DevOps – 持续交付
如果把DevOps的能力提升比作是登山的话，持续交付必然是为登山准备的最重要的工具包。虽然敏捷开发已经被大多数的软件企业所接受，但敏捷的实践必须能够和持续交付的能力结合起来才能做到真正的敏捷。毕竟，我们所做的任何工作都是为了实现价值交付。软件如果不能实现交付使用，那么它也只能是我们代码仓库的存储物。
“如果只修改一行代码，你的软件需要多长时间部署上线？” 我们先来看一下软件交付的基本流程：
从流程的角度来看，任何一个环节出现问题都可能导致一次失败的上线部署。编码质量不高、配置错误、测试不全面、部署考虑不周全都会造成最终的产品不可用，甚至造成巨大的经济损失。那么，在敏捷开发的过程中，持续交付又如何保障了价值交付？为了解决代码质量的问题，我们需要有充分的测试保障；为了避免手工错误，我们需要尽可能的自动化。但在实际的工作中，不是建立了一条自动化的流水线就能解决所有的问题，让敏捷过程和持续交付的实践结合起来，才能发挥最大的价值。一般情况下，持续交付的流水线跟上述开发、测试、部署过程是基本一致的，但在流水线的每个阶段都有其特殊的关注点。
一、持续交付的各个阶段
1、部署流水线的前提条件
版本控制：一般情况下，我们都会将代码存储到版本控制中，但要实现自动化集成和部署，还需要将项目相关的所有内容都提交到版本库中，包含测试代码、数据库脚本、构建脚本、相关配置信息，把项目中涉及到的基础设施也作为代码来看待。
自动化构建：构建过程必须能够用脚本运行，不需要人工在可视化界面上进行干预，才能实现完全的自动化。所以，在各个环节的工具选择上，一定要选那些支持脚本化运行的工具。
团队需要达成的共识：团队成员要共同遵守一些纪律，如：小步增量提交、主干开发、优先解决流水线失败的问题等，这样才能更及时的获取反馈。当问题发生的时候，上下文是清晰的，解决问题也是最快的。
2、编码阶段
编码阶段，在完成功能的同时要保证单元测试的覆盖率。最好是采用TDD，不仅仅是为了完成测试的编写，这是一种思维方式的改变，能使代码结构更清晰、更有可测试性。
3、构建和配置阶段
为了能够保证流水线正常运行，开发人员在提交代码前，必须更新代码并在本机执行构建，让所有的测试能够在本机通过，以防止给流水线带来不必要的构建失败。这也是代码集成的第一次反馈,至少保证代码在自己的电脑上是可以正常执行的。
代码集成以后，流水线自动开始构建，如果遇到构建失败，最好不要继续提交代码，把问题解决以后再继续提交。对于代码构建阶段，在服务器上至少要运行自动化单元测试。为了更严格的控制代码质量，可以把findbugs等静态扫描结果也作为编译失败的条件。
4、测试阶段
软件进行初步的集成后，就可以进行相关测试了。目前的项目基本都是前后端分离或是微服务架构的。为了更方便的开发联调和测试，编辑后的二进制包会按步骤部署到三个环境，分别是Dev、Test和UAT。为了验证自动化部署的环境是否可用，在不同的环境中都可运行冒烟测试、自动化验收测试及对部署环境的测试。
Dev环境：在开发过程中，各个子模块可能会频繁的的提交代码，前端人员也需要与后台的环境进行联调，所以这个集成环境是给前后端开发人员联调使用的。
Test环境：为了保障测试过程的操作及数据不被干扰，QA需要从制品库中选出一个版本部署到Test环境中。这个过程可以在项目中约定由QA操作，或者通过设置权限，由专门人员负责。
UAT环境：该环境为类生产环境，主要用于用户验收演示，也用于容量测试。
5、发布阶段
为了防止手工发布带来的问题，发布阶段的工作也要尽可能的自动化。但这个过程考虑的问题也更复杂一些。从技术层面来讲，如果在生产环境中发布失败，如何确保系统回滚且保障回滚后数据正确性。如果在不中断业务的情况下进行发布，对发布操作的要求就更高一些。可以考虑蓝绿部署、金丝雀发布等策略。
对于每一次发布，都需要制定发布计划。一般情况下，发现问题尽量能够当时解决，尽量不要回滚。因为回滚后，发布时遇到的问题就无法重现了，失去了解决问题的机会。除非遇到无法解决且对功能有一定影响的问题才应该回滚。
二、流水线建设的问题
1、工具的使用和选择
在工具的选择上，如果不是特殊需求，使用更流行的工具能带来更大的好处。越受欢迎的工具，功能一般更完善，遇到问题容易找到解决方法，工具的适应性也更强一些。因为使用的群体众多，所以各种平台的集成和支持也会更好一些。在项目中也曾遇到无法与客户方平台集成，而不得不更换工具的情况。
2、持续交付项目中的度量
在持续交付的项目中，应该注重整个团队全局的度量指标。最重要的全局度量指标就是周期时间了。我们应该衡量团队交付某个特性所使用的时间，或者在固定的迭代周期内能交付多少特性。
反馈是所有软件交付流程的核心。只有缩短反馈周期才能使整个流程得到优化。如：识别流程中哪个环节造成了资源等待，或者资源分配不合理造成某些环节周期太长，以便于调配人员或者增加资源，或者通过技术手段解决一些问题。根据“霍桑效应”：“那些意识到自己被观察的个人，具有改变自己行为的倾向”。团队管理过程注重反馈的时间，每个人也会有意识的缩短反馈时间。
3、循序渐进、持续改进
流水线没有一个标准的流程，也不是一两天时间就构建完善的。可以从简单的流水线开始，根据项目的进展以及开发、测试和生产环境的变化不断进行改进。所有的一切都是为了自动化、为了提升效率，为了能够快速的实现价值交付。
三、总结：
持续交付的重要实践包含以下方面：
自动化部署
持续集成
持续测试
主干开发
版本控制
数据管理和度量
持续交付只是DevOps能力模型中的一个重要组成部分，整体团队的能力提升还需要注重敏捷开发的管理能力、技术运营的能力。这不仅仅是技术团队的管理和能力的问题，甚至会对公司的文化和组织结构产生重大影响。
关注公众号：
