DevOps CI CD 容器云 微服务 敏捷开发

DevOps CI CD 容器云 微服务 敏捷开发
参考:
https://www.sohu.com/a/219547745_151779
https://blog.csdn.net/CrankZ/article/details/81545439

DevOps 理念,方法
2018/12/06 陈信

概念
DevOps(Development和Operations的组合词)是一种方法论,是过程、方法与系统的统称,用于促进开发、运维和质量(QA)部门之间的沟通,协作与整合.
DevOps是为了打破开发和运维之间的隔阂与低效,在保证质量的前提下实现更自动化、更高效的协作与产品的交付.
目前,很多公司在实施容器云时实现CI,或者CI/CD就叫DevOps.我们觉得这只是实现DevOps的一部分,不等于DevOps.

变革
角色分工：打破传统团队隔阂,让开发、运维紧密结合,高效协作
研发：专注研发、高度敏捷、持续集成
产品交付：高质量、快速、频繁、自动化、持续交付

落地
简单的说,DevOps=团队文化+流程+工具.
团队要知道并认可DevOps理念.再通过具体的流程,工具来实现这个理念.

具体注意点说明
一、CI 不等于DevOps
持续集成是编码、构建的过程.
DevOps从CI起步,也是一个很好的切入点.但这仅仅是一个开发构建过程,都在开发端,是实现敏捷开发的一种方式,研发过程自动化,这也是我们考虑采用容器云和DevOps的一个因素.但仅有开发端的敏捷还不等于DevOps.

二、CI /CD也不等于DevOps
快速的迭代(CI,CD),但依然没有解决开发、运维、质量保证部门之间的协作和整合.职责依然没有划分清楚.而且目前的容器云CI/CD流水线设计,不足以支撑企业生产环境部署要求.这也是为什么很多公司即便采用容器云也只是在开发测试环境使用的原因.

三、DevOps是什么(以作者所在公司情况为例)
DevOps不应该重建公司组织架构(专门设立一个部门,牵扯利益过多,同时也违背了DevOps初衷).
我们采用容器云的需求是：
1．敏捷 提升敏捷开发能力.这是DevOps能力.敏捷开发,也是我们为了适应公司互联网业务发展和应用快速迭代开发的要求,让生产端也更加敏捷起来；
2．环境一致性 建立开发测试甚至生产环境一致性. 这是容器云和DevOps能力.建立标准化、一致性的开发、测试、运维环境,专注于业务应用研发而不操心资源；
3．时间 实现应用全生命周期自动化管理.这是DevOps能力. 满足公司内私有云环境内的应用托管、应用开发、自动化运维等应用服务全生命周期管理需求；
4．弹性 弹性伸缩、灰度发布等. 这是容器云和微服务的能力.实现应用服务的弹性伸缩、灰度发布等能力,满足促销、秒杀等业务需求；

DevOps从计划、编码、构建,到测试、发布、部署,以及运营、监控,形成一个环路
这也是我们实采用微服务持续改进的要求.结合容器和微服务的采用,我们把DevOps分为几个流程：
CI持续集成.>CD持续交付.>CD部署发布.>持续监控,形成监控报告.>持续反馈,是基于监控和业务应用的使用情况,持续的数据分析,持续地提出完善意见.>持续改进,基于反馈的意见,启动新的改进计划流程.

四.如何落地
这些流程的实现,需要众多工具的支持,形成一套DevOps工具链.这些流程如何落地？

持续集成CI
持续集成阶段,考虑实现计划流程自动化、资源选择自动化、代码质量控制自动化、构建自动化等流程.
构建自动化,采用容器云后就是构建镜像.在代码检查完毕,没有什么缺陷的情况下,可以自动启动构建流程,Maven或Gradle是目前比较受欢迎的工具.说起构建,一般都离不开Jenkins.它可以集成SVN或Git,JDK,Sonar,Maven等众多工具,是非常方便的构建自动化实现方式.

持续交付CD
镜像构建完毕,上传到镜像仓库.开发工作暂告一段落.开始准备测试环境进行测试.实现自动化测试.
测试用例生成自动化,这可能需要QA团队实现一些工具,根据业务需要自动生成测试用例数据.测试完成没有问题,自动交付到生产镜像仓库.
镜像仓库
容器云中镜像仓库我们作为持续集成和持续交付的终点,也是开发和业务部署的中间节点.所有的开发测试工作到此已经完全完成,所交付出来的是可以部署到生产的业务镜像.

部署发布CD
略

持续监控
日志、监控是业务运营过程中判断业务运行是否正常的重要的基础能力.持续监控是实现日志收集、健康检查监控的自动化.

持续反馈
持续反馈是基于日志和监控的基础上,实现数据分析自动化、告警自动化、反馈自动化等.
反馈的形式可以是简单的短信、邮件告警,也可以是分析报告.集成短信、邮件、微信、设置是Jira等系统可以实现反馈的自动化.

持续改进
基于反馈的信息,继续改进应用服务.实现了业务应用的全生命周期管理.在各个阶段实现自动化,也提升了效率和响应能力.

分工
上面我们谈到的大部分工作,其实是开发人员的职责.也就是业务应用的全生命周期的管理.也是因为运维和QA都是在做幕后的工作.运维人员主要负责资源,软硬件资源的维护,要保证应用服务整个生命周期所需的软硬件资源.比如运营过程中磁盘损坏的修复,主机计算资源的增删、分配等.QA则承担提供开发、测试、生产运行环境供给和测试用例自动生成,以及测试自动化、运维自动化工具研发,质量跟踪保证等职责.

容器云
DevOps和容器云是相辅相成的,容器云提供基础设施资源.很便利的实现环境一致性.
容器云并不包含DevOps,所以不是在容器云里实现DevOps.在容器云中去做CI或CD流水线,是不合适的.CI独立于容器云而存在的,即便不采用容器云,同样可以实现CI 或DevOps.容器云是微服务运营的一个便利的载体,微服务生命周期管理可以是DevOps的一个重要部分.容器云的架构非常适合微服务的架构.微服务的开发部署和运营又和DevOps的理念和方法论很匹配,所以采用容器云和微服务,实现DevOps,是一个很好的选择.

不管怎么变化,人是master,需要协调定义好人在各个流程各个环节的角色和职责.DevOps也在一个不断优化、持续改进的过程中.

常见的DevOps工具

CI, CD AND CD (打通编译->交付->部署的流程)
20180518 陈信
CI是持续集成.
CD既可以指代码持续交付,也可理解为代码持续部署.

持续集成(Continuous Intergation)- 编译,测试,合并
不断将分支进行编译并自动化测试,通过后合并到主线上.
在持续集成环境中,开发人员将会频繁的提交代码到主干.这些新提交在最终合并到主线之前,都需要通过编译和自动化测试流进行验证.这样做是基于之前持续集成过程中很重视自动化测试验证结果,以保障所有的提交在合并主线之后的质量问题,对可能出现的一些问题进行预警.

持续交付(Continuous Delivery)-发布测试版本
通过一个按键来实现随时随地的线上部署.一般每周或每天交付(发布)一次.
持续交付就是将我们的应用发布出去的过程(至测试环境吧?).这个过程可以确保我们尽可能快的实现交付.这就意味着除了自动化测试,我们还需要有自动化的发布流,以及通过一个按键就可以随时随地实现应用的部署上线.
通过持续交付,您可以决定每天/周发布一次.
但是,如果您真的希望体验持续交付的优势,就需要先进行小批量发布,尽快部署到生产线,以便在出现问题时方便进行故障排除.

持续部署(Countinuous Deployment)-发布生产版本
实时自动交付: 代码提交后即刻就会自动进行持续集成+持续发布,用户即刻就看到效果.
如果我们想更加深入一步的话,就是持续部署了.通过这个方式,任何修改会直接和客户见面.没有人为干预(没有一键部署按钮),只有当一个修改在工作流中构建失败才能阻止它部署到产品线.
持续部署是一个很优秀的方式,可以加速与客户的反馈循环,但是会给团队带来压力,因为不再有“发布日”了.开发人员可以专注于构建软件,他们看到他们的修改在他们完成工作后几分钟就上线了.基本上,当开发人员在主分支中合并一个提交时,这个分支将被构建、测试,如果一切顺利,则部署到生产环境中.

合并CI CD and CD(构建全局的持续集成环境)
他们每部分都更加接近生产环境.你可以构建自己的持续集成环境,然后,一旦团队适应,你可以添加持续交付流,最后,可以添加持续部署流到整个工作流中.
举例CI, CD and CD 流水线
Build > Test > Deploy to Staging > Acceptance tests > Deploy to production > Smoke tests

到底值不值这样做呢?

持续集成
你需要具备哪些条件:
你的团队需要为每个新功能,代码改进,或者问题修复创建自动化测试用例.
你需要一个持续集成服务器,它可以监控代码提交情况,对每个新的提交进行自动化测试.
研发团队需要尽可能快的提交代码,至少每天一次提交.
你能获得什么呢？
通过自动化测试可以提早拿到回归测试的结果,避免将一些问题提交到交付生产中
发布编译将会更加容易,因为合并之初已经将所有问题都规避了
减少工作问题切换,研发可以很快获得构建失败的消息,在开始下一个任务之前就可以很快解决.
测试成本大幅降低-你的CI服务器可以在几秒钟之内运行上百条测试.
你的QA团队花费在测试上面的时间会大幅缩短,将会更加侧重于质量文化的提升上面.

持续交付
需要具备什么条件？
你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求
部署需要自动化.触发是手动的,但是部署一旦开始,就不能人为干预.
你的团队可能需要接受特性开关,没有完成的功能模块不会影响到线上产品.
你能收获什么？
繁琐的部署工作没有了.你的团队不在需要花费几天的时间去准备一个发布.
你可以更快的进行交付,这样就加快了与客户之间的反馈环.
轻松应对小变更,加速迭代

持续部署
需要具备的条件:
研发团队测试理念比较完善.测试单元的健壮性直接决定你的交付质量.
你的文档和部署频率要保持一致.
特征标志成为发布重大变化过程的固有部分,以确保您可以与其他部门(支持,市场营销,公关…)协调.
可以获得什么？
发布频率更快,因为你不需要停下来等待发布.每一处提交都会自动触发发布流.
在小批量发布的时候,风险降低了,发现问题也可以很轻松的修复.
客户每天都可以看到我们的持续改进和提升,而不是每个月或者每季度,或者每年.

写在最后:
如前所述,您可以采用持续集成,持续交付和持续部署.你怎么做取决于你的需求和你的业务情况.如果你刚刚开始一个项目,并且还没有客户,那么你就可以去创建这些工作流,最好是将这三个方面都实现,并且在你的项目迭代和需求增长中同时迭代它们.如果您已经有一个生产项目,那么您可以一步一步地分阶段去实现他们.

「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」提供了一个优秀的 DevOps 环境,对于整个团队来说,好处与挑战并行.无论如何,频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分.

敏捷开发(一种开发理念)
20180606 Chenxin整理

瀑布开发
传统的瀑布开发,就好比初始把所有菜都做好后,一并端上来.其中,客户需求是不变的.
敏捷开发指在最短的时间内做好最简单核心的功能模块,之后再不断迭代,完善产品.其中,客户需求经常变更,市场一直在快速变化.
传统的瀑布式开发模式与敏捷开发模式的区别：一次上一个菜(客人边吃边等),还是一次把所有菜做完再上(客人要等很久才能动筷子)

什么是敏捷开发？
敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法.
在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征.
简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本.然后在后续的生产周期内,按照新需求不断迭代升级,完善产品.

敏捷开发模式的分类
敏捷开发的实现主要包括 SCRUM、XP(极限编程)、Crystal Methods、FDD(特性驱动开发)等等.其中SCRUM与XP最为流行.
同样是敏捷开发,XP 极限编程 更侧重于实践,并力求把实践做到极限.这一实践可以是测试先行,也可以是结对编程等,关键要看具体的应用场景.
SCRUM则是一种开发流程框架,也可以说是一种套路.SCRUM框架中包含三个角色,三个工件,四个会议,听起来很复杂,其目的是为了有效地完成每一次迭代周期的工作.在这里我们重点讨论的是SCRUM.
SCRUM的工作流程
学习Scrum之前,我们先要了解几个基本术语：
Sprint：冲刺周期,通俗的讲就是实现一个“小目标”的周期.一般需要2-6周时间.
User Story：用户的外在业务需求.拿银行系统来举例的话,一个Story可以是用户的存款行为,或者是查询余额等等.也就是所谓的小目标本身.
Task：由User Story 拆分成的具体开发任务.
Backlog：需求列表,可以看成是小目标的清单.分为Sprint Backlog和Product Backlog.
Daily meeting：每天的站会,用于监控项目进度.有些公司直接称其为Scrum.
Sprint Review meeting: 冲刺评审会议,让团队成员们演示成果.
Sprint burn down：冲刺燃尽图,说白了就是记录当前周期的需求完成情况.
Rlease：开发周期完成,项目发布新的可用版本.

如上图所示,在项目启动之前,会由团队的产品负责人(Product owner)按照需求优先级来明确出一份Product Backlog,为项目做出整体排期.
随后在每一个小的迭代周期里,团队会根据计划(Sprint Plan Meeting)确定本周期的Sprint Backlog,再细化成一个个Task,分配给团队成员,进行具体开发工作.每一天,团队成员都会进行Daily meeting,根据情况更新自己的Task状态,整个团队更新Sprint burn down chart.
当这一周期的Sprint backlog全部完成,团队会进行Spring review meeting,也就是评审会议.一切顺利的话,会发布出这一版本的Release,并且进行Sprint回顾会议(Sprint Retrospective Meeting).
那么,现实中的Scrum是什么样的情景呢？看看下面的照片就知道了(白板上的一推贴纸,计划,完成进度等.为了提升B格而做的看板(scrum)).

敏捷开发与Devops
Devops是Development和Operations的合成词,其目标是要加强开发人员、测试人员、运维人员之间的沟通协调.如何实现这一目标呢？需要我们的项目做到持续集成、持续交付、持续部署(CI/CD).时下流行的Jenkins、Bamboo,就是两款优秀的持续集成工具.而Docker容器则为Devops提供了强大而有效的统一环境.