持续集成持续部署持续交付
如今，每个DevOps用户都知道CI / CD是一个概念。 CI代表持续集成，而CD通常可互换使用，以表示“持续交付”和“持续部署”。
他们都是同一件事吗？ 没有。
他们有共同的目标吗？ 是。
虽然两种做法看起来很相似，但两者之间还是有一条细线。 让我们探讨一下DevOps环境中这两个术语的含义。
持续交付与持续部署
持续集成涉及一系列步骤，这些步骤将自动执行以集成来自多个源的代码，创建构建并进行测试。 每次构建或一组代码通过测试时，都会自动将其部署到过渡环境中，在该环境中进行进一步的测试，例如负载测试和手动探索性测试。 根据项目交付要求，此过程可以重复几天。
持续交付可通过持续实施修补程序和反馈来帮助您构建完善的软件版本，直到最终您决定将其投入生产为止。 换句话说，持续交付涉及围绕向客户发布什么以及何时发布给客户的决策。 这构成了两者之间差异的基础。
在连续部署中 ，每项更改都会通过一条自动化管道，并且该应用程序的工作版本会自动推送到生产环境 。 它不涉及任何发布批准周期，项目团队需要确保每次更新，测试和发布代码时，它都能在客户端顺利运行。 当然，很大程度上取决于测试套件的质量。 通过连续部署，团队可以在任何一天部署多个软件，而不必为主要版本而费心。
连续交付通常涉及类似于生产的分段区域，在最终发行版中具有强制性的时间滞后。 这种滞后包括在将代码发布到生产环境之前，检查并手动接受代码中的更改。
相反，连续部署不需要暂存区域来手动检查和验证代码更改。 这是因为自动化测试已集成在开发过程的早期，并且在发行的所有阶段都将继续进行。
整合交付和部署以实现共同目标
作为开发人员，基于对CI / CD实践的信心，您可能会觉得自动化部署可能会带来风险或具有更多优势。 尽管如此，在某些情况下应用连续部署仍存在一些合法限制：
- 法规遵从性，市场营销决策或其他限制可能会阻止IT组织采用连续部署。
- 其他考虑因素，例如IT组织内DevOps流程的成熟度，也会影响自动化代码部署的决策。
对于连续交付，在将代码部署到生产中进行手动工作会延长交付时间。 但是，出于合理的原因，为什么对于某些企业而言，连续交付是更方便的选择。
持续交付为需要部署决策以权威的人工智能支持的组织提供了竞争优势。 它允许团队在准备就绪时交付新功能，与真实客户一起测试工作原型，并构建和发展更稳定，更具弹性的系统。
反过来，这减少了不断发展的产品和服务的成本，提高了产品质量并减少了团队的倦怠。
在某些情况下，交付和部署的概念并不像其他地方那样重要。 例如，如果您已经为库做出了贡献或创建了构件，则不太可能将其部署在正在运行的系统上。 换句话说，没有部署阶段。 您只需将代码推送到存储库中，以供其他应用程序使用。 同样，对于大多数Web应用程序，团队通常没有单独的构建和部署阶段，这意味着交付和部署阶段之间没有明显的区别。
但是，要自动化部署，您可以探索用于应用程序发行流程的高端工具。 ARO全面管理以下方面的软件版本：
- 应用包装
- 发行版本
- 数据库更新
- 服务器配置管理
- 行事历
- 前滚和回滚
- 安全访问
- 稽核
Jenkins和Ansible是市场上流行的CI / CD自动化工具。 这些工具和API的各种自定义设置可以嵌入附加功能并提高生产率。 组织还可以遵循蓝/绿部署，金丝雀部署 ， 功能标记等，以安全地自动化交付和部署过程。
正确地结合持续部署，持续交付将巩固DevOps管道的基础，并且是敏捷DevOps计划的核心。 它为测试和数据中心团队提供了自动将变更推向生产，获得即时反馈并缩短发布周期所需的工具，从而促进了敏捷实践。
这些较短的发布周期使您能够以最低的TAT交付最高的软件质量。 这成为在软件交付管道中实施CI / CD的唯一目的。 你能做到吗？ 否则，您需要使用CloudBees CodeShip之类的产品重新考虑，重新评估和发展。
开始使用CloudBees CodeShip。
额外资源
- 了解SaaS CI / CD的价值
- 获取CI / CD的初学者指南
- 阅读更多有关为什么DevOps 不会成为新的Web 2.0的信息
持续交付与持续部署之间有一条很好的界限。 通过@codeship了解与@ethangj的区别
持续集成持续部署持续交付
628
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
