苏州晶体公司网站,渝北集团网站建设,自媒体专业,wordpress网站图标编写CI/CD自动化部署脚本
什么是CI/CD
CI/CD 是现代软件开发过程中的关键实践#xff0c;它包含两个缩写#xff1a;
CI#xff0c;或者持续集成#xff08;Continuous Integration#xff09;CD#xff0c;可以指持续交付#xff08;Continuous Delivery#xff09…编写CI/CD自动化部署脚本
什么是CI/CD
CI/CD 是现代软件开发过程中的关键实践它包含两个缩写
CI或者持续集成Continuous IntegrationCD可以指持续交付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- deploy2. 规定工作流程Workflow
您可以通过 workflow 关键词来限定什么条件下执行 CI/CD 流程。例如只有在 dev-deploy 分支上的提交时才运行此流程
workflow:rules:- if: $CI_COMMIT_BRANCH dev-deploy3. 编写作业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.skiptrue- 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 将会被替换为 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: deployscript:- echo Deploying to production servertags:- 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 的基本步骤 安装 GitLab Runner首先需要在你想要运行 CI/CD 作业的服务器上安装 GitLab Runner。GitLab 官方文档提供了不同操作系统上的安装指南。 注册 GitLab Runner安装完毕后你需要注册 Runner 到你的 GitLab 实例。这个过程涉及到为 Runner 指定 GitLab 实例的 URL 和一个注册令牌token。在注册过程中你可以指定一些标签tags来描述 Runner 的特性或功能。 配置 .gitlab-ci.yml 文件在你的 GitLab 项目中配置 .gitlab-ci.yml 文件来定义 CI/CD 作业。如果需要可以在作业中使用 tags 来指定应该由哪个 Runner 执行这些作业。 执行作业当你的项目中发生了像代码推送push或合并请求merge request这样的事件时GitLab CI/CD 会根据 .gitlab-ci.yml 文件中的定义来安排作业。如果作业中指定了 tagsGitLab 会找到具有相匹配标签的 Runner 来执行作业。
请注意GitLab Runner 要与 GitLab通常是 GitLab.com 或者自托管的 GitLab 实例进行通信以便获取作业并报告结果。因此它需要网络连接到 GitLab 实例。
