【CICD】Why-What-How
上一章我们讲了现代化的软件生命周期管理方法论: DevOps。当然，既然是方法论，那么只是一种指导思想。在软件工程中，我们作为程序员更多的需要讲的是落地。而自动化就是实现DevOps的重要手段，其命名则为CICD。
CICD，全称 Continuous Integration; Continuous Deployment，中文译名为持续集成与持续分发。这个过程连接了我们从代码编写完毕到交付测试环节的整个链路。如果能够将CICD做好的话，研发同学则完全无需管理这一步，而只需要专注于业务实现即可。
如果作为读者的你在面临着开发完毕以后还要花费大量时间用于部署，或者碍于不明确的团队规范导致整体效率低下，那么我建议你可以好好学习一下本课程，学好CICD能够显著提升整体研发效率。如果你没有遇见或者尚未遇见类似的问题，那么也同样也建议你了解一下CICD。学会CICD也是学会一种解决问题的思路。
想象一下，如果提交了一段代码，软件会进行基本的测试用于检查一些低级问题，并发布到相关的平台并通知相关的测试同学，同时输出一份报告告知开发者此时修改对现有的代码造成了什么样的影响，而这一切都是自动化完成的，这是多么美妙的一件事啊。
好了，那么既然我们确定了我们为什么要学习CICD，以及CICD能够做什么。那么，我们该如何设计一个CICD机制呢？
我们先不讨论应该用什么样的技术，也不先讨论应该去如何实现，以及有什么技术难点 —— 一开始就过于关注细节容易让我们沉入思维误区。我们从整体的、宏观的视角上来看待这个问题：即我们的实际需求。
那么我们的实际需求是什么呢？这个需求也是DevOps核心目标，即让开发者专注于业务而不是流程。那么为了实现这个目的，我们想一想，在我们写完业务代码以后我们需要做些什么？
研发自测，发布，交付给测试同学进行测试，再根据测试同学的反馈进行迭代，团队内部进行代码code review，最终代码上线让用户可以看到结果。
可能不同的团队实现的细节有所不同，但是大方向应当是一致的。那么我们就需要CICD帮我们简化这些步骤，实现通过工具、规则等固定的方式来帮我们处理掉一些可能是重复性的工作。
那我们更近一步设计一下我们想要的CICD工具链应该能帮我们做到什么：
- 在研发自测阶段可以直接帮我们处理掉代码改动导致联动修改的其他部分——大部分研发同学只会关心改动到的部分，但不得不说程序是复杂的，一处修改可能被涉及到方方面面。所以我们需要编写单元测试用例来帮我们检查其他代码的正确性。以及每次都自动帮我们进行测试。
- 发布时候尽量减少流程，越是复杂的系统发布的链路越是漫长。我所遇见过最复杂的发布系统发布一次版本可能需要半小时到一小时才能发布完毕。如果相关工具链可以完善，那么每次我都能省下半小时的时间，更何况并不会只发布一次。
- 因为我们需要在发布完毕以后告知测试同学进行测试，那么带来的问题就是作为研发人员的我们必须关注发布的进度，然后在发布完毕后手动告知测试同学进行下一步。那么有没有可能工具可以自动帮我们完成这一步呢？甚至联动相关的项目管理应用可以帮我们直接推进到下一步，作为开发人员只需要关注可能出现的编译/发布错误就行了，而不需要关心代码提交后的结果 —— 开发人员的工作本就应当只需要关心代码的实现。
- 在团队代码的code review中，除了业务逻辑以外，最常见到的就是各种格式/拼写/语法等问题。如果我们用代码格式工具帮我们处理掉这些问题，那么在code review中我们就可以更加关注我们应当关注的问题。
- 最后，一切都准备就绪，就准备上线了。等等！你是不是打算加班到深夜然后等到夜深人静用户量最少的时候对系统进行升级？大部分的程序员都是这么想的。但是如果说我们可以通过自动化工具自动帮我们发版呢？设定定时任务，上下游自动发版。如果出现发布问题，代码自动回滚。如果出现逻辑问题，也只需要点一个按钮直接回滚。不要认为这是一件不可能的事情，因为我认识的一家海外的TOP互联网公司，他们的团队就是这么做的。
以上，我已经把CICD所能做的事情，整体的宏观架构已经展现给你看了。如果感到心动，向往这样自动化的生活，并开始隐隐对现在落后的手动作业开始感到厌恶的话，那么我们赶紧进入下一章节，我会带大家学会如何做到这样的流程。
