敏捷原则
最重要的是，敏捷是一种思维方式——一种思考软件开发过程的方式。
在敏捷的认识中，以交付可运行的软件为目标，相对于严格遵循一套合同要求的计划，拥抱变化和鼓励协作是实现这一目标的高效途径。
敏捷宣言中提出的原则扩展了这些价值观，并提供了将其付诸实践的技术。 这包括建立获权和协作的团队，并在频繁的迭代周期中交付有效软件，使团队能够应对变化。
理由很简单：如果您起初严格设定需求并完全按照计划交付，那么您将难以灵活地根据新信息以及用户环境和需求的变化调整正在构建的内容。 在敏捷方法中，要设立一个最终目标，并制定逐步实现该目标的具体细节。
使用 CI/CD 实现敏捷
这些敏捷原则为 DevOps 运动提供了依据，进而催生了 CI/CD 调查方法。
至少在早期，敏捷的重点是开发团队的工作，而 DevOps 将覆盖范围扩展到下游流程以及从代码编写到发布所涉及的工作。
DevOps 强调打破孤岛和跨团队协作以实现共同目标的重要性：也就是最终要将有效、实用的软件送到用户手中。 DevOps 实践持续集成、交付和部署的目标是在不影响质量的情况下加快软件交付。
持续集成环境将流程中尽可能多的步骤自动化，提供快速反馈构建，从而缩短向用户发布软件所需的时间。
鉴于敏捷和 DevOps 的历史，了解构建管道中涉及的元素当然也将帮助您以敏捷方式工作。 首先，推荐的 CI 实践“尽早和经常提交”鼓励您进行小批量工作。
将功能分解为更小的部分对于迭代构建和发布过程至关重要。 由于目的是确保任何提交都可以通过 CI/CD 工作流并有可能发布，因此每次提交都应该产生有效的结果。 所以，采用这种途径可以帮助您继续专注于交付工作软件。
敏捷和 DevOps 都强调协作和沟通的价值。 尽管 DevOps 最初的重点是开发和运营之间的协作，但其优势可以进一步扩展。
在您的构建管道中加入暂存环境并通过仪表板使每个构建中的更改可见，您可以与组织的其他部门（如营销、设计或安全团队）共享进度并征求反馈。
任何 CI/CD 管道的核心部分都是自动化测试，可提供代码更改的快速反馈并加强构建质量可靠性。 对每次提交运行自动化测试是确保您交付有效软件的重要步骤。
向用户发布软件的重要性经常在敏捷议程中位居前列，而 CI/CD 管道正是该原则的关键推动者。 发布过程中的自动化步骤使团队能够显著加快发布速度并以每天甚至每小时一次的频率部署更改，远高于编写宣言时的设想。
最后，持续反馈周期构成 CI/CD 管道的核心，使正在构建的软件和实现过程都能得到持续改进，同时加强敏捷原则，即团队应该定期反思进度并作出相应调整。 建立和倾听反馈周期将有助于建立宣言中倡导的可持续开发步伐。
建立敏捷组织
尽管实施 CI/CD 管道可以培养敏捷思维，但与自敏捷首次定义以来激增的各种敏捷框架和解决方案相比，它已不再是万能方案。
也就是说，CI/CD 调查方法中的一些常见反模式也可用作指标，表明组织并不像您希望的那样敏捷。
运行有效的构建管道和为持续集成环境采用敏捷原则的一个常见障碍是在发布流程中引入各种手动阶段。 这可能包括更改咨询委员会，或要求在新构建部署到生产（甚至是暂存）之前提供详细的更改通知和风险评估。
这些程序背后的意图通常是确保对发布有一定的监督和控制。 然而，这都显著减慢了过程并忽略了自动化测试制度的目的，也就是让您对构建充满信心。
使用指标展示 CI/CD 管道的稳健性有助于缓解顾虑。 同时，仪表板和自动通知可以减少大量手动工作，让利益相关者随时了解管道中的更改。
收尾工作
敏捷有时被误认为一套必须以特定方式应用的固定规则。 理解基本原理并将这些原则根据您的组织调整，同时注意反模式，可以让您培养敏捷持续集成思维。
采用 CI/CD 调查方法有助于将敏捷价值观付诸实践，并实现迭代开发周期和频繁发布的优势。