不是吹牛，但我所治理的开发团队在软件开发速度上表现出色，可能高质量地编写代码，并在白噪声的陪伴下放弃高效。
但就像所有的故事一样，一开始并不是这样的，甚至相去甚远。咱们经验了工夫、沟通、单干、失败、胜利以及许多对于生产力的会议（有时很难堪，但它们帮忙咱们找出了困扰咱们的问题 …… 另外，我共事会制作他的拿手饼干，所以是双赢的）。接下来，我将间接跳入主题，与你分享我团队的成功经验。
首先，我会提供一些事实来为场景做铺垫：一名一般的开发人员在一天内均匀能够编写大概 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-appr…