持续集成/持续交付 (CI/CD) 流水线已成为发布软件不可或缺的一部分，但它们的用途往往会被误解。在许多情况下，CI/CD 管道被视为解决发布问题的解毒剂，但实际上，它们的有效性取决于它们所代表的底层发布过程。在本文中，我们将了解创建有效 CI/CD 管道的几个简单步骤，包括如何捕获和简化现有发布流程，以及如何将该流程转换为精益管道。
捕获发布过程
CI/CD 管道并不是解决我们所有发布瓶颈的灵丹妙药，如果底层发布过程出现问题，它也只能提供最小的改进。对于软件，发布过程是团队用来将代码从源代码文件中获取到可以交付给客户的打包产品的一组步骤。该过程将反映每个产品和创建产品的团队的 业务需求。
虽然发布过程的细节会有所不同——有些可能需要某些安全检查，而另一些可能需要第三方的批准——但几乎所有软件发布过程都有一个共同的目的：
- 将源代码构建并打包成一组工件
- 通过各种级别的审查来测试工件，包括单元、集成和端到端 (E2E) 测试
- 从最终用户的角度测试产品的关键工作流程
- 将工件部署到类似生产的环境中以对部署进行冒烟测试
每个向客户交付产品的团队都有一些发布流程。这个过程可以从“通过电子邮件将工件发送给吉姆以便他可以测试它们”到非常严格和正式的过程，团队或经理必须在过程中的每个步骤完成时签字。
写在纸上
尽管存在这种差异，但开发有效的 CI/CD 管道的第一个也是最关键的步骤是捕获发布过程。最简单的方法是绘制一组框来捕获发布过程中的步骤，并绘制从一个步骤到另一个步骤的箭头以显示一个步骤的完成如何启动另一个步骤的开始。这幅画不必过于正式；它可以在一张纸上完成，只要捕获当前实践的过程即可。图 1 说明了一个简单的发布过程，该过程对许多产品都很常见：
图 1：基本发布流程 - 捕获当前发布流程的步骤是创建管道的第一步
说同一种语言
一旦捕获了当前的发布过程，下一步就是使该过程正式化。在谈到发布过程以及最终的 CI/CD 管道时，使用通用的本地语言或领域语言非常重要。
对于管道，基本词典是：
- Step – 发布过程中的单个操作，例如Build、Unit Tests或Staging（即框）。
- 阶段——发布过程中的一个阶段，包含一个或多个步骤。通常，阶段可以被认为是管道中的顺序列。例如，Build包含在第一阶段，Unit Test包含在第二阶段，User Tests和Staging包含在第五阶段。当一个阶段中只有一个步骤时，术语步骤和阶段通常作为同义词使用。
- 管道——一组有序的步骤。
- 触发器– 启动管道单次执行的事件，例如签入或提交。
- 门- 必须在所有后续步骤开始之前完成的手动步骤。例如，在部署产品之前，团队或经理可能需要在完成测试后签字。
CI/CD 管道只是正式发布流程的自动化实现。因此，如果我们希望创建一个有效的 CI/CD 流水线，那么首先优化我们的发布流程是必不可少的。
优化发布流程
由于我们的 CI/CD 管道反映了我们的发布流程，因此创建有效管道的最佳方法之一是在从中派生管道之前优化发布流程本身。我们可以对发布流程进行三个关键优化，从而为有效的管道带来好处：
- 简化流程——我们应该尽量减少任何会减慢发布流程的瓶颈或人为步骤。
- 删除任何不必要的步骤。
- 在满足业务需求的同时最大限度地减少步骤数。
- 简化任何复杂的步骤。
- 删除或分发需要单一联系点的步骤。
- 加速长时间运行的步骤并将它们与其他步骤并行运行。
- 自动化一切——理想的发布过程没有手动步骤。虽然这并不总是可能的，但我们应该自动化每一个可能的步骤。
- 考虑JUnit、Cucumber、Selenium、Docker和Kubernetes等工具和框架。
- 捕获在脚本中运行每个步骤的过程——即，运行构建应该和执行build.sh. 这确保没有神奇的命令，并允许我们在故障排除或复制发布过程时按需运行每个步骤。
- 创建可以在发布过程运行的任何地方运行的可移植脚本。不要使用仅适用于特定、特殊用途环境的命令。
- 对脚本进行版本控制，最好与源代码位于同一存储库中。
- 缩短发布周期——我们应该尽可能频繁地发布我们的产品。即使最终可交付成果没有交付给客户或用户（例如，我们每天都在构建产品，但每周只向客户发布一次产品），我们也应该经常运行我们的发布流程。如果我们目前每天执行一次发布过程，我们应该努力在每次提交时完成它。
优化发布流程可确保我们在精简高效的基础上构建 CI/CD 管道。发布过程中的任何膨胀都会反映在我们的管道中。优化我们的发布流程将是迭代的，并且需要不断努力以确保我们在添加更多步骤以及现有步骤变得更大和更全面时保持精益发布流程。
构建管道
一旦我们有了优化的发布流程，我们就可以实施我们的管道。为了创建有效的 CI/CD 管道，我们应该遵循三个重要的建议：
- 不要追随时尚——有无数的噱头和时尚在争夺我们的注意力，但我们的职业责任是根据对我们的需求最有效的东西来选择我们的工具和技术。普遍性和流行性并不能保证有效性。目前，CI/CD 管道工具的选项包括GitHub Actions、GitLab CI/CD和Jenkins。这不是一个完整的列表，但它确实提供了一个稳定的起点。
- 保持简单性——理想情况下，每个步骤都应该运行一个脚本，管道配置中没有硬编码命令。管道配置应该被认为是胶水并且应该包含尽可能少的逻辑。例如，.gitlab-ci.yml图 1 中发布过程的理想 GitLab CI/CD 配置 ( ) 类似于： build: stage: building script: - /bin/bash build.shunit-tests: stage: unit-testing script: - /bin/bash run-unit-tests.shintegration-tests: stage: integration-testing script: - /bin/bash run-integration-tests.sh...deploy: stage: deployment script: - /bin/bash deploy.sh --env production:443 --key ${SOME_KEY}这个理想并不总是可能的，但这应该是我们努力的目标。
- 收集反馈——我们的管道不仅应该产生工件，还应该产生报告。这些报告应包括：
- 显示测试用例总数、通过和失败的测试报告
- 衡量我们被测产品性能的报告
- 显示管道执行时间的报告——整体和每个步骤
- 可追溯性报告显示哪些提交落入构建以及哪些票证（例如 Jira 或 GitHub 票证）与构建相关联
这种反馈使我们不仅可以优化我们的产品，还可以优化构建它的管道。
通过遵循这些提示，我们可以构建一个有效的管道来满足我们的业务需求，并为我们的用户和客户提供最大的价值和最少的摩擦。
结论
CI/CD 管道并不是解决我们所有发布问题的灵丹妙药。虽然它们是可以显着改进我们软件发布的重要工具，但它们的有效性取决于我们的底层发布流程。为了创建有效的管道，我们需要简化我们的发布流程并保持警惕，以便我们的管道尽可能保持简单和自动化。
