通过持续交付提升发布效率

前期我们提到，在研发过程中，可能由于迭代变化或需求调整等等原因会导致团队欠很多技术债，从而导致随着项目的运行，技术债务越积越多，导致给用户交付越来越慢，交付的软件质量越来越差，最终不可控，拖延整体交付进度，系统不可控等很多问题。

在实际研发工作过程中，我们基于一些工程学的方法，借助一些工具与方法，结合科学的流程，能够对降低技术负债起到一定的作用。

最近笔者学习和阅读了一些技术类书籍，其中领导推荐的一本《持续交付发布可靠软件的系统方法》书籍中所提到的理念和实践方法，对提升发布效率、减少技术债等就有一定的帮助，可供软件研发实践参考。

下面就结合笔者的一些实践，以及该书的一些理念，仅仅从持续交付中一些小的点来做一些分享，在实践中可以作为一些参考，可以帮助改善工作质量，减少一些技术债务，提高持续交付的质量和效能。

提到持续交付，我们都知道，它是一种软件工程手法，其目的让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。软件研发过程中，我们不仅仅要保证软件产品当前可用，而且希望保证它持续长时间可用，甚至随时随地有了需求的变更后，都能够快速实现、快速完成、快速部署和交付。尤其是当软件面临客户的紧急需求变更时候的交付诉求，这种能够快速交付的能力就显得尤为重要。

一、持续交付的目标

持续交付的目标在于让软件的构建、测试与发布变得更快以及更频繁。通过这种方式来减少软件开发的成本与时间，减少风险。持续交付往往与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。持续交付往往伴随着持续部署，与自动化测试及自动化部署配合开展，几项工作之间相互协调，相辅相成。

二、关于持续交付

关于持续交付，我们接下来尝试分享和回答下面几个问题：

1)持续交付是在解决什么问题，为什么要做持续交付，它能带来什么？

2)持续交付怎么做？持续交付什么时候做？

首先，看第一个问题，持续交付在解决什么问题。关于交付，从在不同的角度对交付进行解读会有不同含义，面对用户的交付，面的客户的交付，面对甲方乙方，做一款产品的交付，做一个项目的交付，其交付方式，交付质量，交付物可能都是有一定差别的。我们这里缩小范围，仅描述研发团队对用户的软件交付，讨论持续交付如何实践。

对于产品研发团队来说，产品的版本的更新迭代和交付，最终经过集成测试、系统测试等测试后的软件版本通过部署交付到用户环境，最终调试跑起来，达到可提供给客户服务和使用的状态即理解为软件交付。

在交付之前，我们需要进行多轮回归验证，经过单元测试、配置项测试、集成测试、系统验收测试，兼容性测试，发现软件缺陷之后，Bug修复之后的回归测试。而我们希望每一轮的回归测试能够尽可能快，Bug修复能够不带来新的问题，开发人员在引入任何回归错误时（包括缺陷、性能问题、安全问题、可用性问题等），都能快速得到反馈。只有快速发现问题，快速修复问题，快速反馈问题修复结果，才能让整个环节加速。一旦发现软件中的问题，就立即加以解决，从而保持代码的主干master随时都始终处于可部署状态，这样就实现了一定意义上的快速实现，再加上这个过程中，代码compile、代码build，都是以工具方式，通过代码驱动，那就初步实现了持续集成。

我们希望通过持续集成，结合持续交付的作用，将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改。如果代码没有问题，可以继续手动部署到生产环境中。

对于项目实施团队来说，持续交付是要将客户要求实现的功能部署到客户的生产环境，通过验收即为交付。对于最终用户来说，持续交付是最终用户可以使用相关的功能即为交付。持续交付是指持续的将各类变更（包括新功能、缺陷修复、配置变化、实验等）安全、快速、高质量地落实到生产环境或用户手中的能力。持续交付的能力通过自动化流水线的方式实现，减少研发过程中不必要的浪费，近而缩短整个研发过程中所有需求的交付周期。持续交付是一个整体过程，从一个业务端的想法到系统功能可以面对客户的全流程。简单来讲就是，持续交付能够帮助提高交付效率，节约成本。

其次，持续交付怎么做？建议在项目初期，项目立项时候，就开始着手准备，根据项目的形态，是分布式，还是单体应用，是单独的信息管理系统，还是需要多端交互的系统，基于公有云、还是私有化部署等等，结合项目的实际分析，具体选择是直接写脚本，还是通过工具完成。持续交付开展越早越好，越是前期，模块越小，集成时候出错概率越小，遇到问题也容易解决，越是大规模多模块的复杂系统，软件问题的处理难度越大，耗费的时间也越多。

尽早开展持续集成，尽早让测试介入，这条原则，在软件工程实践中，强调多次都不为过。持续交付适合建立了发布流水线，有单元测试与自动化测试的团队做，要想持续交付，通过这些脚本去测试业务代码，能够实现对结果的快速反馈。而前几年流行的TDD模式，就是在通过强调写业务代码之前，需要先写好单元测试测试代码，并将单元测试代码集成，通过测试代码验证业务代码的方式提高业务系统软件质量。在这样的工作模式下，通过测试代码驱动开发业务代码，我们对于覆盖率提出一定数量方面的要求也很有帮助。

三、持续交付的发法和原则

 

在实际开展持续交付过程中，也可以根据实际情况进行，有些界面设计之类可能根据用户喜好不同，风格变化可能比较频繁，此类工作不可少，但是又不影响代码构建，对于此类，我们可以另辟分支开展。针对业务代码，可以考虑参考这几个原则开展：

 

◆坚持精简原则，选择适合自己业务的来实现，尽可能拆分模块，细化小模块做持续交付。

 

◆持续尽早开展，并分解问题，不断试错纠错，在不断的支持分解和解决问题中持续优化交付流程。

 

◆坚持快速反馈，不是一味的埋头苦干，提早确认和反馈风险，在快速反馈中，尽早完成和解决问题。

 

◆持续改进并衡量，改进和衡量方式同样重要。

 

前期做好规划，尽早开展，在实际开展过程中，不断分析优化，持续解决问题，随后进行问题回归与验证，作为下次优化的起点。采取PDCA工作模式，不断执行-检查-分析-调整，持续迭代。而这种小规模，小版本迭代，小步快跑的方式，有助于提升持续交付成功率。

 

我们建议频繁提交，小代码块提交。尽量避免很长时间不提交，却一次性提交大量代码，这种方式，一旦提交后构建失败，导致对问题的分析定位也是耗时巨大。少量代码频繁提交，每个模块只做每个模块的事情，于软件设计模式清晰，也对代码构建有好处，提交后即使出错，也好排查。易于快速迭代，实现快速编译、快速构建、有助于快速交付。

四、持续交付的实践

在软件团队，我们知道以前有一个角色叫做SCM，软件配置管理工程师。他专门会负责代码的构建、集成，以及配置项、代码基线与版本等的管理。但近年来，随着DevOps的流行，加上敏捷的口号，该职位只在一些大中公司中存在，但SCM的关键性毋庸置疑。软件的集成，软件的配置项，代码管理等环节，是软件能够从零散的代码得以组装，成为可执行可运行的软件的必要环节，于交付而言不可或缺。

SCM工程师在软件配置管理过程中的这些活动：配置标识、配置控制、配置状态发布、配置的评审，现在逐步融入在持续集成环节。配置管理是软件生命周期里，对定义各类配置项，建立各类基线、描述相关软件配置项及其文档的过程很重要。在持续交付过程中，把一些之前需要手动操作的，通过脚本或工具连起来，用代码去自动化的实现，有助于落地持续交付。逐渐借助一些工具，在实践中能够帮助我们实现持续交付，比如以前就有cruise control、hudson、Jenkins、 TeamCity、等一些出名的CICD工具，随后出现了Travis CI、Gitlab CI等；但是Jenkins由于其免费，跨平台，支持docker化安装，支持上千个插件的扩展版本，可以集成几乎所有市场上可用的工具和服务，现在依然收到很广泛的使用。Jenkins支持插件化安装并扩展为最大的开源CI工具之一，可帮助工程团队自动化部署。在实际的开展过程中，可以参考相关帮助文档进行，关于jenkins的实践与应用使用，网上资料很多，这里暂不展开详细描述具体工具的使用细节。

五、写到最后

持续交付并非一蹴而就，我们可以借助一些工具结合实际业务快速实现，结合持续集成、持续交付、持续部署几个活动相辅相成，经过在项目中的磨合实践、调试、优化，并最终形成适合团队的持续交付工作流程。在实际中，可能项目不同，业务不同，也需要适当调整。可以根据实际业务的规模，以及项目周期的长短，选择适当的工具，能够最快速的用于解决项目实际问题，助力快速交付，才是最好的。