CI 与 CD 有什么区别
CI, CD AND CD
CI很容易理解，就是持续集成。但是CD既可以指代码持续交付，也可理解为代码持续部署。CI和CD之间有很多相似的部分，但是也有很大的区别。
持续集成（CONTINUOUS INTEGRATION）
在持续集成环境中，开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证。这样做是基于之前持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。
持续交付（CONTINUOUS DELIVERY）
持续交付就是讲我们的应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试，我们还需要有自动化的发布流，以及通过一个按键就可以随时随地实现应用的部署上线。
通过持续交付，您可以决定每天，每周，每两周发布一次，这完全可以根据自己的业务进行设置。
但是，如果您真的希望体验持续交付的优势，就需要先进行小批量发布，尽快部署到生产线，以便在出现问题时方便进行故障排除。
持续部署（CONTINUOUS DEPLOYMENT）
如果我们想更加深入一步的话，就是持续部署了。通过这个方式，任何修改通过了所有已有的工作流就会直接和客户见面。没有人为干预（没有一键部署按钮），只有当一个修改在工作流中构建失败才能阻止它部署到产品线。
持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。基本上，当开发人员在主分支中合并一个提交时，这个分支将被构建、测试，如果一切顺利，则部署到生产环境中。
合并CI CD and CD？
当然，正如我所说，他们每部分都更加接近生产环境。你可以构建自己的持续集成环境，然后，一旦团队适应，你可以添加持续交付流，最后，可以添加持续部署流到整个工作流中。
举例CI, CD and CD 流水线
到底值不值这样做呢?
持续集成:
你需要具备哪些条件:
你的团队需要为每个新功能，代码改进，或者问题修复创建自动化测试用例。
你需要一个持续集成服务器，它可以监控代码提交情况，对每个新的提交进行自动化测试。
研发团队需要尽可能快的提交代码，至少每天一次提交。
你能获得什么呢？
通过自动化测试可以提早拿到回归测试的结果，避免将一些问题提交到交付生产中
发布编译将会更加容易，因为合并之初已经将所有问题都规避了
减少工作问题切换，研发可以很快获得构建失败的消息，在开始下一个任务之前就可以很快解决。
测试成本大幅降低-你的CI服务器可以在几秒钟之内运行上百条测试。
你的QA团队花费在测试上面的时间会大幅缩短，将会更加侧重于质量文化的提升上面。
持续交付
需要具备什么条件？
你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求
部署需要自动化。触发是手动的，但是部署一旦开始，就不能人为干预。
你的团队可能需要接受特性开关，没有完成的功能模块不会影响到线上产品。
你能收获什么？
繁琐的部署工作没有了。你的团队不在需要花费几天的时间去准备一个发布。
你可以更快的进行交付，这样就加快了与客户之间的反馈环。
轻松应对小变更，加速迭代
持续部署
需要具备的条件:
研发团队测试理念比较完善。测试单元的健壮性直接决定你的交付质量。
你的文档和部署频率要保持一致。
特征标志成为发布重大变化过程的固有部分，以确保您可以与其他部门（支持，市场营销，公关…）协调。
可以获得什么？
发布频率更快，因为你不需要停下来等待发布。每一处提交都会自动触发发布流。
在小批量发布的时候，风险降低了，发现问题也可以很轻松的修复。
客户每天都可以看到我们的持续改进和提升，而不是每个月或者每季度，或者每年。
如前所述，您可以采用持续集成，持续交付和持续部署。你怎么做取决于你的需求和你的业务情况。如果你刚刚开始一个项目，并且还没有客户，那么你就可以去创建这些工作流，最好是将这三个方面都实现，并且在你的项目迭代和需求增长中同时迭代它们。如果您已经有一个生产项目，那么您可以一步一步地分阶段去实现他们。