zoukankan      html  css  js  c++  java
  • Devops、CICD、Jenkins

    Devops

    DevOps对应用程序发布的影响

    在很多企业中,应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中,应用程序发布的风险很低,原因如下 [2] :

    (1)减少变更范围

    与传统的瀑布模式模型相比,采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行,因此每次部署不会对生产系统造成巨大影响,应用程序会以平滑的速率逐渐生长。

    (2)加强发布协调

    靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟;采用电子数据表、电子数据表、电话会议和企业门户(wiki、sharepoint)等协作工具来确保所有相关人员理解变更的内容并全力合作。

    (3)自动化

    强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。

     
     

    与传统开发方法那种大规模的、不频繁的发布(通常以“季度”或“年”为单位)相比,敏捷方法大大提升了发布频率(通常以“天”或“周”为单位)。


    实现DevOps需要什么?

    硬性要求:工具上的准备

    上文提到了工具链的打通,那么工具自然就需要做好准备。现将工具类型及对应的不完全列举整理如下:

    代码管理(SCM):GitHub、GitLab、BitBucket、SubVersion

    构建工具:Ant、Gradle、maven

    自动部署:Capistrano、CodeDeploy

    持续集成(CI):Bamboo、Hudson、Jenkins

    配置管理:Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail

    容器:Docker、LXC、第三方厂商如AWS

    编排:Kubernetes、Core、Apache Mesos、DC/OS

    服务注册与发现:Zookeeper、etcd、Consul

    脚本语言:python、ruby、shell

    日志管理:ELK、Logentries

    系统监控:Datadog、Graphite、Icinga、Nagios

    性能监控:AppDynamics、New Relic、Splunk

    压力测试:JMeter、Blaze Meter、loader.io

    预警:PagerDuty、pingdom、厂商自带如AWS SNS

    HTTP加速器:Varnish

    消息总线:ActiveMQ、SQS

    应用服务器:Tomcat、JBoss

    Web服务器:Apache、Nginx、IIS

    数据库:MySQL、Oracle、PostgreSQL等关系型数据库;cassandra、mongoDB、redis等NoSQL数据库

    项目管理(PM):Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker

    在工具的选择上,需要结合公司业务需求和技术团队情况而定。(注:更多关于工具的详细介绍可以参见此文:51 Best DevOps Tools for #DevOps Engineers)

    软性需求:文化和人

    DevOps成功与否,公司组织是否利于协作是关键。开发人员和运维人员可以良好沟通互相学习,从而拥有高生产力。并且协作也存在于业务人员与开发人员之间。

    出席了2016年伦敦企业级DevOps峰会的ITV公司在2012年就开始落地DevOps,其通用平台主管Clark在接受了InfoQ的采访,在谈及成功时表示,业务人员非常清楚他们希望在最小化可行产品中实现什么,工程师们就按需交付,不做多余工作。

    这样,工程师们使用通用的平台(即打通的工具链)得到更好的一致性和更高的质量。此外,DevOps对工程师个人的要求也提高了,很多专家也认为招募到优秀的人才也是一个挑战。


    链接:https://www.jianshu.com/p/c5d002cf25b9

    本文链接:https://blog.csdn.net/duanlei123456/article/details/87454053


    持续集成
    持续集成强调对于开发人员的每个提交,立刻进行构建、扫描、(单元)测试。根据结果,我们可以确定新代码和原有代码能否正确地集成在一起。

     

    持续交付
    持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」中进行更多的测试来更早地发现问题。

    比如,我们完成单元测试后,可以把代码部署到QA环境,预生产,中更多的自动化集成测试。如果代码没有问题,可以继续手动部署到生产环境中

    持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的

     

    持续部署
    持续部署则是在持续交付的基础上,把部署到生产环境的过程自动化,发布条件:团队成员确认预发布环境验证通过,进入发布阶段.

     

    持续集成脑图

     

    https://blog.csdn.net/miss1181248983/article/details/82840006

    CI/CD介绍

    https://blog.csdn.net/qq_37372007/article/details/81586751

    教你如何用Jenkins自动化部署项目(教程,从零到搭建完成)

  • 相关阅读:
    Spring(五)AOP简述
    Spring(四)Bean注入方试
    Spring(三)Bean继续入门
    Spring(二)Bean入门
    Spring(一)简述(转载)
    浅析Java中的final关键字(转载)
    浅谈Java中的深拷贝和浅拷贝(转载)
    eclipse的使用、优化配置
    类与对象【一】
    Java学习方法
  • 原文地址:https://www.cnblogs.com/aidata/p/11847475.html
Copyright © 2011-2022 走看看