持续集成(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/
登录后评论
立即登录 注册