可扩展 CI/CD 流程的技巧和窍门

当你规划一个项目时，你并不总是知道它最终会有多大。因此，遵循一些指南来确保开发过程尽可能顺利至关重要。一个特别有用的工具是持续集成/交付流程，简称 CI/CD 流程。

在典型的开发过程开始时，在项目准备发布之前，您的 CI 流程如下所示：

在开发阶段，流程会不断添加更多步骤，直到看起来像下图所示。不过，在某些项目中，您可能会看到比这更多的步骤。原图。

在本文中，我将演示一个典型的 CI/CD 流程，并提供一些技巧，帮助您将其扩展到更大的项目。请注意，这些建议是基于您已经使用 Docker 和编排工具（例如 Kubernetes）开发了基础架构设置的前提。

定义您的 VCS 流程

所有现代 CI 工具都依赖于版本控制系统，因此为了保持 CI 流程的高水平，您应该拥有一个合适的版本控制流程。如果您正在寻找灵感，我推荐Git Flow或Github Flow。选择其中一个，并根据您的需求调整您的流程。

建议：

• 对任何分支中的每次推送都运行测试。这有助于您的开发人员更快地发现错误并加快代码审查流程。
• 定义将用于触发 Docker 镜像构建过程的分支并部署它们，如上图所示。
• 如果您的发布具有复杂的手动审批流程，请使用标签来触发生产发布。

指定您的环境

一旦你建立了 Git 流程，就将其与你的构建逻辑集成，并根据你拥有的环境数量进行调整。最初，你可能会在本地环境测试后将所有内容部署到生产环境。之后，你可能会决定进行开发、用户验收测试 (UAT) 和生产环境。

例子：

我们通常使用主分支来启动到开发环境的部署。然后，我们将主分支合并到发布分支。这会触发部署到用户验收测试 (UAT)，我们允许少数用户测试新版本。如果一切正常，并且 QA 团队确认发布，我们会从发布分支创建一个标签，从而启动到生产环境的部署。

设置通知

您应该通过您喜欢的通知渠道跟踪所有 CI 流程。我们在项目中使用 Slack。

• 创建系统通知渠道并使其能够发送有关所有 CI 和基础设施流程的通知。
• 设置有关成功或失败状态的通知，并在构建开始时提醒您。

保持 Docker 镜像简单

最佳做法是不要将环境变量传递给 Docker 镜像。所有环境变量都应通过 Docker 运行命令或在编排工具级别（例如 Kubernetes）传递。这也有助于保持 CI 配置文件的简洁性。

统一您的管道

如今，越来越多的公司开始使用微服务架构；统一的流水线可以帮助您更快地扩展部署，并在新的微服务中配置持续集成 (CI)，从而从中受益。在 Drone CI 或 Travis CI 中，您可以在流水线步骤中使用大量 CI 环境变量（请参阅Travis CI 环境变量和Drone CI 环境变量）。以下是一些 CI 环境变量的实际示例：

• 要标记 Docker 镜像，可以使用构建分支和构建编号的组合。结果会是类似“master-6”的形式。或者，您也可以使用 git 的版本号进行标记。tags: "${DRONE_COMMIT_BRANCH}-${DRONE_BUILD_NUMBER}"

• 在编排工具中使用仓库名称进行部署。Drone CI 使用环境变量部署到 Kubernetes 集群的示例。
  

deploy:
   image: peloton/drone-k8s-deployment
   deployment_names: "${DRONE_REPO_NAME}"
   container_names: "${DRONE_REPO_NAME}"
   namespaces: microservices
   docker_image: "62673275295.dkr.ecr.eu-west-1.amazonaws.com/${DRONE_REPO_NAME}:${DRONE_COMMIT_BRANCH}-${DRONE_BUILD_NUMBER}"
   date_label: deployment.drone.io/date-deployed
   secrets: [kubernetes_url, kubernetes_token]

定义 Docker 镜像名称约定

您应该根据环境的具体情况和重要性来制定 Docker 镜像的命名策略。例如，在开发和 UAT 环境中，由于不需要回滚功能，您可以使用分支名称作为标记，以便所有新构建都会覆盖之前的镜像。对于生产环境，最好使用发行版的版本号 (v1.0.0) 来标记镜像，这样可以减小镜像的体积，从而使镜像仓库更加结构化、可读性更强。

使用建造者模式

如果您能够在 CI 级别编译和构建某些内容，那么在将其放入最终镜像之前，将此作为额外步骤会很有帮助。观看此视频以更好地理解。

数据库迁移作为单独的步骤

不要将迁移作为 Dockerfile 的一部分执行；而应将其作为单独的步骤执行。额外的命令（例如资源编译或迁移）应作为单独的步骤运行，而不是在 Docker 启动时执行。您还应尝试在尽可能短的时间内启动并运行 Docker 镜像。

避免使用私有库和子模块

任何额外的依赖项（例如私有 npm 模块或子模块）都可能在 CI 配置设置过程中给您带来麻烦。例如，如果您有一个子模块，而默认情况下您的 CI 只能通过 http 和授权令牌访问您的代码库，那么您通过 git 为本地计算机配置的配置将无法正常工作。您需要覆盖子模块，但并非所有 CI 工具都提供此功能。

无人机 CI 子模块覆盖示例

如果您使用私有 npm 模块，您将面临类似的问题，因为您将需要 Docker 镜像中的密码或已下载的模块。

概括

为新项目配置 CI 时，请花一些时间思考和定义命名约定、潜在的扩展方法以及构建步骤的统一性。这有助于您更快地部署新服务，将这些实践作为新项目的基础，并更快地让员工加入到流程中。