你也可以将这篇文章下载为PDF格式，在沙发上阅读。
你希望你的工程团队以高速度交付无缺陷的代码吗？一个快速、可靠的CI/CD管道对于长期持续地做到这一点至关重要。
什么是CI/CD管线？
CI/CD流水线使你的软件交付过程自动化。该管道构建代码，运行测试（CI），并安全地部署应用程序的新版本（CD）。
自动管道消除了人工错误，为开发人员提供标准化的反馈回路，并实现快速的产品迭代。
CI和CD是什么意思？
CI是持续集成（Continuous Integration）的简称，是一种软件开发实践，在这种实践中，所有开发人员每天多次合并中央仓库中的代码变化。CD代表持续交付*，它在持续集成的基础上增加了整个软件发布过程的自动化实践。
通过CI，代码中的每一个变化都会触发给定项目的自动构建和测试序列，并向做出变化的开发者提供反馈。整个CI的反馈循环应该在10分钟内完成。
持续交付包括基础设施配置和部署，这可能是手动的，由多个阶段组成。重要的是，所有这些过程都是完全自动化的，每次运行都有完整的记录，并对整个团队可见。
在这里了解更多： CI/CD：持续集成和交付的解释
CI/CD管道的要素
CI/CD管道可能听起来像开销，但它不是。它本质上是一个可运行的规范，是任何开发人员为交付一个新版本的软件产品而需要执行的步骤。在没有自动化管道的情况下，工程师仍然需要手动执行这些步骤，因此效率要低得多。
大多数软件发布都要经过几个典型的阶段：
CI/CD流水线的阶段
每个阶段的失败通常会触发一个通知--通过电子邮件、Slack等--让负责的开发人员知道原因。否则，整个团队在每次成功部署到生产后都会收到一个通知。
源阶段
在大多数情况下，流水线的运行是由源代码库触发的。代码的变化触发了对CI/CD工具的通知，该工具运行相应的流水线。其他常见的触发器包括自动安排的或用户发起的工作流程，以及其他管道的结果。
构建阶段
我们把源代码和它的依赖性结合起来，建立一个我们产品的可运行实例，我们有可能把它运送给我们的终端用户。用Java、C/C++或Go等语言编写的程序需要进行编译，而Ruby、Python和JavaScript程序则无需这一步骤。
不管是哪种语言，云原生软件通常是用Docker部署的，在这种情况下，CI/CD管道的这个阶段会构建Docker容器。
如果不能通过构建阶段，说明项目的配置存在根本问题，最好立即解决。
测试阶段
在这个阶段，我们运行自动化测试来验证我们代码的正确性和产品的行为。测试阶段作为一个安全网，防止容易复制的bug到达终端用户。
编写测试的责任落在开发人员身上。编写自动化测试的最好方法是在我们编写测试或行为驱动开发的新代码时进行。
根据项目的规模和复杂性，这个阶段可以持续几秒钟到几个小时。许多大型项目在多个阶段运行测试，从进行快速理智检查的烟雾测试开始，到从用户的角度测试整个系统的端到端集成测试。一个广泛的测试套件通常被并行化以减少运行时间。
测试阶段的失败暴露了开发人员在编写代码时没有预见的问题。这个阶段必须快速产生对开发人员的反馈，同时问题空间还在他们的脑海里，他们可以保持流程状态。
部署阶段
一旦我们建立了一个可运行的代码实例，并通过了所有预定义的测试，我们就可以准备部署了。通常有多个部署环境，例如，产品团队内部使用的 "beta "或 "staging "环境，以及供最终用户使用的 "production "环境。
接受敏捷开发模式的团队，在测试和实时监控的指导下，通常将正在进行的工作手动部署到暂存环境，以进行额外的手动测试和审查，并自动将批准的更改从主分支部署到生产。
CI/CD管线的例子
管线反映了项目的复杂性。即使是最简单的管道配置，在每一个代码变更上运行一个作业，也能为团队在未来节省很多麻烦。
在Semaphore上，管道可以很容易地用多个连续或平行的作业块进行扩展。管道还可以通过使用手动或自动触发的促销活动来扩展，这些促销活动是基于自定义条件的。
一个简单程序的流水线
一个流水线可以从非常简单的开始。下面是一个Go项目流水线的例子：
- 编译代码
- 检查代码风格，以及
- 在两个平行作业中运行自动测试
Go项目的简单CI流水线
使用Docker和Kubernetes的持续交付管道
使用Docker会增加CI/CD管道的复杂性，因为它要求开发人员在每次代码构建中构建和上传一个大型容器镜像。
对于许多团队来说，方便开发者入职和标准化部署的好处超过了成本。
下面是一个构建、测试和部署一个微服务到Kubernetes集群的管道。
使用Docker和Kubernetes的CI/CD流水线
使用Semaphore上的私有Docker注册表（可用于企业云计划），开发人员可以在他们的管道中获得巨大的性能提升，因为他们避免了在每个CI/CD工作流程中与外部云注册表沟通的开销。
单程序的CI/CD管线
使用monorepo开发意味着拥有一个包含许多项目的单一的、受版本控制的代码库。这些项目可以是相关的，但通常在逻辑上是独立的，并且通常由不同的团队运行。
用单库做CI/CD是一个挑战。默认情况下，每一个代码变更都会启动一个管道，对包含在monorepo中的每一个项目进行构建、测试和部署。这既浪费时间，又耗费资金，而且风险很大。
Semaphore可以自动检测到monorepo中的变化，并让开发者指定管道的哪些部分要在此基础上运行：
单例持续集成管道
管线的其他好处
拥有一个CI/CD流水线比仅仅使现有的流程更有效率有更多的积极作用：
- 开发人员可以继续专注于编写代码和监控生产中系统的行为。
- QA和产品利益相关者可以很容易地访问系统的最新版本，或任何版本。
- 产品更新没有压力。
- 所有代码修改、测试和部署的日志都可以随时检查。
- 在出现问题的情况下，回滚到以前的版本是一个常规的按钮动作。
- 一个快速的反馈回路有助于建立一个学习和责任的组织文化。
在这里了解更多：持续交付帮助建立学习文化的7种方式
什么是一个好的管道？
一个好的CI/CD管道是快速、可靠和准确的。
速度
速度体现在几个方面：
- 我们如何快速获得关于工作正确性的反馈？如果比喝咖啡的时间还长，那么将代码推送到CI就相当于要求开发人员在解决问题的过程中参加会议。由于不可避免的上下文切换，开发人员的工作效率会降低。
- 我们需要多长时间来构建、测试和部署一个简单的代码提交？例如，CI和部署的总时间为一小时，这意味着整个工程团队全天最多只能进行七次部署的硬性限制。这导致开发人员选择不那么频繁、风险更大的部署，而不是今天企业需要的快速变化。
- 我们的CI/CD管道是否能实时扩展以满足开发需求？传统的CI/CD管道的容量是有限的，这意味着在一个特定的时间内只有一定数量的管道可以运行。因此，资源在大部分时间都是闲置的，而开发人员在一天中的繁忙时段排队等待CI/CD的出现。在最近发布的Semaphore 2.0中，最大的变化之一是自动扩展和随用随付的定价模式，这是一个支持开发者生产力的 "无服务器 "操作原则。
- 我们如何快速建立一个新的管道？难以扩展CI/CD基础设施或重复使用现有配置会产生摩擦，从而扼杀开发。今天的云基础设施最好通过将软件写成微服务的组合来利用，这就要求频繁地启动新的CI/CD管道。通过拥有一个适合现有开发工作流程的可编程CI/CD工具，并将所有CI/CD配置存储为可审查、版本和恢复的代码，就可以解决这个问题。
更多信息请点击这里：为什么云原生的成功取决于高速度的CI/CD。
可靠性
一个可靠的管道对于给定的输入总是产生相同的输出，并且在运行时没有震荡。断断续续的故障会给开发者带来强烈的挫败感。
运营和扩展CI/CD基础设施，为不断增长的团队提供按需、干净、相同和隔离的资源是一项复杂的工作。当团队和项目数量增加，或者技术栈发生变化时，对一个项目或几个开发人员来说似乎很有效的东西通常会被打破。当我们听到新用户说，不可靠的CI/CD是他们转到Semaphore的首要原因之一，通常是来自于一个自我托管的解决方案。
精确性
任何程度的自动化都是一种积极的变化。然而，在CI/CD管道准确运行和可视化整个软件交付过程之前，这项工作还没有完全完成。这需要使用一个CI/CD工具，它可以对简单的工作流程进行建模，如果需要的话，也可以对复杂的工作流程进行建模，这样，重复性工作中的人工错误就完全不可能发生了。
例如，将CI阶段完全自动化，但不将部署作为手动操作，由团队中的一个人执行，这种情况并不少见。如果一个CI/CD工具能够模拟所需的部署工作流程，例如使用秘密和多阶段推广，这个瓶颈就可以被消除。
要做的好事情
当主程序被破坏时，放下你正在做的事情并修复它：在管道上保持一个 "无破窗 "政策。
首先运行快速和基本的测试：如果你有一个大型的测试套件，通常的做法是将其并行化以减少运行时间。然而，如果一些重要的单元或代码质量测试失败，运行所有耗时的UI测试是没有意义的。相反，最好是建立一个具有多个阶段的管道，其中快速和基本的测试--如安全扫描和单元测试--首先运行，只有当它们通过后，管道才会转向集成或API测试，最后是UI测试。
始终使用完全相同的环境：如果一个流水线的运行修改了下一个流水线的环境，那么CI/CD流水线是不可靠的。每个工作流程都应该从相同的、干净的、隔离的环境开始。
内置的质量检查：例如，有一些开源工具为每一种主要的编程语言提供静态代码分析，涵盖从代码风格到安全扫描的所有内容。在你的CI/CD管道中运行这些工具，并释放出脑力来解决创造性的问题。
包括拉动请求：没有理由让CI/CD管道局限于一个或几个分支。通过对每个分支和相应的拉动请求运行标准的测试集，贡献者可以在参与同行评审之前，或者更糟糕的是，在与主分支集成之前，发现问题。这种做法的结果是，合并任何拉动请求都会成为一个非事件。
对每个拉动请求进行同行评审：没有任何CI/CD管道可以完全取代审查新代码的需要。有的时候，改变确实是如此的微不足道，以至于同行审查是浪费时间；然而，最好是设定一个标准，即每一个拉动请求都需要另一双眼睛，只有在有意义的时候才做例外，而不是反过来。同行代码审查是建立一个强大的、无自我的、协作解决问题的工程文化的一个关键因素。
准备好实施一个CI/CD管道了吗？
Semaphore是最快的基于云的CI/CD服务，原生支持Docker和主要编程语言，具有自动扩展和随用随付的定价模式。创建一个新的管道只需要几个简单的步骤：
- 创建一个免费的Semaphore账户
- 选择一个你能访问的Git仓库
- 提交并推送一个管道实例
- 参加导游，从Semaphore文档中的许多教程和示例项目中学习
构建愉快!
