From 4e6631182568582b626e21bb3dc7f79e5b505d0a Mon Sep 17 00:00:00 2001 From: Xingyu Wang Date: Tue, 7 Jul 2020 10:26:15 +0800 Subject: [PATCH] PRF PART 1 --- ...D pipeline per product to rule them all.md | 28 +++++++++---------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/translated/tech/20190702 One CI-CD pipeline per product to rule them all.md b/translated/tech/20190702 One CI-CD pipeline per product to rule them all.md index 93de062373..3685ee4a99 100644 --- a/translated/tech/20190702 One CI-CD pipeline per product to rule them all.md +++ b/translated/tech/20190702 One CI-CD pipeline per product to rule them all.md @@ -1,36 +1,36 @@ [#]: collector: (lujun9972) [#]: translator: (chunibyo-wly) -[#]: reviewer: ( ) +[#]: reviewer: (wxy) [#]: publisher: ( ) [#]: url: ( ) [#]: subject: (One CI/CD pipeline per product to rule them all) [#]: via: (https://opensource.com/article/19/7/cicd-pipeline-rule-them-all) [#]: author: (Willy-Peter Schaub https://opensource.com/users/wpschaub/users/bclaster/users/matt-micene/users/barkerd427) -使用一条CI/CD流水线管理所有的产品 +使用一条 CI/CD 流水线管理所有的产品 ====== -统一的持续集成与持续交付的流水线的构想是一种梦想吗？ + +> 统一的持续集成与持续交付的流水线的构想是一种梦想吗？ + ![An intersection of pipes.][1] -当我加入 WorkSafeBC 的云端运维团队，我负责的是云端运维和工作流水线优化，我分享了一个可以对任意产品进行持续集成和持续交付的流水线。 +当我加入 WorkSafeBC 负责云端运维和工程流程优化的云端运维团队时，我和大家分享了我的梦想，那就是一个可以对任意产品进行持续集成和持续交付的流水线。 -根据 Lukas Klose 所说，[flow][2]（在软件工程范围内）是“软件系统可以在一种稳定和可预测的状态下创造价值”一种状态。我认为这是我遇到的最大的挑战和机遇之一，特别是在解决紧急问题的复杂领域。我力求通过一种持续，高效和优质的解决方案，提供一种持续交付模式，并且能够构建正确的事物让我们的用户感到满意。 +根据 Lukas Klose 的说法，[流程][2]flow（在软件工程的语境内）是“软件系统以稳定和可预测的速度创造价值的状态”。我认为这是最大的挑战和机遇之一，特别是在复杂的新兴解决方案领域。我力求通过一种持续、高效和优质的解决方案，提供一种持续交付模式，并且能够构建正确的事物让我们的用户感到满意。想办法把我们的系统分解成更小的碎片，这些碎片本身是有价值的，使团队能够渐进式地交付价值。这需要业务和工程部门改变思维方式。 -### 持续集成和持续交付的 (CI/CD) 流水线 +### 持续集成和持续交付的（CI/CD）流水线 -CI/CD 流水线是一种代码变更的频率更高，一致并且可靠的持续交付 DevOps 实践。它可以帮组敏捷开发团队增加**部署的频率**并且减少**变更所需要的时间**，**变更失败的频率**，和**故障恢复的时间**等关键绩效指标 (KPIS) ，从而提高质量并且实现更快的交付。唯一的先决条件就是坚实的开发基础，对需求从构想到放弃的责任心，和一个全面的流水线（如下图所示）。 +CI/CD 流水线是一种代码变更的频率更高、更一致、更可靠的持续交付 DevOps 实践。它可以帮组敏捷开发团队提高**部署的频率**并且减少**变更所需要的时间**、**变更失败的频率**，和**故障恢复的时间**等关键绩效指标（KPI），从而提高质量并且实现更快的交付。唯一的先决条件就是坚实的开发基础、对质量的心态和对需求从构想到废弃的责任心，以及一个全面的流水线（如下图所示）。 ![Prerequisites for a solid development process][3] -它简化了工程流程和产品用以稳定基础架构环境；优化工作流程；创建一致的，可重复的，自动化的任务。正如 Dave Snowden [Cynefin Sensemaking][4] 所说的那样，这样就允许我们将复杂不可解决的任务变成了复杂可解决的任务，降低了维护成本，提高了质量和可靠性。 - -精简流程的一部分是需要最大程度地减少浪费 [wasteful practice types][5] Muri (过载), Mura (变异), 和 Muda (浪费) - - * **Muri:** 避免过度工程化，和与业务价值不相关的功能以及过多的文档 - * **Mura:** 改善确认和审批流（比如，安全审核）；驱动测试 [shift-left][6]，安全漏洞扫描与代码质量检查；并且可以改进风险评定。 - * **Muda:** 避免浪费比如技术债务，bugs 或者前期详细的文档等。 +它简化了工程流程和产品，以稳定基础架构环境；优化工作流程；创建一致的、可重复的、自动化的任务。正如 Dave Snowden [Cynefin Sensemaking][4] 模型所说的那样，这样就允许我们将复杂不可解决的任务变成了复杂可解决的任务，降低了维护成本，提高了质量和可靠性。 +精简流程的一部分是需要最大程度地减少 [浪费实践类型][5]wasteful practice types Muri（过载）、Mura（变异）和 Muda（浪费）的浪费。 + * **Muri**：避免过度工程化，避免与业务价值不相关的功能以及过多的文档 + * **Mura**：改善审批和验证流程（比如，安全审核）；驱动 [左移][6]shift-left 措施以推动单元测试、安全漏洞扫描与代码质量检查；并改进风险评定。 + * **Muda**：避免浪费，比如技术债务、错误或前期的详细文档等。 看起来 80％ 的重点都集中在提供一种可以持续集成和协作的工程产品，这些系统可以采用构想一个创意，计划，开发，测试和监视您的解决方案。然而，一个成功的转型和工程系统是由 5％ 的产品，15％ 的过程和 80％ 的开发人员组成的。