借助Emoji表情，轻松理解CD的工作流程

持续集成(CI)和持续交付(CD)工具可通过质量保证实现快速高效的开发。使开发人员能够自动测试代码，自动打包，甚至还可以自动部署到生产环境中。

持续集成(CI)通过立即构建和测试代码来确保代码能够产生可部署的应用程序，从而自动执行代码更改。持续交付(CD)向前迈出了一步，并推动了应用程序进入部署阶段。

成熟的CI/CD系统，会监视源代码中的更改，自动构建和测试代码，然后将其部署到生产环境，在此过程中，它会通过各种测试来确定流水线是否继续或失败。

之前的文章中，我们分享了《借助Emoji表情，轻松理解CI的工作流程》。

本文，我们继续通过Emoji表情符号和比萨饼类比持续交付(CD)，以及解释它与持续部署的不同之处。

什么是持续交付(Continuous Delivery)？

CD 本质上将开发人员👩🏿‍🍳提交的每个功能代码🍅🧀都视为“版本发布的候选”🍕——在我们的比萨饼类比中，可以看作是将会被”吃掉”的潜在的“新比萨饼”。

除非功能代码🍅🧀被测试有缺陷，否则它会沿着自动部署流水线发送到指定环境。一旦我们的“候选比萨”通过测试🥄，它就会被整齐地装箱，然后被取走交付🛵，等待用户最后的评价。

简而言之，持续交付–其实就是开发人员写的代码推到代码库了，我们能够快速的，自动化的，稳定的将这个变更发布到各个环境中。

持续交付

CD中一个很好的例子，就是Spinnaker，它最初由 Netflix 开发。 Spinnaker 是基于云的 CD 平台，提供快速、可靠、稳定的软件变更服务。主要包含两类功能：集群管理（Cluster management）和部署管理（deployment management）。

Spinnaker也是一个开源的，多云的持续交付平台。一般来说，我们可能用Jenkins来完成CI/CD，但是你会发现，Jenkins要做CD的话，得需要去写代码，写一些插件来实现。相对来说，对我们每个人能力要求就比较高了，而且还得不断的去调试这个程序所写的兼容性问题，所以说目前来说，开源的CD平台的话，Spinnaker是功能最强大的。

Spinnaker可以使用或集成现有的 CI 工具(如 Jenkins)，还可以在 Git 中创建一个 webhook，决定当代码仓库变化时是否去触发Spinnaker的流水线去运行。Spinnaker里面支持很多种部署策略(蓝绿部署、金丝雀部署)，我们自己也可以去自定义部署策略。

持续部署(Continuous Deployment)是什么？适合什么场景？

除了CI/CD ，有时候你还听到了持续部署。它本质上与持续交付相同，不同之处在于它是一个从开始到结束完全自动化的流水线。正如你所料，持续部署并不适合所有用例，除非你相信你的自动化流程完全可靠。但是，如果正确实施，它可以为开发人员或运维人员节省更多的时间去做其他事情。

持续部署

通过自动化流程对候选版本进行全面测试后，持续部署会将其交付给客户。

完美的交付需要合适的CI/CD

很明显，集成、交付和部署是软件开发到发布流程中的不同阶段。那所谓的持续是相对于过去的流程提出的。过去的流程是所有人写好代码之后再进行合并，然后再进行测试，最后再发布。这种流程会把风险堆到软件发布前的最后阶段。那持续的概念就是，做一点就马上递交给下一个流程，这样能够尽早地发现并解决问题。

所以你可以看到，当 CI 和 CD 结合起来时，它通过尽可能地消除人为干预，可以让开发或优化的功能代码，在更短的时间内从开发环境部署到生产环境。这也能够很好地支持团队的敏捷开发流程。它通过集中控制，提供对性能的可见性，并准确地监控和标记问题。

在进行CI 和 CD选型时，你需要考虑几个不同的因素，例如避免使用无法扩展的脚本、要选择和基础架构集成的解决方案，也要避免过多的插件管理。

译文链接：https://thenewstack.io/ci-vs-cd-explained-by-emoji-part-2-continuous-delivery/