良好 CI/CD 管道的 4 个属性

找到一个没有某种持续集成/持续交付流水线的地方是很奇怪的。使用 CI/CD 是企业能够更快地响应用户需求，并让开发人员能够更频繁、更自信地发布新版本的方法之一。持续集成是指将来自不同分支的代码整合在一起，并确保代码库能够正常工作。您的构建将在这里进行。

持续交付是指将代码库发送到不同环境（例如 QA 或生产环境）的方式。在持续集成到位后，按照行业标准设置持续交付也是理所当然的。两者分离的情况并不多见，但有些地方出于自身原因会进行手动部署。而 CI/CD 结合使用，您无需担心手动部署，因为它们可以让您实现所有操作的自动化。

当您的团队完成代码更改后，所有分支都将准备好合并到开发分支或您使用的其他分支。所有拉取请求获得批准后，您就可以立即启动 CI/CD 流水线，除非出现问题，否则无需进行其他操作。流水线的持续集成部分将创建一个构建工件，该工件将被发送到流水线的持续交付部分，然后持续交付部分会在选定的环境中发布该工件。

这是 CI/CD 流水线的一般实现方式。创建这些流水线涉及许多细节，这意味着并非所有流水线都相同。同一项工作可以用多种方式完成，有些流水线自然会比其他流水线更好。您希望CI/CD 流水线具备某些属性，因为它们将提高发布质量，并让您和业务部门更有信心更频繁地向用户发布更改。以下是优秀 CI/CD 流水线的一些属性。

速度很快

CI/CD 流水线可能包含许多活动部件，包括单元测试、集成测试、创建构建工件等等。您的代码不应该需要一整天的时间才能通过流水线。拥有快速的流水线意味着您可以在一天内完成更多部署，并更高效地查找和修复代码问题。您的集成或代码反馈应该只需几分钟即可完成。

为了获得快速反馈，我们通常会将所有单元测试或代码 linters 尽可能地放在靠近流水线起始处的位置。这样，如果您的代码出现问题，您无需等待流水线执行完大部分步骤。您会收到一条自动消息，告知您构建失败或类似信息，您可以查看持续集成日志。尽早发现问题是提高流水线速度的最佳方法之一。

它使用相同的流程和工件

流水线的持续集成部分生成新的构建工件后，就该让持续交付部分接管了。构建生成的工件可以是源代码，甚至可以是 Docker 容器。无论工件的格式如何，您都应该在所有环境中使用相同的工件。通过在所有环境中使用相同的工件，您可以在 QA 或阶段测试代码，并将其部署到生产环境中，并且更加确信其能够正常工作，因为它与您用于测试的工件完全相同。

持续交付最让我欣赏的一点是它能保持部署流程的一致性。部署过程无需指定关键人员，因为无需任何秘密操作或手动操作。您可以编写脚本将工件移动到云端或服务器中的正确位置，并且每次都会以相同的方式执行。这免去了您记住所有部署步骤的麻烦，并避免了大量潜在的人为错误。

您可以随时交付任意版本的代码

如果您曾经需要在周五下午部署重大变更，您就会明白这一点。只要您有工件，就可以部署它。如果工件版本之间有任何数据变更，请务必小心。引用较旧或较新的数据库模型时，可能会出现重大问题。大多数情况下，您手头上只会保留两三个工件，但您始终可以创建先前版本代码的新版本。

所以，如果你周五晚上遇到了一些奇怪的部署问题，业务部门慌乱地打电话给你，你可以自信地告诉他们，你会在周一回滚更改并调查问题。有了这项功能，每个人都可以安心地部署更改，因为即使出现问题，他们也可以部署最后一个可以正常工作的版本。

几乎不需要手动交互

自动化让持续集成和部署的额外努力变得值得。构建良好的流水线可能需要一些时间，但这是最需要注意的关键事项之一。任何人都不应该手动执行超过一两个步骤，例如单击按钮。一旦开发人员提交代码，并且他们的拉取请求获得批准，更改就会自动部署。无需其他步骤。您提交代码，代码获得批准，剩下的就交给我们了。

CI/CD 的目标是让业务方掌控功能发布时间，无需经过开发团队。你真的希望他们记住部署流程吗？你能记住部署流程，并在每次他们要求你时都能准确无误地完成吗？我们大多数人都有过部署失败的经历，通常是因为忘记了什么。一个好的 CI/CD 流水线可以确保你无需担心忘记什么，因为它已经准备好所有东西，可以自动运行。

构建一个良好的 CI/CD 流水线是值得的，因为它能帮你节省大量时间和精力。你无需在生产环境中苦苦追查 bug，因为你已经在 QA 阶段发现了它们，只需构建一个包含修复内容的新工件即可。这可以减轻开发人员的压力，但我不知道它是否会增加压力。你是否曾因为 CI/CD 而感到自己被迫在更短的时间内完成更多工作？

嘿！你应该在 Twitter 上关注我，理由如下：https://twitter.com/FlippedCoding