《持续交付》（六）总结

引言

本文是《持续交付》一书学习总结的最后一篇。主要内容是结合实际中的一些工具和实践，对持续交付这个话题做个总结。

总结：工具和实践

持续交付的核心是构建一个部署流水线，这个流水线起始于源代码，终止于用户界面，并长期地、反复地、持续地运行。我们采用持续交付的目的是，更加频繁地发布软件中最新的改动，增加产品迭代的次数，在适应快节奏需求的同时，保证产品的质量。

对于源代码管理，我在项目中经常使用Git，这也目前比较主流的版本控制工具和系统。开源社区Github的代码管理也是Git来完成。很多商业公司提供了图形界面化的代码管理工具，比如Bitbucket以及Gitlab，当然这些图形化工具的背后依然是Git命令实现的。

在持续集成阶段，可以使用一些开源的持续集成系统如Jenkins，它的好处是应用广泛、开源免费、插件丰富。还有一些商用的CI系统，比如TeamCity等，它的好处是相对较少，不过要收费。具体的build工具就依赖项目了，比如.NET项目就可以使用MSBuild，Java项目可以使用Maven，Gradle等，JavaScript项目可以使用NodeJS及其相关的库。这些build工具都可以直接或者通过插件的方式配置在CI系统中，用于实现部署流水线。

对于测试，也是因项目而异。常见的单元测试工具如NUnit，JUnit，Karma等。测试工具也可以与CI系统结合，或者写入部署流水线的脚本中。还有很多单元测试与开发框架紧密集成，方便开发者使用。至于测试的代码覆盖率、安全问题以及代码风格问题可以通过静态代码扫描工具发现，常见的工具有SonarQube，我们可以将其配置在CI系统中，在每次build时运行，并把结果上传到服务器供查看。如果有比较严重的问题，可以直接让build失败，直到问题解决。

在build成功后，要把生成的一些可部署的二进制文件或者容器上传到某个仓库中，常见的仓库有JFrog Artifactory。该工具还支持二进制文件的安全扫描XRay功能。这类工具也可以通过插件集成到如Jenkins这样的CI系统中。在build过程中有时还需要把要执行的命令和环境打包成一个容器用于部署，常见的容器工具有Docker，使用的十分广泛。生成的Docker镜像也可以上传到远程的仓库中。

对于CI系统执行的脚本，可以利用系统支持的语言和API，比如Jenkins里基于Groovy脚本的Jenkins API。如果有常见的功能，可以将其配置成Module，供其他开发者使用，提供团队整体的开发效率。

在部署阶段，由于我经常参与跟云平台相关的项目，常见的平台工具有微软的Azure，亚马逊的AWS，Google的Google Cloud。不过这些平台都从基础设施开始就可以支持，比较底层。对于容器类的应用有Kubernetes（K8S）作为容器的管理工具，开发人员不必关心Docker容器的资源管理细节，而可以专注于容器的使用。对于发布流程，可以使用诸如Spinnaker的工具来管理，它支持蓝绿发布、金丝雀发布、手工触发等多种发布流程的管理。管理员只需要在界面上进行简单的配置和控制，就可以完成产品的部署和发布。这个工具支持的部署平台包括前面提到的Azure、AWS以及K8S等。

最后几点体会就是，工具再好用也要服从于好的实践流程，并且整个团队都要对高效的流程有纪律之心，不能觉得可有可无。没有一劳永逸的流程和工具，二者都在频繁改进中，就像软件在不断迭代一样。软件持续交付是整个团队的事情，某个环节的低效都可能成为整个流程的瓶颈。

《持续交付》这本书的分享就到这里，谢谢！欢迎讨论。