DevOps 的出现并非只是为了顺应开发人员和运维人员应该协同合作的理念，更大程度上，它是企业在走向现代化应用交付的过程中需要经历的文化转型。DevOps 的最终目标是能够更频繁地发布高质量的软件，并通过促进沟通和协作来实现这一目标。
Octopus Deploy 创始人兼首席执行官 Paul Stovell 说：“现如今，团队应该做出更快的改变。如果没有开发人员和运维人员成功合作，实现快速改变的机会几乎为零“。
CI/CD 管道是 DevOps 背后的推动力，这种推动力依赖 DevOps 的内聚性，并将其带入到现代软件的开发和交付当中。
来自 CA Technologies 的持续交付总经理 Jeff Scheaffer 说：“正在进行数字化转型的公司在面临组织变革时，DevOps 通常被认为是一剂良药，但 CI/CD 管道才是推动 DevOps 走向成功的引擎，帮助企业更快地交付更好的应用。这是企业从手动转向自动化、从单体应用交付转向现代应用交付的核心业务流程“。
OpsGenie 联合创始人兼工程副总裁 Sezgin Küçükkaraaslan 说，在讨论 DevOps 时经常会提到 CI/CD 管道，因为它在团队之间建立起了桥梁，并帮助他们看到了更大的蓝图，这个蓝图就是能够成功构建出软件系统，并交付给用户。
他说：“CI/CD 管道是将代码移交到生产环境最快的一种方式。开发人员能够通过自动化且不易出错的方式轻松地构建、打包、集成、测试和发布代码“。
Küçükkaraaslan 补充道，DevOps 专注于文化，而 CI/CD 管道则专注于能够帮助团队适应不断变化的文化的过程和工具。
Stovell 说，CI/CD 管道是 DevOps 的关键推动者，因为它消除了 DevOps 流程中的摩擦因素，从而可以更快地发生变化和投入生产。他还解释说，消除的摩擦越多，发生变更的周期就越短。“这意味着你正在推动业务向前发展，并创造出了一个反馈闭环以及持续改善的环境”。
如何保持管道的流动性
Mobile Labs 总裁兼首席执行官 Dan McFall 说，管道“实际上是发布流程自身的一个循环。它是一个持续的过程，包括编写代码、测试代码、部署代码、在生产环境中重新测试，然后再次完成对整个过程的反馈。这是实现高质量发布并持续运作一切的能力“。
如果能够从更宽泛的角度来思考管道，它将会让你看到更完整的生命周期，不仅包括了将软件交付到生产环境，还会看到它时如何交付的以及交付之后会发生什么。Stovell 说，如果事情失败了，你可以看到出了什么问题，并很容易进行恢复。
API Fortress 创始人 Patrick Poulin 说，CI/CD 管道中最重要的方面是 C，它代表持续性。为了在 CI 和 CD 方面获得成功，你必须“具备在不影响其他事情的情况下持续前进的能力”。
管道包含了一个发布阶段，首先你要知道自己要交付什么，然后进入测试阶段、预生产阶段、部署阶段，最后进入生产环境。来自 XebiaLabs 的首席产品官 Robert Stroud 说，这当然是一种经过简化的管道，它的基本思想是以自动的方式经过这些阶段或批准点。“目前业界存在几个切入点，我们将这些切入点交给开发团队、测试团队、阶段发布团队和部署团队，而只有自动化所有这些步骤和阶段才能真正加速整个过程。”
来自 CA 的 Scheaffer 说，之所以被形象化地称为管道，是因为在理想情况下，变更是从头到尾一个接一个地发生。
来自 OpsGenie 的 Küçükkaraaslan 说，从更高的层面来看，管道“包括在代码库合并之前进行的编译、打包和基本测试。将代码合并到主分支之后，将运行其他测试，以确保应用程序能够使用真实的配置和其他服务。性能和安全测试也在这个时候运行。随后就可以将代码部署到 staging 环境，然后再到生产环境“。
Scheaffer 说，保持管道的简单性、可见性和可衡量性是让管道奏效的最好方式。这里的关键因素包括管道的自动化和编排、改进、与利益相关者保持一致，以及对“好”的评估能力。
McFall 说，“DevOps 让你以渐进和可管理的节奏取得进展，让你能够在软件准备就绪时拥有更强的信心，并且确实交付了正确的东西。”
小心管道出现扭结
Scheaffer 说，管道应该是流动式的，不同的阶段可以同时发生。“例如，测试可以不需要等开发完成编码才开始进行。相反，测试可以与开发同时进行——与开发一起并行测试更小的代码块“。
Scheaffer 解释说，管道就像一根含有多级玻璃纤维的光缆。“每根玻璃纤维都可以代表单个应用程序的工作流，你可能会有许多不同的应用程序在管道中移动，而你需要做好协调工作”。
不过，同时运行多条线索很容易带来复杂性，所以不要让你的管道成为瓶颈。OpsGenie 的 Küçükkaraaslan 建议 DevOps 团队要不断监控所有组件，确保能够发现问题并尽快解决。
另外，他还解释说，团队应该密切关注测试性能。“大家都喜欢将新代码快速发布到生产环境，但如果没有经过正确的测试，这样做是非常危险的。系统相互依赖的复杂性意味着一切都有可能出错。监控测试环境中新代码的执行情况对于发布稳定的版本来说至关重要。所以，尝试在快速测试和模拟生产环境测试之间找到最佳平衡。“Stroud 说，拥有良好的测试套件和良好的测试覆盖率可以更好地了解部署了什么、部署在哪里和部署时间。
Küçükkaraaslan 解释说，CI/CD 管道不是一成不变的，它会随着时间推移而发生演化，团队和业务需要能够随着管道一起演化。
他说：“我们不断努力改善我们的 CI/CD 性能，并拥抱最佳实践。也就是说，我们一直在收集每个参与交付新功能的人的反馈意见，以便找到可以改进的地方。随着业务的发展，我们的 CI/CD 流程也必须跟着演化“。
McFall 说，如果你没有为 CI/CD 管道创建反馈循环，那么实际上你并没有在实施 DevOps。“建立反馈循环的好处是，它可以让你有更强的信心和更快的速度去做事情。”即使现在团队可以把所有东西都推到生产环境中，但这并不意味着他们应该一直这么做。这就是反馈循环发挥作用的地方，因为它确保你可以听到客户的意见，而不只是一直在推出新的东西。“请注意你的同事在做什么，他们的成功之处在哪里，以及是否有机会不要犯同样的错误“。
Scheaffer 建议我们远离快速修复方法。他说：“在生活中，快速取得胜利是很诱人的，但也是要付出代价的。在 CI/CD 管道中，它表现为技术债务，发展脚步停滞不前，其他团队无法参与进来，以及在组织内部对什么是’好’的东西理解不一致。其结果是要花费很多精力重建管道“。McFall 相信组织会不断试图找到一种适用于所有工具的方法，而实际上，他们真正需要做的是找出对他们的业务和风险状况有意义的事情。
Stroud 表示，要尽可能地利用自动化，但不要陷入自动化孤岛的局面。Stroud 解释说，目前管道中存在的一个常见问题是，企业的自动化并没有覆盖所有部门，因此存在自动化孤岛。“DevOps 的关键规则之一是我们需要在整个工具链中进行一致的协作，否则它就变成年轻玩家最大的陷阱之一”。组织可以通过标准化和合理化他们在每个孤岛中使用的工具来解决这个问题。
最后，不要陷入责备文化。Stroud 说，当事情失败时，关键的不是问责，而是想想如何能够做得更好，如何提高速度，以及如何交付更好的结果。“你希望人们试错，并从错误中学习。这必须成为 DevOps 的基本原则，而不是在发现部署的变更不符合要求之后对谁严加指责。借鉴这些经验或反馈，并在未来改变你的流程，这样你就可以持续创造价值。”
持续交付与持续部署
Stroud 说，尽管 CD 通常被称为持续交付，但一些组织正在将其视为持续部署。
现如今，软件变更在规模、性质和增量差异方面正逐渐缩小。这种变化使得团队能够达到可以自动部署的程度。Stroud 说：“现实情况是，我们最终按照迷你的速率进行部署。变更在瞬间就发生，可能是每周一次，某些组织会收集变更，并把它们组合在一起，然后按月部署。具体情况取决于业务和业务转型的意愿“。
为了跟上变化的速度，团队需要采用良好的部署方法，例如金丝雀发布。如果使用金丝雀发布，变更先被发布到一小组样本实例上，以便验证变更是否没有问题。如果使用蓝绿部署，就可以以一种可控的方式让不同的用户收到变更。开发者可以收到反馈，确保交付的东西符合要求。
Stovell 说，在部署软件时一个常见的错误是，团队编译代码并将其部署到测试环境中，而在进入生产环境时再次编译代码。“这不是一个好的做法，因为在你第二次编译代码时，会引入很多潜在的问题。你无法保证你测试过的东西就是最后进入生产环境的那个“。正确的做法是只构建一次，保留构建过程中生成的文件副本，然后将其部署到测试环境和生产环境中。
成功实现持续部署的另一种方式是为每个环境提供一致的流程。Stovell 说：“保证生产环境部署成功的最好方法就是确保生产环境的流程尽可能与其他环境保持一致。”
Küçükkaraaslan 说，部署管道的高级别视图被称为 DevOps 组装线。他说：“我们所要面临的挑战是，DevOps 工具链并不像 CI/CD 那样完善，并涉及到对人的依赖，因此可能会效率低下。DevOps 组装线尝试将活动连接到基于事件驱动的工作流程中，然后可以将这些工作流程与特定的应用程序或服务相关联。”
实现以 API 为主导的 DevOps 方法
API Fortress 创始人 Patrick Poulin 说，如果你将 CI/CD 管道视为一直在运行的软管，那么 API 测试就是拖慢流速的扭结。
API 测试已经成为 DevOps 开发过程中的一个痛点，因为它一直被忽视。他说：“这是人们一直在拖延的事情之一，因为可能不存在一种工具可以让这个问题变得容易解决，或者因为它需要大量的开发工作”。
如果团队没有测试这些 API，那么在错误发生时他们可能就捕获不到，或者需要数周时间才能发现错误，因为除非 API 完全不可用，否则他们将看不到任何问题。Poulin 说：“如果一直延续下去，可能会变成一个非常严重的错误，只因团队没有对其进行全面的测试”。
与自动化网站和应用程序测试相比，DevOps 团队需要在 API 测试中也投入同样的工作量。Poulin 说：“相比前端，API 也同样重要，API 涉及到公司系统的每个部分，因此对测试、可靠性和正常运行时间有足够的了解”。
团队应该要测试所有的 API，而不仅仅是测试单个端点。还要创建集成测试，也就是用于重现常见用户流程的多步骤任务。Poulin 解释说，你不仅需要对单个功能很了解，而且还需要知道它们在与其他功能或过程结合在一起时是如何工作的。“当你以真实的用户体验方式来测试你的东西，就会发现它们之间存在的差别”。
关键在于要找到一种工具或平台，让每个人都可以知道 API 的状态，比如我的 API 在运行中吗？昨天有没有出现 API 问题？Poulin 说：“如果你有适当的工具，任何人都可以通过几次点击就可以得到答案，并充分了解他们的 API 的健康状况”。
将基础设施引入管道
根据云管理解决方案提供商 TriNimbus 的首席技术官 Goran Kimovski 的说法，DevOps 和 CI/CD 管道有两个价值原则。第一个原则是不断整合代码变更，并按照一组定义好的测试标准进行测试。Kimovski 说，这是一个非常有吸引力的主张，因为你可以持续确保代码可以正常运行。第二个原则往往难以实现，那就是加速采用。Kimovski 解释说，开发人员编写的应用程序代码需要部署到某种基础设施上，但这一过程通常与手动变更管理流程相关联。
他说：“软件行业已经花了多年时间在单元测试以及像自动化集成测试、最终用户测试、性能测试这样的概念上，但测试基础设施的整体概念仍处于早期阶段，测试代码本身都很困难。”
Kimovski 说，这是因为开发人员需要调配和部署基础设施。而传统方案则包括实际的硬件或虚拟环境，要求传统的网络工程师、IT 运维和系统管理员了解相关技术，将硬件组合在一起，建立网络，创建虚拟机并将它们交给开发人员或 QA 去配置，然后再让其他人在上面部署应用程序。“这一过程需要由多人来处理，并依赖大量的体力劳动，不稳定或不可重复“。Kimovski 补充说，这不仅耗费时间，还会引入外部成本。
Kimovski 建议基于云来实现 CI/CD 管道。他说：“在云中配置一台服务器，运行 15 分钟后关闭，你只需要为此支付 15 分钟的费用。而在某个数据中心里配置服务器意味着你必须拥有物理硬件，这对你的业务而言是额外的成本。”另外，使用物理硬件来测试基础设施代码会有所限制，因为不是每个人都可以访问到它。他解释说，云将其大众化，并将其转化为运营成本。