敏捷，持续集成/持续交付, DevOps 三者的区别

Posted 2023-05-10

参考技术A 以下这篇译文清晰明了地揭示了敏捷（Agile），持续集成/持续交付（CI/CD）和 DevOps 三者之间的区别和联系。它们尽管有所不同，但是彼此支持，相互联系。敏捷专注于开发过程，CI/CD 专注于实践，DevOps 专注于文化。

3种不同的开发工具可用于建立练习

您无法只用一个工具盖高楼大厦，您也不能一口气进行开发实践。敏捷，DevOps 和 CI/CD 是三个截然不同的工具，每一个工具本身都很重要。当开发团队将这三个功能用于其预期目的时，结果将具有变革性。

敏捷开发

敏捷专注于消除流程障碍，并使关键的利益相关者（如开发人员和客户）能够在加快交付速度方面进行更紧密的协作。敏捷强调了变革的持续性，并承认作为软件生产者，我们并不总是在一开始就了解在整体生命周期中，成功构思、开发和交付高质量软件所需的一切需求和资源。

因此，尽管在过去的二十年中敏捷的意义有所不同，但其基本原则仍然保持不变：消除赋予个人权力的流程障碍，迅速开发可运行的软件，与客户密切协作以及积极应对（而不是抵制）变化。

CI/CD

持续集成（CI）是一种软件工程实践，团队成员以越来越高的频率集成他们的工作。通过长久的 CI 实践，团队至少每天甚至每小时进行集成，以此接近“连续”程度的集成。

从历史上看，集成一直是一项昂贵的工程活动。因此，为避免项目遭受重创，CI 强调了驱动构建和测试的自动化工具。 CI 实现之后，构建和集成工作就会减少，团队也可以尽快检测到集成错误。

持续交付（CD）用于打包和部署 CI 要构建和测试的项目。实践 CD 的团队可以构建，配置和打包软件，并编排其部署方式，以便可以随时以软件定义的方式（低成本，高度自动化）将其发布到生产环境中。

由于软件更改更频繁地投入生产，高功能化的 CI/CD 实践直接促进了敏捷开发。因此，客户有更多机会体验产品变化并提供反馈。

DevOps 文化

DevOps 专注于敏捷开发过程中文化和角色的局限性。 DevOps 的目的是解决组织中过度专业化和不同部门人员沟通不畅导致的一些痛点，例如对生产问题无法快速甚至有效响应。DevOps 组织通过对每个团队进行彼此技能的交叉培训来打破运维和开发之间的障碍。这种方法提高了每个人欣赏和参与彼此任务的能力，并促进了更高质量的协作和更频繁的交流。

什么是 DevOps 中的 CI/CD？它们与敏捷有什么关系？

CI/CD，敏捷和 DevOps 与现实生活中的发展有何关系？工程团队通常从 CI 开始实践。 DevOps 可以帮助组织了解在整体生命周期甚至更长时间内软件所必需的配置，打包和编排--从而创建更有价值的持续交付实践。反过来，DevOps 中 CI/CD 的实践又增强了敏捷开发。

结论

区分敏捷，DevOps 和 CI/CD 最快速简便的方法：

敏捷专注于在加速交付的同时突出变化的过程。

CI/CD 专注于软件生命周期内强调自动化的工具。

DevOps 专注于强调响应能力的文化角色。

传统企业如何打造统一的持续集成平台

一、传统行业打造统一持续集成平台痛点

• 多团队维护多套工具链，重复任务多、运维成本高。
• 各团队交付流程不统一么，重复造轮子，知识经验无法共享。
• 各交付质量、标准不统一，难以形成统一的度量体系。
  

二、从零到一的解决方案

1.成立团队
该团队初期视公司技术人员规模，可由虚拟组或专属devops工程师组成。该需要具备下述能力：

• 对需求管理、敏捷有所了解，敏捷教练最佳。
• 各语言研发专家，制定静态代码检测标准，负责公司技术栈选型。
• 测试工程师，负责测试工具选型及集成。
• 运维人员对资源及部署能力及流程进行把控。
• 需要与安全团队联合，对源码安全及外部组件安全形成统一方案。
• 由技术运营负责持续集成平台建设成本及收益做评估。

2. 打造工具链
   由上述团队对工具链选型，对整个软件生命周期全流程进行工具链选型，选型可参考下图，工具能力要覆盖需求管理、开发、构建、测试、发布、部署、运维及监控等多个领域。

3. 解决持续集成平台在推广中遇到的问题

问题一：开发团队不配合怎么办？
答：构建统一的平台，为不同团队提供全方位的基础平台，减少开发团队自己的运维成本。晓之以情、动之以礼，如果仍然没效果，做详细的资源使用及度量痛点，自上而下调动研发团队配合。

问题二：开发团队担心学习新平台投入时间成本较高怎么办？
答：编写统一的持续集成模版，对开发人员模版化或桌面化提供持续集成服务，让开发人员通过简单的调用或拖拽就能实现复杂的持续集成流水线，不必要去学习大量的脚本语言。（如jenkins的sharelibrary）

问题三：开发团队不安规范使用怎么办？
答：回收持续集成平台权限，让外包或自有研发人员无法对构建模版进行修改，强制每一次持续集成要进行完整的测试和扫描步骤，保障每一个质量关卡都被触发。

4. 推广的方式
   试点团队先行：试点团队尽量选择关系比较好的、边缘业务团队，先行团队要尽量踩雷、快速反馈，验证工具链及管理方案的可行性，快速迭代工具链及模版内容。
   小范围试用：小范围试用是为了验证平台的通用性，保障平台能适配大多数技术栈。并在试用中持续接受各团队的反馈，持续迭代平台功能。同时要在该阶段定义度量指标及使用标准。
   集团推广：真正实现统一管理，并继续持续改进。

5. 持续集成过程中的元数据管理
   统一编写模版后需要在模版中强制收集软件生命周期各个工具链产生的数据，我们把这个数据称之为软件的元数据。元数据包括但不限于：需求id、开发者信息、构建环境、依赖组件、测试报告、静态扫描结果、安全扫描结果、部署信息等。最终这些数据将会作为评判此版本的质量关卡，确保每次交付都是高质量的交付。
   

6. 持续集成过程中的安全管理
   尽量做到安全扫描左移，在开发侧引入安全扫描，对外部依赖及源码做扫描，尽量避免漏洞在未被测试扫描情况下被引入到生产线上。这样不会造成高危漏洞在生产线上被发现而导致的整个开发迭代过程要重新进行的低效情景。

三，总结
打造传统企业统一的持续集成平台，需要专门的团队打造合适的工具链，并制定合理的规范及度量标准，最终通过不同的方式推广到整个集团。