DevOps从持续集成到研发运维一体化逐步演进

　　今天再讲下DevOps，即从最简单的持续集成到整个研发运维一体化过程的逐步演进过程。对于DevOps，我在前面已经写过多篇文章，涉及到DevOps介绍，成熟度模型，流水线设计，和敏捷研发集成，自动化测试等。感兴趣的可以先参考我前面的文章。持续集成和持续部署CICD
　　先做下概念区分，即早期的持续集成重点是解决多个开发人员提交的代码能否编译构建通过，是否存在编译错误，存在检入代码冲突等问题。
　　也就是说持续集成完成可以仅仅是构建通过在集成环境，并没有部署到测试环境。
　　而持续部署谈的则是持续集成完成的东西要部署到测试环境，同时在测试验证通过后，能够在多个测试环境，比如SIT测试环境，UAT测试环境等进行环境迁移部署。
　　持续集成和容器云结合
　　传统持续集成过程，往往并没有将打包过程单独列出。在和容器云集成的时候，注意这个时候交付的对象不再是部署包，而是容器镜像。
　　因此存在一个过程，将编译构建完成的部署包制作成容器镜像的过程。而后续的部署，包括持续部署则是基于制作好的容器镜像文件进行的。
　　持续集成是否涉及到部署？
　　如果团队有两个人各自开发一个模块，那么持续集成不仅仅是做两个模块能够编译构建通过，可能还需要运行自动化测试代码，比如单元测试或接口测试代码，来验证两个模块之间的接口是否正常。
　　而这些操作是需要进行部署的，当然持续集成的部署可以部署在开发环境，或集成环境，目的仍然是为了验证代码编译和集成过程没有问题，而并不是说部署出来给测试人员测试。
　　持续部署以二进制部署包交付
　　当SIT测试环境测试完成后，应用需要部署到UAT环境，那么这个过程是持续部署的一个部分。注意这里的部署仅仅是部署包的跨环境迁移，而不会再涉及到重新进行编译构建等操作。
　　因此持续部署有一个重点即跨环境的部署对象是二进制部署包，同时部署过程不再涉及到编译，构建等操作。
　　持续部署和持续交付
　　持续交付应该理解为持续部署的一个部分。
　　即持续交付是将测试验证通过的软件应用发布到生产环境供用户使用的过程。持续交付面对的是最终的生产环境。部署只关心我新版本的应用程序是否已经部署到生产环境即可，但是持续交付则需要关心我最终交付给用户的是哪个应用或哪个版本。
　　因此，即使部署到生产环境的应用，也可能没有马上交付给用户使用，也可能是逐步交付给用户使用。即我们常说的交付过程中的灰度发布等。持续集成和研发管理协同
　　在DevOps最佳实践里面分为了研发管理，持续交付和技术运营几个关键的过程域。
　　但是在实践的过程中，最容易出现问题的不是单个技术点，而是跨域的协同问题，或者说研发过程管理和持续集成交付本身就是密不可分的两个部分，我们只是为了容易理解和学习将其划分为了不同的过程域而已。
　　要明白任何一次新的编译构建部署完成后都涉及到测试人员测试，测试人员测试出问题后又会提交Bug，开发人员修改Bug后Checkin代码，等待下一次打包部署以形成多次迭代。整个过程最好的方式就是要尽量减少大量的人工沟通协同，而是应该通过工具链协同来完成。
　　传统敏捷研发工具类似禅道，往往基于Scrum标准方法论，提供了需求管理，产品管理，项目管理，任务管理，缺陷管理等完整的研发过程管理功能。
　　对于软件项目来说，整个过程核心如下：先收集需求，形成需求资源池基于需求和变更规划项目版本版本任务开发应用持续集成交付测试测试发现问题，开发修复并持续集成
　　也就是说整个研发过程管理和软件持续集成过程两条线需要高度协同和配合。而整个协同过程中有两条关键的内容。
　　即测试发现Bug并提交，Bug转变为任务，研发修改Bug后推动了版本的持续构建和集成。其次就是持续集成过程中在部署操作环节，通过部署过程的完成要自动化的推动任务或Bug缺陷状态的变更。
　　基于以上思考，整个敏捷研发和持续集成过程协同如下：
　　为何要协同？
　　简单来说就是整个研发过程，各个岗位角色要做的事情是类似任务自动化推动执行的。比如测试，只需要关心自己的todo待办，就知道哪些Bug能够测试，而且这些可测试的Bug一定是已经持续集成和部署到测试环境的。
　　如果未集成和协同，那么就会出现大量无谓的沟通，比如测试还要去问开发，哪些Bug已经修改完成，哪些Bug已经部署可以测试了等。研发和QA过程协同
　　对于DevOps研发运维一体化来讲，始终都是在围绕研发，QA，运维三者之间的协同来展开。这也是DevOps的核心思想。
　　那么研发和QA的协同，在DevOps过程中则是通过持续集成过程来完成自动化的，也可以理解为通过DevOps过程实践中的自动化流水线设计来完成协同。
　　DevOps过程实践更加强调自动化测试，自动化测试既包括了单元测试，接口测试，也包括了UI和界面层的自动化测试。自动化测试从生命周期来讲又包括了测试计划，测试用例设计，测试执行，测试报告输出等。
　　对于测试本身实际又包括两个方面内容。
　　一个是常说的代码功能测试，一个是代码静态检查和安全审计。对于代码的规范性检查，代码安全漏洞扫描，容器安全检查等都可以纳入到静态安全审计内容。不论是自动化测试还是安全审计，都可以作为流水线设计中的可插拔的插件加入到整个流水线执行过程中。
　　所以流水线能力从最初仅仅完成持续集成和持续部署发展到增加了各类QA和质量管控能力，同时这些能力的加入本身又能够实现自动化的协同，实现QA，敏捷研发和持续集成过程三者之间的协同。从持续集成到持续运维
　　持续集成完成后，最终是需要交付和发布到生产环境供用户使用。当发布完成后一个软件应用也进入到持续的监控运维阶段。
　　在DevOps的成熟度模型里面已经将运维管理上升到了运营管理这个概念。
　　简单来说就是DevOps最佳实践里面，软件应用的运维不再应该是一个被动的问题驱动过程，比如发现了问题故障，再推动去解决；而更应该是一个持续运营的过程，这个运营的依据是数据，数据即我们在对环境，应用，服务的持续监控过程中得到的性能数据，状态数据和日志数据。
　　通过对这些状态和日志数据的分析，以数据驱动的思维来推动应用的持续运营。整个运维过程也从被动的问题驱动转变为风险驱动，大数据预测驱动。可以看到从运维发展到AIOps智能化运维，基本也是这个思路。
　　运维和运营是完成整个软件全生命周期过程闭环的关键。
　　即运维发现问题或风险，分析后形成优化或变更需求，同时这些变更需求本身又推动了软件应用下一次迭代版本的持续交付。
　　欢迎关注：人月聊IT
　　分享数字化转型，企业架构规划，云原生，思维和个人成长类文章。公众号同名，可以搜索关注，文章每周一，三，五定期更新。