在开始搭建这个持续交付流程之前，有必要用一篇文章来详细阐述我的一个观点，这就是:
我们要尽量去推动与实施好的工程实践
对于项目或产品而言，好的工程实践也许并不起决定作用，项目或产品的成功依赖的因素太多了，市场，风口，公司的营销能力，人脉以及资源等。
但是，对于产生良好的可维度的好的代码，好的工程实践则起着决定性的作用。
这是从零到一，构建你的持续交付流程系列的第二篇，本系列其它文章为:
- 从零到一，构建你的持续交付流程（一）：一个持续交付流程的构思
一）
首先明确一个定义，什么叫好的工程实践。
以下这些都属于好的工程实践，例如敏捷软件开发，TDD测试驱动开发，代码审查，以及这个系列讲的持续交付等。这些都属于不做看似不影响编程开发及进度但实质对代码的不可见的质量有关键性的影响。
但事实上这样做的并不多。
的确存在相当一部分，可能用大多数都不为过，在编码理念已经发展到非常成熟，形成了上述所说的非常好的工程实践之后，其编码理念仍处于一种类似原始的阶段，单纯不停的编码，也没有单元测试，也不会代码审查，甚至没有事前的领域模型设计，也没有自动化的持续交付流程。
为什么明明有更好的方式，可是团队或公司中很难推行？
暂时我也没有答案，我暂时认为也许与公司的管理文化，以及技术文化有关。
二）
持续交付本身就是好的工程实践的一种。
持续交付的作用是不言而喻，我也不认为我需要一点一点列出来持续交付有什么好处。
而且，持续交付需要与其它好的工程实践搭配一起使用，才会产生更大的价值。
我们再从这个我们的这个交付的流程图说起。
光是从这个流程上来说，要做到好的持续交付，至少你得满足以下：
- 你得有单元测试，不然单元测试这个过程将没有意义
- 你得接受自动化的代码审查，比如Sonar或ESLint，否则质量分析这个过程也没有价值
- 你得编写必要的文档，比如API文档，或者你在代码中编写足够的注释，你还能把Java Doc自动生成也加入这个交付过程
事实上，还有挺多的，想要一个好的，能对项目产生更大价值的持续交付，你得先做这些好的工程实践。
否则，你的持续交付最多只能做到从编译到生成二进制包，然后最多管理重启服务这个最简单的过程。
三）
详细说下我在编码中，是如何应用这些好的工程实践，以及用的哪些技术吧。
单元测试
在后端开发中，无论是Java Spring Boot还是Kotlin Vert.x，单元测试我都是用的JUnit Mockito
前端或跨平台桌面中，jest是我的选择。但不比后端，在前端或基于前端的跨平台桌面中，是否要针对UI层面做单元测试，我个人暂时认为必要性不高。
移动端虽然Android和iOS搞了几年，但没有应用TDD测试驱动开发。
质量分析
其实最好的是有团队的相互代码审查，在代码审查这件事情上，人还是比计算机的审查意义更大。
但这种依赖于团队技术文化，是另一个层面的事了。
而我通常会使用Sonar来分析代码质量，它会根据不同语言的一些规则，来分析你的代码，更重要是，它也能提供单元测试覆盖率的数据。
前端的话，开发中我会用ESLint。但ESLint有个不好的地方在于，开发人员可以自行修改ESLint的规则，或在文件中申明忽略某些规则的约束，这使得ESLint的约束力不具备强制性。
而Sonar的话，除了管理员能修改约束规则外，开发人员并无权限修改或忽略任何规则。
我知道，我们不一定能影响团队或公司，但是没关系，从自己做起就好了。这是我的myddd-vertx在sonar上的数据，我约束自己严格按照单元测试覆盖率不低于80%的要求，这也是我自己个人的所有项目的标准。
文档
文档其实是非常容易过时的，包括注释也好，API也好，经常出现的是代码改了文档不同步更新。
所以一般我也不主张过分关注文档，更反对开发前事无巨细的文档或设计工作，也就是满布的开发。
但我认为必要的文档仍然必不可少。
比如对于注释，要求接口或供外部调用的类及方法需要写清楚注释，而对于公开给其它人员使用的REST API等，则必须要有文档，不然难道依靠口述来传达么?
关于REST API这个，我使用的是OpenApi 3.0的标准，这个非常方便。
你只遵照一些OpenAPI 3的标准编写yml或json，就会有类似Swagger UI或Redoc来帮你处理UI方面的事。
持续交付
支持持续交付的工具其实挺多的，包括开源的Jenkins,travis等，Github也推出了Github Actions，Gitlab也有个类似的机制。
但我一直用的Jenkins。
我的持续交付是基于Jenins Pipeline而构建的，最主要它是开源免费的，非常适合公司或团队。
四）
好的工程实践越多，事实上就越容易产生高质量易于维护的代码，这是不言而喻的。
当然，很多公司或团队并不具备类似的技术氛围或文化，可能环境并不支持你去做这些事情，我觉得没有关系，先从你自己做起。
不要相信什么写单元测试会增加开发时间这种鬼话，这是压根没有去尝试过的，仅凭想当然，觉得要多做事所以时间更久。事实上，不写单元测试，后续的维护及技术债务，连带影响质量等带来的成本远远高于写单元测试带来的时间成本。
要相信，好的工程实践才是王道，这应该成为程序员的信仰。
下一篇，从零到一，构建你的持续交付流程（三）：持续交付流程的环境搭建
