LabNow Stack的CI/CD的思路、实践、理念
本文简单介绍了我们进行CI/CD的思路、实践、理念。
我们的 CI/CD 理念
过去几年中，我们的团队尝试了包括但不限于 Travis、GitLab 运行器等 CI/CD 工具。直到最近，我们选择了 GitHub Actions 作为当前的选择。
随着这些工具的发展（或团队选择的变化），代码的 CI/CD 流水线，无论是以 YAML 文件的形式还是手动配置的流水线，都需要重构以适应新工具。
我们的理念是尽可能保持 CI/CD 的简单性，并与 CI/CD 工具解耦。
因此，很自然的选择是 将更多的功能实现放在源代码中的脚本/模块里，而不是依赖于工具提供的功能（例如：GitHub Actions）。
基于这一理念，我们建立了我们的 CI/CD 实践以及相应的工具包。
以下是我们 CI/CD 的工具包示例，包括以下部分：
-
tool.sh：一个包含几个用于构建代码或项目的函数的 shell 脚本。
-
github workflow YAML：一个特定于 CI/CD 平台的配置，使用上述的
tool.sh，并使用简单的 Linux shell 命令完成大部分构建任务。如你所见，每个作业都以source ./tool.sh开始，以使用我们工具包中定义的函数。
其他选择
随着构建工件在开发/测试（暂存）/发布（生产）阶段的变化，我们发现从两个角度管理工件（artificats）很重要：
-
每个工件都应该正确地进行版本控制和标记，特别是在测试（暂存）或生产环境需要回滚时。
-
用于发布（生产环境）的artifact仓库（例如 Docker registry）应与开发/测试（暂存）仓库分开，以便更好地管理生产环境的工件，并使用适当的资源。在许多情况下，生产环境需要一个高可用的工件仓库，并且最好与计算资源位于同一 VPC/区域，或者具有不同的推送/拉取权限。
因此，我们选择将开发/测试阶段的工件和发布/生产工件放入不同的仓库，至少是不同的registry命名空间。在上面的 tool.sh 文件中，你可以看到我们使用一个变量 DOCKER_IMG_NAMESPACE 来决定工件应该被推送到哪个命名空间。此外，这个变量由 Git 分支名称前缀 决定：
if [ "${CI_PROJECT_BRANCH}" = "main" ] ; then
# 如果在主分支上，Docker 镜像命名空间将与 CI_PROJECT_NAME 的命名空间相同
export CI_PROJECT_NAMESPACE="$(dirname ${CI_PROJECT_NAME})" ;
else
# 不是主分支，Docker 命名空间设置为 {CI_PROJECT_NAME 的命名空间} + "0" + {CI_PROJECT_SPACE 中 / 之前的第一段}
export CI_PROJECT_NAMESPACE="$(dirname ${CI_PROJECT_NAME})0${CI_PROJECT_SPACE}" ;
fi
通过这种方式：
-
当代码被推送或合并到
main分支时，工件仓库命名空间将是我们示例中的LabNow。 -
当代码被推送到分支名称为
dev/*的模式，并且创建了一个 PR 将这个分支dev/*合并到main，工件将被推送到命名空间LabNow0dev（后缀0dev可以自定义）。 -
当代码被推送到没有 PR 合并到
main的分支时，代码将不会被构建（流水线不会被触发执行）。