使用一条 CI/CD 流水线管理所有的产品
流水线 CI CD

> 
> 统一的持续集成与持续交付的流水线的构想是一种梦想吗？
> 
> 
> 


![](/data/attachment/album/202007/07/224752iib7xgh7icr8478f.jpg)


当我加入 WorkSafeBC 负责云端运维和工程流程优化的云端运维团队时，我和大家分享了我的梦想，那就是一个工具化的流水线，每一个产品都可以持续集成和持续交付。


根据 Lukas Klose 的说法，<ruby> <a href="https://continuingstudies.sauder.ubc.ca/courses/agile-delivery-methods/ii861">  流程 </a> <rt>  flow </rt></ruby>（在软件工程的语境内）是“软件系统以稳定和可预测的速度创造价值的状态”。我认为这是最大的挑战和机遇之一，特别是在复杂的新兴解决方案领域。我力求通过一种持续、高效和优质的解决方案，提供一种持续交付模式，并且能够构建正确的事物让我们的用户感到满意。想办法把我们的系统分解成更小的碎片，这些碎片本身是有价值的，使团队能够渐进式地交付价值。这需要业务和工程部门改变思维方式。


### 持续集成和持续交付的（CI/CD）流水线


CI/CD 流水线是一种 DevOps 实践，用于更频繁、一致、可靠的地交付代码变更。它可以帮助敏捷开发团队提高**部署频率**，减少**变更准备时间**、**变更失败率**和关键绩效指标（KPI）的**平均恢复时间**，从而提高质量并且实现更快的交付。唯一的先决条件就是坚实的开发流程、对质量的心态和对需求从构想到废弃的责任心，以及一个全面的流水线（如下图所示）。


![Prerequisites for a solid development process](/data/attachment/album/202007/07/224842j18g88t8ptlt8z3m.png "Prerequisites for a solid development process")


它简化了工程流程和产品，以稳定基础架构环境；优化工作流程；并创建一致的、可重复的、自动化的任务。正如 Dave Snowden 的 [Cynefin Sensemaking](https://en.wikipedia.org/wiki/Cynefin_framework) 模型所说的那样，这样就允许我们将复杂不可解决的任务变成了复杂可解决的任务，降低了维护成本，提高了质量和可靠性。


精简流程的一部分是将 <ruby> <a href="https://www.lean.org/lexicon/muda-mura-muri">  浪费实践类型 </a> <rt>  wasteful practice types </rt></ruby> Muri（过载）、Mura（变异）和 Muda（浪费）的浪费降低最低。


* **Muri（过载）**：避免过度工程化，避免与商业价值不相关的功能以及过多的文档。
* **Mura（变异）**：改善审批和验证流程（比如，安全签批）；推动 <ruby> <a href="https://en.wikipedia.org/wiki/Shift_left_testing">  左移提前 </a> <rt>  shift-left </rt></ruby> 策略以推行单元测试、安全漏洞扫描与代码质量检查；并改进风险评定。
* **Muda（浪费）**：避免技术债、错误或前期的详细文档等浪费。


看起来 80％ 的重点都集中在提供一种可以集成和协作的工程产品上，这些系统可以采用一个创意和计划、开发、测试和监控你的解决方案。然而，一个成功的转型和工程系统是由 5％ 的产品、15％ 的过程和 80％ 的开发人员组成的。


我们可以使用的产品有很多。比如，Azure DevOps 为持续集成（CI）、持续交付（CD）和可扩展性提供了丰富支持，并与 Stryker、SonarQube、WhiteSource、Jenkins 和 Octopus 等开源集成和商用成品（COTS）软件即服务（SaaS）进行集成。对于工程师来说，关注产品总是一种诱惑，但请记住，它们只是我们旅程的 5%。


![5% about products, 15% about process, 80% about people](/data/attachment/album/202007/07/224912njddunhzhyuayzyd.png "5% about products, 15% about process, 80% about people")


最大的挑战是打破数十年的规则、规定和已经步入舒适区的流程：“*我们一直都是这样做的；为什么需要改变呢？*”


开发和运维人员之间的摩擦导致了各种支离破碎的、重复的、不间断的集成和交付流水线。开发人员希望能访问所有东西，以便持续迭代，让用户使用起来和持续地快速发布。运维人员希望将所有东西锁起来，保护业务、用户和品质。这些矛盾在不经意间导致了很难做到一种自动化的流程，进而导致发布周期晚于预期。


让我们使用最近的一次白板讨论中的片段来探索流水线。


想要支持流水线的变化是一项困难并且花费巨大的工作；版本和可追溯性的不一致使得这个问题变得更加复杂，因此不断精简开发流程和流水线是一项挑战。


![Improving quality and visibility of pipelines](/data/attachment/album/202007/07/224923qy3odty04g4yzn5g.png "Improving quality and visibility of pipelines")


我主张一些原则使得每个产品都能使用通用流水线：


* 使一切可自动化的东西都自动化
* 一次构建
* 保持持续集成和持续交付
* 保持持续精简和改进
* 保持一个构建的定义
* 保持一个发布流水线的定义
* 尽早、频繁地扫描漏洞，并且*尽快失败*
* 尽早、频繁地进行测试，并且*尽快失败*
* 保持已发布版本的可追踪和监控


但是，如果我要打破这些，最重要的原则就是*保持简单*。如果你不能说明流水线化的原因（是什么、为什么）和过程（如何），你或许是不了解自己的软件过程的。我们大多数人想要的不是最好的、超现代的和具有革命意义的流水线 —— 我们仅仅是需要一个功能强大的、有价值的和能促进工程的流水线。首先需要解决的是那 80% —— 文化、人员和他们的心态。请你的 CI/CD 骑士们穿上闪亮的盔甲，在他们的盾牌上贴上 TLA（<ruby> 两个/三个字母的缩写 <rt>  two/three-lettered acronym </rt></ruby>）符号，加入到实践和经验工程的力量中来。


### 统一流水线


让我们逐步完成我们的白板会议实践。


![CI build/CD release pipeline](/data/attachment/album/202007/07/224942byvjt49x94zqjfhh.png "CI build/CD release pipeline")


每个应用使用一套构建定义来定义一个 CI/CD 流水线，用来触发*拉取请求的预合并验证*与*持续集成*的构建。生成一个带有调试信息的*发布*的构建，并且将其上传到 [符号服务器](https://en.wikipedia.org/wiki/Microsoft_Symbol_Server)。这使开发人员可以在本地和远程生产环境进行调试，而在不用考虑需要加载哪个构建和符号，符号服务器为我们施展了这样的魔法。


![Breaking down the CI build pipeline](/data/attachment/album/202007/07/225011ee1vpjlv1r1hjwrr.png "Breaking down the CI build pipeline")


在构建过程中进行尽可能多的验证（*左移提前*），这允许开发新特性的团队可以尽快失败，不断的提高整体的产品质量，并在拉取请求中为代码审核人员提供宝贵证据。你喜欢有大量提交的拉取请求吗？还是一个带有少数提交和提供了漏洞检查、测试覆盖率、代码质量检查和 [Stryker](https://stryker-mutator.io/) 突变残余等支持的拉取请求？就我个人而言，我投后者的票。


![Breaking down the CD release pipeline](/data/attachment/album/202007/07/225030gxma3a66the4ewem.png "Breaking down the CD release pipeline")


不要使用构建转换来生成多个特定环境的构建。通过一个构建实现*发布时转换*、*标记化*和 XML/JSON 的*值替换*。换句话说，*右移滞后*具体环境的配置。


![Shift-right the environment-specific configuration](/data/attachment/album/202007/07/225047zi8z8pgf3sfr8nss.png "Shift-right the environment-specific configuration")


安全存储发布配置数据，并且根据数据的*信任度*和*敏感度*，让开发和运维都能使用。使用开源的密钥管理工具、Azure 密钥保险库、AWS 密钥管理服务或者其他产品，记住你的工具箱中有很多方便的工具。


![Dev-QA-production pipeline](/data/attachment/album/202007/07/225059w67gtmnw8mf7yrv8.png "Dev-QA-production pipeline")


使用*用户组*而不是*用户*，将审批人管理从跨多个流水线的多个阶段移动到简单的组成员。


![Move approver management to simple group membership](/data/attachment/album/202007/07/225128qst8gs1tsb05eez6.png "Move approver management to simple group membership")


创建一条流水线并且对赋予特定的交付阶段的权限，而不是重复流水线让团队进入他们感兴趣的地方。


![Pipeline with access to specific delivery stages](/data/attachment/album/202007/07/225144jf5inb5sktyk0bgi.png "Pipeline with access to specific delivery stages")


最后，但并非最不重要的是，拥抱拉取请求，以帮助提高对代码仓库的洞察力和透明度，增进整体质量、协作，并将预验证构建发布到选定的环境，比如，开发环境。


这是整个白板更正式的视图。


![The full pipeline](/data/attachment/album/202007/07/225211c6x1o9b0lapz2a49.png "The full pipeline")


所以，你对 CI/CD 流水线有什么想法和经验？我的通过*一条流水线来管理它们*的这个梦想是空想吗？




---


via: <https://opensource.com/article/19/7/cicd-pipeline-rule-them-all>


作者：[Willy-Peter Schaub](https://opensource.com/users/wpschaub/users/bclaster/users/matt-micene/users/barkerd427) 选题：[lujun9972](https://github.com/lujun9972) 译者：[chunibyo-wly](https://github.com/chunibyo-wly) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
When I joined the cloud ops team, responsible for cloud operations and engineering process streamlining, at WorkSafeBC, I shared my dream for one instrumented pipeline, with one continuous integration build and continuous deliveries for every product.

According to Lukas Klose, [flow](https://continuingstudies.sauder.ubc.ca/courses/agile-delivery-methods/ii861) (within the context of software engineering) is "the state of when a system produces value at a steady and predictable rate." I think it is one of the greatest challenges and opportunities, especially in the complex domain of emergent solutions. Strive towards a continuous and incremental delivery model with consistent, efficient, and quality solutions, building the right things and delighting our users. Find ways to break down our systems into smaller pieces that are valuable on their own, enabling teams to deliver value incrementally. This requires a change of mindset for both business and engineering.

## Continuous integration and delivery (CI/CD) pipeline

The CI/CD pipeline is a DevOps practice for delivering code changes more often, consistently, and reliably. It enables agile teams to increase *deployment frequency* and decrease *lead time for change*, *change-failure rate*, and *mean time to recovery* key performance indicators (KPIs), thereby improving *quality* and delivering *value* faster. The only prerequisites are a solid development process, a mindset for quality and accountability for features from ideation to deprecation, and a comprehensive pipeline (as illustrated below).

![Prerequisites for a solid development process Prerequisites for a solid development process](https://opensource.com/sites/default/files/uploads/devops_pipeline_pipe-2.png)

It streamlines the engineering process and products to stabilize infrastructure environments; optimize flow; and create consistent, repeatable, and automated tasks. This enables us to turn complex tasks into complicated tasks, as outlined by Dave Snowden's [Cynefin Sensemaking](https://en.wikipedia.org/wiki/Cynefin_framework) model, reducing maintenance costs and increasing quality and reliability.

Part of streamlining our flow is to minimize waste for the [wasteful practice types](https://www.lean.org/lexicon/muda-mura-muri) Muri (overloaded), Mura (variation), and Muda (waste).

**Muri:**avoid over-engineering, features that do not link to business value, and excessive documentation**Mura:**improve approval and validation processes (e.g., security signoffs); drive the[shift-left](https://en.wikipedia.org/wiki/Shift_left_testing)initiative to push unit testing, security vulnerability scanning, and code quality inspection; and improve risk assessment**Muda:**avoid waste such as technical debt, bugs, and upfront, detailed documentation

It appears that 80% of the focus and intention is on products that provide an integrated and collaborative engineering system that can take an idea and plan, develop, test, and monitor your solutions. However, a successful transformation and engineering system is only 5% about products, 15% about process, and 80% about people.

There are many products at our disposal. For example, Azure DevOps offers rich support for continuous integration (CI), continuous delivery (CD), extensibility, and integration with open source and commercial off-the-shelve (COTS) software as a service (SaaS) solutions such as Stryker, SonarQube, WhiteSource, Jenkins, and Octopus. For engineers, it is always a temptation to focus on products, but remember that they are only 5% of our journey.

![5% about products, 15% about process, 80% about people 5% about products, 15% about process, 80% about people](https://opensource.com/sites/default/files/uploads/devops_pipeline_pipe-3.png)

The biggest challenge is breaking down a process based on decades of rules, regulations, and frustrating areas of comfort: "*It is how we have always done it; why change?*"

The friction between people in development and operation results in a variety of fragmented, duplicated, and incessant integration and delivery pipelines. Development wants access to everything, to iterate continuously, to enable users, and to release continuously and fast. Operations wants to lock down everything to protect the business and users and drive quality. This inadvertently and often entails processes and governance that are hard to automate, which results in slower-than-expected release cycles.

Let us explore the pipeline with snippets from a recent whiteboard discussion.

The variation of pipelines is difficult and costly to support; the inconsistency of versioning and traceability complicates live site incidents, and continuous streamlining of the development process and pipelines is a challenge.

![Improving quality and visibility of pipelines Improving quality and visibility of pipelines](https://opensource.com/sites/default/files/uploads/devops_pipeline_pipe-4_0.png)

I advocate a few principles that enable one universal pipeline per product:

- Automate everything automatable
- Build once
- Maintain continuous integration and delivery
- Maintain continuous streamlining and improvement
- Maintain one build definition
- Maintain one release pipeline definition
- Scan for vulnerabilities early and often, and
*fail fast* - Test early and often, and
*fail fast* - Maintain traceability and observability of releases

If I poke the hornet's nest, however, the most important principle is to *keep it simple*. If you cannot explain the reason (*what*, *why*) and the process (*how*) of your pipelines, you do not understand your engineering process. Most of us are not looking for the best, ultramodern, and revolutionary pipeline—we need one that is functional, valuable, and an enabler for engineering. Tackle the 80%—the culture, people, and their mindset—first. Ask your CI/CD knights in shining armor, with their TLA (two/three-lettered acronym) symbols on their shield, to join the might of practical and empirical engineering.

## Unified pipeline

Let us walk through one of our design practice whiteboard sessions.

![CI build/CD release pipeline CI build/CD release pipeline](https://opensource.com/sites/default/files/uploads/devops_pipeline_pipe-5_0.png)

Define one CI/CD pipeline with one build definition per application that is used to trigger *pull-request pre-merge validation* and *continuous integration* builds. Generate a *release* build with debug information and upload to the [Symbol Server](https://en.wikipedia.org/wiki/Microsoft_Symbol_Server).** **This enables developers to debug locally and remotely in production without having to worry which build and symbols they need to load—the symbol server performs that magic for us.

![Breaking down the CI build pipeline Breaking down the CI build pipeline](https://opensource.com/sites/default/files/uploads/devops_pipeline_pipe-6.png)

Perform as many validations as possible in the build—*shift left*—allowing feature teams to fail fast, continuously raise the overall product quality, and include invaluable evidence for the reviewers with every pull request. Do you prefer a pull request with a gazillion commits? Or a pull request with a couple of commits and supporting evidence such as security vulnerabilities, test coverage, code quality, and [Stryker](https://stryker-mutator.io/) mutant remnants? Personally, I vote for the latter.

![Breaking down the CD release pipeline Breaking down the CD release pipeline](https://opensource.com/sites/default/files/uploads/devops_pipeline_pipe-7.png)

Do not use build transformation to generate multiple, environment-specific builds. Create one build and perform release-time *transformation*, *tokenization*, and/or XML/JSON *value replacement*. In other words, *shift-right* the environment-specific configuration.

![Shift-right the environment-specific configuration Shift-right the environment-specific configuration](https://opensource.com/sites/default/files/uploads/devops_pipeline_pipe-8.png)

Securely store release configuration data and make it available to both Dev and Ops teams based on the level of *trust* and *sensitivity* of the data. Use the open source Key Manager, Azure Key Vault, AWS Key Management Service, or one of many other products—remember, there are many hammers in your toolkit!

![Dev-QA-production pipeline Dev-QA-production pipeline](https://opensource.com/sites/default/files/uploads/devops_pipeline_pipe-9.png)

Use *groups* instead of *users* to move approver management from multiple stages across multiple pipelines to simple group membership.

![Move approver management to simple group membership Move approver management to simple group membership](https://opensource.com/sites/default/files/uploads/devops_pipeline_pipe-10.png)

Instead of duplicating pipelines to give teams access to their *areas of interest*, create one pipeline and grant access to *specific stages* of the delivery environments.

![Pipeline with access to specific delivery stages Pipeline with access to specific delivery stages](https://opensource.com/sites/default/files/uploads/devops_pipeline_pipe-11.png)

Last, but not least, embrace pull requests to help raise insight and transparency into your codebase, improve the overall quality, collaborate, and release pre-validation builds into selected environments; e.g., the Dev environment.

Here is a more formal view of the whole whiteboard sketch.

![The full pipeline The full pipeline](https://opensource.com/sites/default/files/uploads/devops_pipeline_pipe-12.png)

So, what are your thoughts and learnings with CI/CD pipelines? Is my dream of *one pipeline to rule them all* a pipe dream?

## 1 Comment