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

2023-12-20 06:31:11

编写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_project
  tags:
    - support-dev
  script:
    - 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。

条件跳过示例:

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

mybatis_generator:
  stage: generate_domain_and_sql
  tags:
    - support-dev
  except:
    variables:
      - $CI_COMMIT_MESSAGE =~ /skip-mbg/
  script:
    - echo "Starting mybatis generator..."
    - ...

4. 定义脚本(Script)

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

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

rulesonly/changes 用来确定何时执行作业。例如,只有当 support-entity 模块发生变更时才运行此作业:

install_entity:
  stage: install_entity_and_api
  tags:
    - support-dev
  rules:
    - changes:
        - support-entity/**/*
  script:
    - echo "Installing support-entity"
    - ...

6. 打包模块(Package Modules)

package_modules 阶段,您会编译和打包您的应用程序。例如:

package_core_service:
  stage: package_modules
  tags:
    - support-dev
  only:
    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: deploy
  tags:
    - support-dev
  only:
    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_BRANCH
  only:
    - master

在上面的例子中,如果这个作业在 master 分支上运行,$CI_COMMIT_BRANCH 将会被替换为 masterdeploy 命令将会接到 --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: deploy
  script:
    - 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 实例。

文章来源:https://blog.csdn.net/weixin_45979976/article/details/135082196
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。