解决流水线瓶颈、提升编码效率的五个方法（上篇）

不是吹牛，但我所管理的开发团队在软件开发速度上表现出色，能够高质量地编写代码，并在白噪声的陪伴下保持高效。

但就像所有的故事一样，一开始并不是这样的，甚至相去甚远。我们经历了时间、沟通、合作、失败、成功以及许多关于生产力的会议（有时很尴尬，但它们帮助我们找出了困扰我们的问题......另外，我同事会制作他的拿手饼干，所以是双赢的）。接下来，我将直接跳入主题，与你分享我团队的成功经验。

首先，我会提供一些事实来为场景做铺垫：一名普通的开发人员在一天内平均可以编写大约 100 行代码。这已经是相对高效的开发人员的产出了。有些开发人员每天可能只产出五行或十行代码。考虑到一个手机应用程序大约包含 5 万行代码，所以这并不是一个特别高的数字。如果程序员每周只能生产出几百行代码，那么编写一个应用程序会需要很多很多开发工作日。

这就是为什么开发团队需要不断地寻找加速代码生产的方法。他们需要克服减缓软件开发的瓶颈，然后找到一些工具和流程，解决他们在持续编写和部署应用程序时面临的挑战（这就是我们在吃饼干的会议中讨论的内容）。

现在，我们都知道，要实现这一目标，持续集成（CI）流水线是一个很好的起点。尽管导致代码生产时间超过预期的原因有很多，但初始化、配置和执行 CI 流水线时出现的问题却是最常见的。开发人员在设置和管理 CI 流水线或解决构建失败的问题上花费的时间越多，他们完成主要工作（编写创新代码）的时间就越少。此外，能够花更多时间编写代码，而不是与 CI 工具纠缠不清的开发人员往往更加幸福。

这是最重要的一点，因为这是让开发人员快乐的原因。他们希望编写有意义的代码，为最终结果做出贡献，无论代码是否支持更好的用户体验（谁没有经历过一个不能提供所需功能的应用程序的愤怒），或是增加安全性（以便任何人都可以放心使用您的软件，包括您的祖父母），或者因为写得精巧收获了一众粉丝的崇拜。

大多数程序员选择他们的职业是因为他们喜欢写代码，而不是因为他们喜欢手动设置软件，也不是因为他们喜欢在 CI 日志中查找为什么构建时间超出预期。

好了，背景故事说够了，我将开始分享我在解决软件交付生命周期中的那一部分“机器”的经验——流水线。

我们都知道，一个结构良好的 CI 流水线可以确保开发人员快速高效地编写、集成和构建新的应用程序代码。然而，设置一个高效的 CI 流水线可能会是一项繁重的工作。特别是在需要启动多个流水线的情况下，每个流水线都需要稍微不同的配置。如果开发人员必须从头开始设置每个 CI 流水线并手动调整它，他们可能会在编写第一行代码之前，就花费数周的时间来初始化流水线。如何在这里运用“避免重复原则（Do not repeat yourself，也被称为 DRY 软件开发原则）”呢？反复做同样的事会令人沮丧，尤其是越做离目标反而越远的时候。

确保流水线配置符合组织标准或法规要求只会让问题变得更加复杂。对于开发人员来说，了解他们的流水线需要满足哪些标准都有点难，更别说以有效的方式实施这些标准了。

所以，在这里，我列出了采用的部分功能，来帮助我们解决流水线挑战。此篇文章是第一篇，会带来其中两个挑战的解决方案。在系列文章的最后，我还会添加我们选择的解决方案。

我们所面临的挑战是相当普遍的，我们选的解决方案解决了这些问题，并且提供了可衡量的成功，让每个人都很开心，包括首席执行官，他居然笑了。希望你也能在其中找到自己面临的挑战，并找出适合的解决方案。

挑战 1：缓慢的流水线初始化（也就是我们避免 DRY 的过程）

流水线模板和流水线模板目录在这里起到了关键作用，避免了在创建流水线时重复操作。这些功能让 CI 管理员和开发团队以模板的形式定义标准流水线配置。在创建了这样的模板之后，管理员或开发人员可以通过配置流水线模板目录将其共享给整个企业。该目录会根据团队的不同，将流水线模板组织成不同的组。后端有一组与前端不同的模板可供选择。所有这些模板都在一个地方进行维护，并且可以让团队自动地抓取和部署。

通过使用流水线模板和模板目录，开发人员在初始化流水线时节省了大量时间和精力，而且在确定如何配置流水线以满足特定于域的要求时，猜测也大大减少。

挑战 2：自定义 CI 配置（又名灵活性，为了满足特殊需求）

虽然在多个项目和开发团队中，模板是简化流水线初始化的有效方法，但一个流水线适合某个团队，也不一定适合别的团队。这意味着配置需要灵活，满足现在和以后的需求。

例如，我曾经有一个团队喜欢某个集成工具，但它没有内置到我们的 CI 配置中。我们需要一种方法，既能让他们自定义配置，又能符合我们经过测试和批准的 CI 配置。该怎么办呢？我当然不会阻挡开发人员想要这个工具来提高生产力的愿望。

为了解决这个问题，我们首先让每个开发人员对 CI 流水线拥有完全的管理员权限。这解决了允许开发人员自定义配置的挑战。随后我们发现这种方法存在问题，因为这导致了混乱和不符合规范。如果单个开发人员可以在没有监督或控制的情况下，部署他们想要的任何插件或配置更改，那么团队最终可能会得到违反企业或监管标准的流水线，甚至可能导致不稳定性。我们需要一起解决这个问题。

对我们来说，更好的解决方案是利用配置即代码（Configuration as Code，简称 CasC），它提供了一个可管理的基于 Git 的工作流，让开发人员可以请求 CI 配置更改，并在应用更改之前使用自动化测试进行验证。具体流程如下：

• 当开发人员想要更改托管控制器（例如 Jenkins®实例）的配置时，开发人员会在 Git 上发出拉取请求；

• 拉取请求触发新的托管控制器实例，其中将自动测试配置更改；

• 如果测试通过，拉取请求将合并到目标托管控制器的主分支中，以便更改生效。

这种方法解决了两个关键挑战。首先，它提供了一个自助式的自动化过程，开发人员可以通过该流程请求 CI 配置更改，无需面对机构官僚主义或追踪管理员以请求更改。其次，基于 Git 的方法可以确保在应用配置更改之前，对其进行了适当的测试和验证。通过这种方式，开发团队就可以避免引入导致流水线不稳定或不达标的更改的风险。开发人员也可以拥有他们所期望的个性化设置和稳定性。

下一篇文章，我们将为您带来余下三个挑战的解决方案，包括排查流水线执行问题、管理流水线依赖关系以及构建基础设施使用效率低下。并且，在下期文章的末尾，作者会给出她选择的解决方案——一次解决这五种挑战的核心武器，敬请期待！

作者：萨曼莎·弗罗斯特（Samantha Frost），CloudBees 公司产品营销经理。

文章来源：https://www.cloudbees.com/blog/lets-get-back-to-coding-5-approaches-to-solving-pipeline-bottlenecks