持续集成、持续交付和持续部署实施涵盖了软件的广泛自动化可能性。本文将概述这三个原则、它们可以为您的工程效率带来的好处以及潜在的挑战。持续集成管道是采用 CI/CD 流程的第一步。
什么是持续集成？
持续集成 (CI) 是一种软件开发实践，当工程团队将代码更改合并到共享的源代码控制存储库（例如 GitHub、GitLab 和 Bitbucket）时，会自动执行构建、测试和集成。使用 CI 流程有助于及早识别和修复错误，提高应用程序的整体稳定性，验证集成，并最终提高工程和产品利益相关者的信心。
强大的 CI 管道支持扩展工程团队并提高功能和错误开发速度。CI 在开发团队中促进一种文化，将小的、迭代的更改跨多个团队并行合并到应用程序代码库中，从而降低代码冲突的风险以及在可扩展、高效和可重复的过程中合并的风险。
持续集成环境
CI 管道还可以包括对共享 CI 环境的应用程序部署。开发团队可以使用 CI 环境为业务利益相关者测试和演示即将推出的功能。如果开发之外的利益相关者没有这种能力来参与他们产品中即将推出的功能，那么工程和更广泛的组织之间可能会有一种孤立感。共享的 CI 环境可以帮助减轻这些感觉，并通过改进的反馈循环建立更富有成效的关系。
仅这些好处就足以证明对 CI 部署的投资是合理的；然而，在许多现代软件项目中，应用程序的基础架构在代码中进行管理，通常称为基础架构即代码 (IaC)。因此，在部署 CI 环境时，管道还可以在部署过程中与应用程序一起应用对基础设施的更改。
将这些基础架构更改部署为 CI 管道的一部分可确保自动化测试验证更新的基础架构及其支持的功能，从而为每次更新提供最大的信心。
通过“拉取请求构建”升级
拉取请求构建通常与工程团队将代码更改接受到中央存储库时运行的过程相同。但是，不是等到该功能在 CI 中可用，而是根据建议的更改执行管道。拉取请求构建具有 CI 的所有优势（运行构建、测试和部署）。它还允许工程师、测试人员和产品所有者在更改到达中央存储库之前对其进行审查和测试。拉取请求构建具有在开发生命周期的早期执行的优势，从而减少返工和补救性错误修复的需要，否则这些错误会在 CI 之后被发现，最终提高您对功能开发的信心。
持续交付更进一步
持续交付涵盖所有 CI 流程并对其进行扩展，从而使每个构建都准备就绪并准备好部署到生产环境。这些构建不会自动部署到生产中，需要手动批准流程。由于构建部署取决于团队决策，因此并非所有构建都会投入生产。
持续交付需要一种机制来支持在不影响客户的情况下将不完整的功能部署到生产中；这就是功能切换（有时称为功能标志）走到最前沿的地方。
什么是功能切换？
有多种类型的功能切换（或功能标志）可用于控制应用程序功能和操作问题。然而，对于这个主题，我们将重点关注那些用于支持发布的不完整功能代码。
这些功能切换允许开发人员控制是否在应用程序中启用功能。例如，工程团队在开发阶段添加功能切换，可以在开发环境中启用以进行测试，而在生产环境中禁用。完成和验证后，可以在生产中启用功能切换，而无需更新部署，如果功能出现意外行为或损坏，则可以禁用功能切换，从而减少对客户的影响。
持续部署，最后一块拼图
持续部署 (CD) 是开发操作的最终目标，建立在持续交付的基础上。合并到应用程序代码库中的每个更改都会自动部署到生产环境中，无需批准或手动步骤。
CD 需要强大的工程纪律，以确保通过手动检查（在代码审查阶段）和 CI 过程中的自动测试来测试和验证每个构建。这些准则与功能切换相结合，导致应用程序更改立即交付，减少了客户的反馈循环，并使开发团队能够快速有效地满足业务需求。
企业在采用 CI/CD 时面临的挑战
虽然 CI/CD 的好处似乎显而易见，但企业开发组织在建立良好流程的过程中可能面临重大挑战。因此，如果没有同时满足技术和业务需求并得到所有相关利益相关者支持的完善解决方案，利益相关者永远不应该开始实施 CI/CD 管道。
安全与合规
将安全性和合规性纳入 CI/CD 管道通常是主要障碍。虽然可以将一系列安全测试（例如静态或动态分析）集成到 CI/CD 管道中的各个阶段，但情况并非总是如此。必须使用人工检查和批准。
为了帮助解决这些挑战，可以将无法自动合并到 CI/CD 管道中的外部手动检查添加为管道本身内的明确批准步骤。与电子邮件链或其他外部审批流程不同，审批步骤会停止管道流程，直到相应的业务部门完成手动检查并批准为止。此批准和支持文档将与测试的应用程序构建隐式关联。
从长远来看，DevOps 可以投资于工具或流程，以在可能的情况下取代手动步骤，以实现持续部署流程。
管理不完整或未经测试的功能
如前所述，CD 需要能够在不影响最终用户的情况下将不完整或未经测试的功能交付生产。如果没有此功能，则必须先完成并测试所有新功能，然后才能将构建视为生产就绪。这可能成为一个严重的瓶颈，尤其是在具有多个开发团队的产品上。功能切换是一种标准的开发实践，用于禁用这些正在运行或未经测试的功能，确保它们不会影响最终用户。
产品工程团队可以在应用程序代码库中开发特性切换功能，或者集成许多现成的特性切换服务之一。
不完整或不一致的测试
CD 的基本原则之一是每个构建都被认为可部署到生产环境中。只有当应用程序具有足够强大和可靠的测试（单元、集成、安全、性能）以提供重要的应用程序覆盖率时，才有可能进行生产就绪构建。
当应用程序没有测试能力来提供足够的信心作为转向 CD 的一部分时，需要改进测试并更新开发过程，以便新的开发包括所有测试要求。
从速度到发布质量的文化转变
CD 为工程团队带来了额外的要求和纪律，意味着每个构建都已准备好部署到生产环境中。维持此质量标准所需的额外任务和审查时间最初可能会影响感知的开发速度，从而导致产品利益相关者的反对。
从长远来看，拥有强大的 CD 管道将使产品能够更快地发布功能和修复错误，尽管速度有所下降。体验长期利益将有助于缓解整个企业的生产力问题。
管理多个管道和复杂的构建
大型企业产品可能有许多现有的跨多个团队的复杂工作流和流程。为像这样的企业级应用程序迁移到 CI/CD 所需的工作和资源是巨大的，并且需要所有相关团队之间的协作方法。
企业必须确保将遗留产品迁移到 CI/CD 的好处大于成本（时间和金钱）。即使在这种情况下，从小处着手并逐步迁移产品（或多个产品）也可以提供继续下去的信心和胃口。
结论
采用持续部署流程和文化将提高应用程序的稳定性和质量，以及开发团队的生产力，从而使客户和利益相关者更加满意。
有许多解决方案可以提供此处讨论的部分或全部 CI/CD 流程，例如Vercel、Netlify、CloudBees CI、TravisCI、CircleCI、Jenkins、Bamboo、Teamcity和AWS。
为了帮助您选择最适合您的业务的 CI 工具，UranPlus 拥有丰富的经验和专业知识，可以帮助您跨任何这些平台设置功能齐全的 CD 管道。
