在编码过程中，一个很容易发现的现象就是：

经常依赖手工操作的过程，一定容易出错，而且是反复出错

这就是持续交付出现的原因。

持续交付的目标就是从代码编译到可部署的二进包，甚至是部署这个很多都是依赖手工操作的过程自动化，流水线化。

微言码道开始新的系列，从零到一，构建你的持续交付流程

这是第一篇。

一）

稍微观察下，你所参与的项目，从编码到部署服务，这个过程是如何推动的？

估计方式有挺多，但总体来说，可以分为两种方式，一种是依赖人工手动操作，还有一种是自动。

手工的方式当然可能多种多样，有些可能还会有非常规范的流程约束，但最终仍然避免不了由某个特定的开发或测试或运营人员，以远程登录到服务器的方式，执行某些命令，来达到部署新版本的目标。

这个过程是不是非常熟悉？

当然，因为这就是大多数项目的日常而已。

而持续交付则主张：

把从源码编译开始，直至部署，甚至部署后的必要验证等全部由计算机来执行，将这个过程流水线化，自动化

二)

所以，我们需要开始思索一个问题，究竟哪些过程应该或者是可以放到持续交付中。

构思一：将二进制包的构建过程自动化

这种是最初级的，也是大多数持续交付应该最起码要达到的目标。

触发构建 --> 编译源码 --> 生成二进制包

就是将编码的最终的二进制包的生成过程自动化，不需要再由开发人员手工来做。

关于这一点，我本人有挺大的感触，前几年在我负责移动开发的时候，我们移动端团队最烦的一件事就是给测试，项目经理及各种客户打包。因为不同的包的App名称，Logo都不一样，没有一个统一的包。只能按需打包。

很长一段时间内，都是由这些人找到我们团队的人来打包。

每次打包对我们团队的开发人员其实是个很无聊但又挺折磨人的事，因为要修改名称，LOGO，或者又有一些定制化的修改，改完发包，发给相应人员，如果有问题再来回折腾。

效率极低，而且极其浪费开发人员的时间。

大约在18年还是19年的时候，我就想着如何改善这个现象，于是在一个MacOS系统上，基于Jenkins，写了些Shell脚本，把这个过程自动化了。

这就是最简单的一种形式，将生成二进制包的过程自动化。

构思二：把单元测试和质量分析纳入进来

我是TDD测试驱动开发的忠实的信徒。所以基本都会写单元测试，那在持续交付的这个过程中，当然也可以把单元测试加进来。

想像下，每次触发构建的过程中，自动运行所有单元测试，通过才构建，不通过中止构建。

这是不是挺好的一件事?

还有质量分析，在后端我通常是用Sonar来协助做质量分析，而在前端也是用的主流的ESLint。那在这个持续交付过程中，是不是可以自动的把代码放到这些工具上去执行，分析并具报告？

甚至更完美点，设定一个质量的标准，只有达到这个标准的才允许继续执行这个流程，没有达到的中止流程。比如为单元测试覆盖率设计一个目标，达到这个目标以上才算通过。

这又让我们的持续交付帮我们做了单元测试与代码审查这两个事情了。

非常好。

构思三：将文档更新与部署自动化

很有可能，我们在项目中，都会编写一些文档，比如Api文档或Java doc文档。

那我们完全可以把Api文档或Java doc文档的生成与部署也自动化。

这样每次流程完成，所有文档都保持在最新的状态，对开发人员来说，只需要编写文档就好，不用关心如何生成HTML或PDF，以及怎么样把它更新到服务器上部署等。

又往前推进了一步。

构思四：部署的自动化

也许仅仅生成二进制包并不足够，至少在某些环境下并不足够。

为什么不在开发环境自动重启服务？或在测试环境下提供一个按钮或某种机制，让测试人员点击一下就完成服务重启？

相比让人去拿二进制包再COPY到哪个服务器上，重启这种手工的操作，让流程来做到这一切，不是更好么？

所以把这个也加入持续交付中吧。

构思五：及时的通知与反馈

我们希望这个交付流程的运行过程，能及时有效的通知给我们，成功或失败，或者上一次失败这一次成功等各种我们设定的条件下，以邮件或短信或微信消息等，不论什么形式都好，第一时间通知开发团队。

构建失败，构建失败，构建失败了

当构建失败时，如果我们能收到类似的通知，我们就能立马做出反馈，及时修正。

等恢复成功后，可以再通知我们

好了，构建成功了

这样的通知也是不能少的吧？

更多，还有更多

事实上，能做的还有挺多的。

比如，我们期望服务重启后，运行一些简单的健康检查，以证明这个服务重启后的状态是OK的，因为很有可能某个配置配置失败或数据库当机了等。

甚至，我们都可以加上其它很多过程。。。

我们并不需要一步到位，我们只需要记住一个真理：

复杂实现永远是构建在简单实现的基础之上，所以我们可以从简单的开始*

三）

是的，我的确就是这样构思的。

虽然还没有做到服务重启后的必要的健康检查，但至少从构建一到五，我都一一实现了。

最终的交付流程如下图所示：

并且，这个交付流程不仅仅是针对某一端，比如只是后端。

我把它应用于整个项目，包括前端，后端都做到了持续交付。

只是前端没有单元测试和API文档，少了一些不需要过程而已。

这意味着，整个项目的这些过程都是自动化的，这些过程都不需要人工参与。

四）

这就是从零到一，构建你的持续交付流程这个系列的目的所在，我想让更多的人知道如何实现这个过程。

而好的工程实践，是保证好的，可维护的代码的基础与前提。

下一篇：从零到一，构建你的持续交付流程（二）：好的工程实践是必要的前提