CI,CD理解

一.什么是CI,CD

​ 当咱们在谈论现代的软件编译和发布流程的时候，常常会听到CI 和CD这样的缩写短语。CI很容易理解，就是持续集成。

​ 可是CD既能够指代码持续交付，也可理解为代码持续部署。CI和CD之间有不少类似的部分，可是也有很大的区别。

它们之间的区别和联系。

1. 持续集成（CONTINUOUS INTEGRATION）
在持续集成环境中，开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线以前，都须要经过编译和自动化测试流进行验证。这样作是基于以前持续集成过程当中很重视自动化测试验证结果，以保障全部的提交在合并主线以后的质量问题，对可能出现的一些问题进行预警。

2. 持续交付（CONTINUOUS DELIVERY）
持续交付就是讲咱们的应用发布出去的过程。这个过程能够确保咱们尽量快的实现交付。这就意味着除了自动化测试，咱们还须要有自动化的发布流，以及经过一个按键就能够随时随地实现应用的部署上线。经过持续交付，您能够决定天天，每周，每两周发布一次，这彻底能够根据本身的业务进行设置。

可是，若是您真的但愿体验持续交付的优点，就须要先进行小批量发布，尽快部署到生产线，以便在出现问题时方便进行故障排除。

3. 持续部署（CONTINUOUS DEPLOYMENT）
若是咱们想更加深刻一步的话，就是持续部署了。经过这个方式，任何修改经过了全部已有的工做流就会直接和客户见面。没有人为干预（没有一键部署按钮），只有当一个修改在工做流中构建失败才能阻止它部署到产品线。

持续部署是一个很优秀的方式，能够加速与客户的反馈循环，可是会给团队带来压力，由于再也不有“发布日”了。开发人员能够专一于构建软件，他们看到他们的修改在他们完成工做后几分钟就上线了。基本上，当开发人员在主分支中合并一个提交时，这个分支将被构建、测试，若是一切顺利，则部署到生产环境中。

合并CI CD and CD？
固然，正如我所说，他们每部分都更加接近生产环境。你能够构建本身的持续集成环境，而后，一旦团队适应，你能够添加持续交付流，最后，能够添加持续部署流到整个工做流中。

cd

举例CI, CD and CD 流水线

二.到底值不值这样作呢?

持续集成:

• 你须要具有哪些条件:

你的团队须要为每一个新功能，代码改进，或者问题修复建立自动化测试用例。
你须要一个持续集成服务器，它能够监控代码提交状况，对每一个新的提交进行自动化测试。
研发团队须要尽量快的提交代码，至少天天一次提交。

• 你能得到什么呢？:

经过自动化测试能够提前拿到回归测试的结果，避免将一些问题提交到交付生产中
发布编译将会更加容易，由于合并之初已经将全部问题都规避了
减小工做问题切换，研发能够很快得到构建失败的消息，在开始下一个任务以前就能够很快解决。
测试成本大幅下降-你的CI服务器能够在几秒钟以内运行上百条测试。
你的QA团队花费在测试上面的时间会大幅缩短，将会更加侧重于质量文化的提高上面。

持续交付

• 须要具有什么条件？:

你须要有强大的持续集成组件和足够多的测试项能够知足你代码的需求
部署须要自动化。触发是手动的，可是部署一旦开始，就不能人为干预。
你的团队可能须要接受特性开关，没有完成的功能模块不会影响到线上产品。

• 你能收获什么？:

繁琐的部署工做没有了。你的团队不在须要花费几天的时间去准备一个发布。
你能够更快的进行交付，这样就加快了与客户之间的反馈环。
轻松应对小变动，加速迭代

持续部署

• 须要具有的条件:

研发团队测试理念比较完善。测试单元的健壮性直接决定你的交付质量。
你的文档和部署频率要保持一致。
特征标志成为发布重大变化过程的固有部分，以确保您能够与其余部门（支持，市场营销，公关…）协调。

• 能够得到什么？:

发布频率更快，由于你不须要停下来等待发布。每一处提交都会自动触发发布流。 在小批量发布的时候，风险下降了，发现问题也能够很轻松的修复。 客户天天均可以看到咱们的持续改进和提高，而不是每月或者每季度，或者每一年。 如前所述，您能够采用持续集成，持续交付和持续部署。你怎么作取决于你的需求和你的业务状况。若是你刚刚开始一个项目，而且尚未客户，那么你就能够去建立这些工做流，最好是将这三个方面都实现，而且在你的项目迭代和需求增加中同时迭代它们。若是您已经有一个生产项目，那么您能够一步一步地分阶段去实现他们。