document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

PRF

Browse Source 
PART 1
This commit is contained in:
Xingyu Wang 2020-07-07 10:26:15 +08:00
parent a5e08845c7
commit 4e66311825
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
translated/tech/20190702 One CI-CD pipeline per product to rule them all.md
View File

@ -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 的说法，<ruby>[流程][2]<rt>flow</rt></ruby>（在软件工程的语境内）是“软件系统以稳定和可预测的速度创造价值的状态”。我认为这是最大的挑战和机遇之一，特别是在复杂的新兴解决方案领域。我力求通过一种持续、高效和优质的解决方案，提供一种持续交付模式，并且能够构建正确的事物让我们的用户感到满意。想办法把我们的系统分解成更小的碎片，这些碎片本身是有价值的，使团队能够渐进式地交付价值。这需要业务和工程部门改变思维方式。
### 持续集成和持续交付的 (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] 模型所说的那样，这样就允许我们将复杂不可解决的任务变成了复杂可解决的任务，降低了维护成本，提高了质量和可靠性。
精简流程的一部分是需要最大程度地减少 <ruby>[浪费实践类型][5]<rt>wasteful practice types</rt></ruby> Muri（过载）、Mura（变异）和 Muda（浪费）的浪费。
* **Muri**：避免过度工程化，避免与业务价值不相关的功能以及过多的文档
* **Mura**：改善审批和验证流程（比如，安全审核）；驱动 <ruby>[左移][6]<rt>shift-left</rt></ruby> 措施以推动单元测试、安全漏洞扫描与代码质量检查；并改进风险评定。
* **Muda**：避免浪费，比如技术债务、错误或前期的详细文档等。
看起来 80％ 的重点都集中在提供一种可以持续集成和协作的工程产品，这些系统可以采用构想一个创意，计划，开发，测试和监视您的解决方案。然而，一个成功的转型和工程系统是由 5％ 的产品，15％ 的过程和 80％ 的开发人员组成的。