编写CI/CD自动化部署脚本

编写CI/CD自动化部署脚本

什么是CI/CD

CI/CD 是现代软件开发过程中的关键实践，它包含两个缩写：

• CI，或者持续集成（Continuous Integration）
• CD，可以指持续交付（Continuous Delivery）或持续部署（Continuous Deployment）

持续集成 (CI)

持续集成 是一种软件开发实践，开发人员经常（通常是每天多次）将代码变更集成到共享存储库中。每次代码提交都通过自动化的构建和测试来验证，以便尽早发现集成错误，提高软件质量。

CI 的关键步骤包括：

• 版本控制：所有的源代码都维护在版本控制系统中，比如 Git。
• 自动构建：每次提交都会触发自动的构建过程，它包括编译代码，运行测试，打包等步骤。
• 自动测试：构建过程中包含自动化测试（单元测试、集成测试等）的执行，以确保代码更改没有引入任何错误。
• 反馈回馈：如果构建或测试失败，团队会立即收到反馈。

持续交付 (CD - Continuous Delivery)

持续交付 是在持续集成的基础上，确保软件可以随时在生产环境中发布的实践。它意味着除了自动化测试外，你还有一个自动化的发布过程，可以随时手动触发将软件部署到生产环境。

持续交付确保了：

• 软件的新版本能够快速并且可靠地发布。
• 发布过程是自动化的，减少了人为错误。

持续部署 (CD - Continuous Deployment)

持续部署 更进一步，它是持续交付的一个扩展。每次更改通过所有的生产管道阶段自动化测试后，如果通过测试，就会自动部署到生产环境。在持续部署中，从代码提交到生产环境的部署没有人工干预。

持续部署确保了：

• 减少了软件发布的周期，提高了发布的频率。
• 使团队能够更快地收到用户反馈，并对此做出响应。

CI/CD 的实践降低了软件开发的风险，提高了效率和速度，现在几乎成为敏捷开发和DevOps实践的标准组成部分。一些流行的CI/CD工具包括Jenkins、GitLab CI、CircleCI、Travis CI、Bamboo和GitHub Actions等。

逐步编写一个脚本

这份 .gitlab-ci.yml 文件是 GitLab CI/CD 的配置文件，用于自动化地进行软件的构建、测试、打包和部署。我将会逐步教您如何编写一个类似的自动化部署脚本。

1. 定义阶段（Stages）

首先，您需要定义执行的各个阶段，这些阶段按照定义的顺序执行。例如：

stages:- update_project- generate_domain_and_sql- install_entity_and_api- package_modules- deploy

2. 规定工作流程（Workflow）

您可以通过 workflow 关键词来限定什么条件下执行 CI/CD 流程。例如，只有在 dev-deploy 分支上的提交时才运行此流程：

workflow:rules:- if: $CI_COMMIT_BRANCH == "dev-deploy"

3. 编写作业（Jobs）

每个阶段可以包含一个或多个作业。作业是执行特定任务的脚本集合。

更新项目示例：

update:stage: update_projecttags:- support-devscript:- echo "Currently running as..."- whoami- echo "Changing dir..."- cd /home/recruit/support-dev/support-backend- git fetch --all- git reset --hard origin/dev-deploy- echo "Project update finished!"

这段脚本将会在 update_project 阶段执行，标签 support-dev 通常用来指示运行这个作业的特定的Runner。

条件跳过示例：

通过 except 或 rules 关键字，您可以条件地执行或跳过特定的作业。例如，如果提交信息包含 “skip-mbg”，则跳过此作业：

mybatis_generator:stage: generate_domain_and_sqltags:- support-devexcept:variables:- $CI_COMMIT_MESSAGE =~ /skip-mbg/script:- echo "Starting mybatis generator..."- ...

4. 定义脚本（Script）

script 是作业中实际执行的命令序列。这些命令可以是任何 shell 命令。

5. 使用规则（Rules）和只有在更改时（Only Changes）

rules 和 only/changes 用来确定何时执行作业。例如，只有当 support-entity 模块发生变更时才运行此作业：

install_entity:stage: install_entity_and_apitags:- support-devrules:- changes:- support-entity/**/*script:- echo "Installing support-entity"- ...

6. 打包模块（Package Modules）

在 package_modules 阶段，您会编译和打包您的应用程序。例如：

package_core_service:stage: package_modulestags:- support-devonly:changes:- support-core-service/**/*- ...script:- echo "Packaging core service..."- cd /home/recruit/support-dev/support-backend/support-core-service- mvn clean package -Dmaven.test.skip=true- echo "Core service packaged!"- ...

7. 部署模块（Deploy Modules）

最后，在 deploy 阶段，您将部署您的应用程序。这通常涉及移动构建的包到运行环境并重启服务。

deploy_core_service:stage: deploytags:- support-devonly:changes:- support-core-service/**/*- ...needs: ["package_core_service"]script:- echo "Restarting core service..."- systemctl restart support-core- echo "Restart succeed!"

小结

自动化部署脚本的编写需要您根据项目的需要去定义阶段、作业、脚本以及执行条件。每个项目可能有不同的需求

疑问

$CI_COMMIT_BRANCH是一个固定参数吗，为什么用$符号

在 GitLab CI/CD 环境中，$CI_COMMIT_BRANCH 是一个预定义的环境变量。这种变量通常以 $ 符号开始，这是 Unix shell 环境中引用变量的标准方式。在 GitLab CI/CD 脚本中，使用 $ 符号可以获取环境变量的值。

$CI_COMMIT_BRANCH 特别指代了触发当前 CI/CD 流水线的 Git 分支名称。例如，如果您向 feature-branch 推送代码，$CI_COMMIT_BRANCH 将会是 feature-branch。

GitLab CI/CD 为构建环境提供了许多这样的预定义环境变量，它们可以帮助您获取关于仓库、运行作业、流水线等的信息，以便在自动化脚本中使用。

这些环境变量对于写出能够根据不同情况动态改变其行为的 CI/CD 脚本是非常有用的。例如，您可能想要在向特定分支推送时才部署应用程序，或者根据提交信息中的某些关键词来跳过某些测试。通过使用这些环境变量，您可以让 CI/CD 脚本更加灵活和智能。

在 .gitlab-ci.yml 文件中，您可以通过简单地在变量名前加上 $ 符号来使用这些变量。例如：

deploy_to_production:script:- echo "Deploying to production server"- deploy --branch $CI_COMMIT_BRANCHonly:- master

在上面的例子中，如果这个作业在 master 分支上运行，$CI_COMMIT_BRANCH 将会被替换为 master，deploy 命令将会接到 --branch master 参数。

tags的作用是什么，是必须的吗

在 GitLab CI/CD 的 .gitlab-ci.yml 文件中，tags 关键词用于为 CI/CD 作业指定特定的运行器（Runner）。这不是必须的，但是它允许你控制哪些 Runner 能够执行特定的作业。

Runner 是用来执行你的作业和发送结果回 GitLab 的服务器。GitLab Runner 可以注册到 GitLab，并且可以拥有一个或多个标签（tags），这些标签在注册 Runner 时被指定。这些标签可以基于它们的用途、运行环境、部署的位置或者它们拥有的特定硬件特性来设置。

当你在 .gitlab-ci.yml 文件中的作业指定 tags 列表时，GitLab 会查找注册的 Runner 中具有所有这些标签的 Runner 来执行该作业。

例如：

deploy_to_production:stage: deployscript:- echo "Deploying to production server"tags:- production

在这个例子中，只有拥有 production 标签的 Runner 才会被用来执行 deploy_to_production 作业。

如果没有指定 tags，那么任何没有指定 tags 的 Runner（即注册为共有 Runner）都可以执行该作业。如果你的项目或者 Runner 的设置比较特殊，使用 tags 可以帮助保证作业只在具有特定配置的 Runner 上运行，这可以是为了安全、性能或者兼容性的原因。

如果你不需要对 Runner 进行特别的控制，那么 tags 关键词可以省略，作业将由可用的共有 Runner 执行。

我还是对Runner不理解，它是一个jar包吗

GitLab Runner 并不是一个 jar 包。GitLab Runner 是一个开源项目，用于运行你的 CI/CD 作业并发送结果回到 GitLab。它是一个单独的应用程序，可以在 Unix、Linux、macOS、Windows、Docker 容器中，以及 Kubernetes 集群上运行。GitLab Runner 是用 Go 语言编写的，因此它是一个编译后的可执行文件，而不是依赖 Java 运行环境的 jar 包。

你可以将 GitLab Runner 理解为一个客户端，它会接受来自 GitLab CI/CD 的指令（即在 .gitlab-ci.yml 文件中定义的作业），然后在相应的环境中执行这些指令（比如运行测试、部署代码等）。运行结束后，Runner 会将结果反馈给 GitLab。

为了使用 GitLab Runner，你需要在一台服务器或计算资源上安装并注册它。注册 Runner 时，你可以为其分配标签（tags），这些标签可以在 .gitlab-ci.yml 文件中通过 tags 关键词被引用，以决定哪一个 Runner 应该执行特定的作业。

以下是使用 GitLab Runner 的基本步骤：

1. 安装 GitLab Runner：首先需要在你想要运行 CI/CD 作业的服务器上安装 GitLab Runner。GitLab 官方文档提供了不同操作系统上的安装指南。

2. 注册 GitLab Runner：安装完毕后，你需要注册 Runner 到你的 GitLab 实例。这个过程涉及到为 Runner 指定 GitLab 实例的 URL 和一个注册令牌（token）。在注册过程中，你可以指定一些标签（tags）来描述 Runner 的特性或功能。

3. 配置 .gitlab-ci.yml 文件：在你的 GitLab 项目中，配置 .gitlab-ci.yml 文件来定义 CI/CD 作业。如果需要，可以在作业中使用 tags 来指定应该由哪个 Runner 执行这些作业。

4. 执行作业：当你的项目中发生了像代码推送（push）或合并请求（merge request）这样的事件时，GitLab CI/CD 会根据 .gitlab-ci.yml 文件中的定义来安排作业。如果作业中指定了 tags，GitLab 会找到具有相匹配标签的 Runner 来执行作业。

请注意，GitLab Runner 要与 GitLab（通常是 GitLab.com 或者自托管的 GitLab 实例）进行通信，以便获取作业并报告结果。因此，它需要网络连接到 GitLab 实例。