CI/CD 的 3 个挑战

持续集成和交付帮助DevOps团队更快交付更高质量的软件。

但是所有的CI/CD实现起来都是相同的？

成功的CI/CD落地是什么样子？你是否知道在正确的方向上？

在这四章节中，我们谈谈CI/CD的模式化：挑战、影响、产出和解决方案。今天，我们将聚焦于DevOps挑战和形势，如果一套完整的CI/CD方法是你正在寻找的答案的话。

如果这些问题是你期待解决的，请继续关注第二部分，我们将深入探讨这些障碍如何影响SDLC的其他部分。

我面对的挑战是什么？

1、维护和集成成本，主要是人力成本

在整个IT预算中，很大一部分用于支持需要集成和维护复杂工具链的工程师团队。一个拥有1000名开发人员的企业公司可能需要多达40名工程师来维护DevOps工具链，而不是将这些资源用于交付业务价值。

2、开发被运维团队拖慢/阻塞

在一个未实现DevOps世界，最典型的挑战是鼓励开发团队通过发布新特性来提高创新速度。鼓励运营团队保持稳定性、正常运行时间和减少错误。开发速度越快，宕机和出错的机会就越大，因此这些团队自然会产生分歧。开发团队负责人通常没有足够吸引人的证据或激励让运维团队提高部署速度，反之亦然。

3、开发人员做运维工作

今天，团队和开发人员根据他们环境的能力而不是业务的需要来生成代码。

这些实践时看起来像什么？

很大一部分资源和预算用于重复的集成和维护。

团队被他们的工具孤立——每个团队都有他们最喜欢的工具，并且基于这些特定工具进行工作优化。由于缺乏透明互通，很难跨堆栈进行协作和故障排除。

代码有时根本无法投入生产

在代码被写出来到产生价值之间有一段时间。当出现问题或错误并需要发回给开发人员时，由于代码在他们脑中不再那么清晰（上下文切换），定位故障就变得困难了。他们必须停止当前项目的工作，并回到之前的代码进行故障排除。可能已经过了很长时间，代码在当前状态下已无法再次部署。除了浪费时间和金钱之外，这也会让开发人员因为看不到自己劳动成果而变得士气低落。

开发人员担心的是环境，而不是业务逻辑

环境依赖和配置分散了开发人员在他们更擅长的任务上的注意力。他们甚至可能会花时间来决定需要部署到多大的VM上。在这种情况下，DevOps意味着“开发人员必须同时做dev和ops工作”。只有一小部分开发人员真正喜欢这种安排，并且通常会说：“我是开发人员，请不要再让我做运维。”