耶律小贱

利用.gitlab-ci.yml来实现.net代码自动升级更新

Posted on by qutao

以下文章不能跳过，请逐行细看，相信看完后，你对.gitlab-ci.yml 如何自动部署你的代码会有深刻理解。

好了，目前我们的GIT版本管理器收到了程序员们提交的代码了，测试都OK了，产品经理已经决定上线了，然后呢？把代码编译好交给服务器运维？让运维更新包然后重启服务吗？不这样太不智能了。有没有一种能让一个没接触过服务器的小白都能一键实现编译和更新的功能呢？这还真有。

.gitlab-ci.yml 是 GitLab 用于配置 ‌CI/CD（持续集成/持续交付）流水线‌的核心文件。它定义了自动化任务的流程，例如代码构建、测试、部署等。

‌核心作用‌
‌自动化流程‌：在代码提交或合并请求时，自动触发任务（如编译、测试、部署）。
‌任务编排‌：将流程拆分为多个阶段（如 build, test, deploy），按顺序或并行执行。
‌环境管理‌：支持定义测试环境、生产环境，并可配置变量、密钥等敏感信息。

下面，我们就来试试看。好了，我这里有一个已经通过测试，提交到GIT的项目，让我们一步步来，让我想想，更新要做啥？对了，首先，你得告诉GitLab，你的服务器在哪，好，那让我们开始维护服务器吧，首先，我们得找到Runner。

配置Runner

所谓Runner，就是用于接收和执行GitLab的CI/CD作业的进程，这个通常位于设置,CI/CD里面，我们可以用他来配置指定的服务器，告诉他IP地址与令牌，像这里，我配置了一台Windows生产服务器，标签（31.85-Windows-Powershell），一台Linux编译服务器，标签（130.80-Linux-bash），为啥搞2台不一样的？嗯，只是为了下面演示用，声明，编译服务器和运行服务器在不同的平台，显然不是一个好选择，现实请不要这样尝试，让我们继续，

请记牢这些标签，这些标签将在你撰写.gitlab-ci.yml时用到

撰写.gitlab-ci.yml

好了，现在我们要开始撰写.gitlab-ci.yml，我们来看看这东西到底有哪些属性吧。

.gitlab-ci.yml文件是GitLab CI/CD（持续集成/持续部署）的配置文件‌，它描述了项目在版本控制过程中如何和何时执行各项任务。这个文件定义了一系列的工作（jobs），这些工作可以被组织到不同的阶段（stages），并在触发某些事件时自动运行，如代码提交或合并。每次提交或推送都会触发一个新的CI/CD pipeline，GitLab CI/CD系统会根据gitlab-ci.yml文件的配置来协调和控制这个pipeline的执行过程‌

主要组成部分和功能
‌1.Pipeline‌：一次Pipeline相当于一次构建任务，可以包含多个阶段，如安装依赖、运行测试、编译、部署等。任何提交或合并请求都会触发Pipeline的构建‌

2.Stages‌：表示一个构建阶段，所有阶段会按照顺序运行，当一个阶段完成后下一个阶段才会开始。如果任何一个阶段失败，整个Pipeline也会失败‌

‌3.Jobs‌：定义了具体的任务，每个Job属于一个Stage，包含执行的具体脚本或命令‌

好，看懂了1+1，学有用的，怎么快怎么来，我们下面容易得出下面的推导。

stages:
  - release
  - deploy
  - rollback

release:
  stage: release
  only:
    - tags
  tags:
    - '130.80-Linux-bash'
  script:
    - cd WT.AutomatedDeployment.WebSite
    - dotnet build
    - dotnet publish -c Release -o bin/Release/net5.0/publish/
    - rm -f bin/Release/net5.0/publish/web.config \
      && rm -f bin/Release/net5.0/publish/appsettings.json \
      && rm -f bin/Release/net5.0/publish/appsettings.Development.json \
      && rm -f bin/Release/net5.0/publish/appsettings.Production.json
  artifacts:
    paths:
      - WT.AutomatedDeployment.WebSite/bin/Release/net5.0/publish/
    expire_in: 1 day

deploy:
  stage: deploy
  when: manual
  tags:
    - '31.85-Windows-Powershell'
  dependencies:
    - release
  script:
    - chcp 65001
    - xcopy /E /I /EXCLUDE:D:\web\AutomatedDeployment20230111\exclude.txt D:\web\AutomatedDeployment20230111 C:\Users\wt-jx\Desktop\自动发布系统备份\%CI_COMMIT_TAG%
    - sc stop AutomatedDeployment
    - ping 127.0.0.1 -n 3 > nul
    - xcopy /E /I /Y WT.AutomatedDeployment.WebSite\bin\Release\net5.0\publish D:\web\AutomatedDeployment20230111
    - sc start AutomatedDeployment

rollback:
  stage: rollback
  when: manual
  tags:
    - '31.85-Windows-Powershell'
  dependencies:
    - deploy
  script:
    - chcp 65001
    - sc stop AutomatedDeployment
    - ping 127.0.0.1 -n 3 > nul
    - xcopy /E /I /Y C:\Users\wt-jx\Desktop\自动发布系统备份\%CI_COMMIT_TAG% D:\web\AutomatedDeployment20230111
    - sc start AutomatedDeployment

怎么了？突然觉得跳跃幅度太大了？没事，不用紧张，我们可以按照语句，一行行分析，看看我到底在做什么，相信马上你也能针对你的项目，配置你要的.gitlab-ci.yml

好，先来看stages:

这里定义了3个stages，依次为release、deploy、rollback，顾名思义，是编译、部署、回滚的意思，对没错，看看前面的stages的作用，当一个阶段完成后下一个阶段才会开始。所以编译成功才能部署，部署成功才能回滚……额，我还是希望项目上线后不要用到回滚，祝愿你们的项目都能顺利上线

再看看release属性:

下面这段就是编译服务器要做的事了

release:
  stage: release
  only:
    - tags
  tags:
    - '130.80-Linux-bash'
  script:
    - cd WT.AutomatedDeployment.WebSite
    - dotnet build
    - dotnet publish -c Release -o bin/Release/net5.0/publish/
    - rm -f bin/Release/net5.0/publish/web.config \
      && rm -f bin/Release/net5.0/publish/appsettings.json \
      && rm -f bin/Release/net5.0/publish/appsettings.Development.json \
      && rm -f bin/Release/net5.0/publish/appsettings.Production.json
  artifacts:
    paths:
      - WT.AutomatedDeployment.WebSite/bin/Release/net5.0/publish/
    expire_in: 1 day

首先，我们声明了当前的stage就是release，紧接着，我们定义了only的属性，啥意思呢？only 关键字用于定义在何种条件下应该运行特定的作业（job）。这通常用在 .gitlab-ci.yml 文件中，以指定哪些分支或标签（tags）应该触发特定的作业。我这里指定的是tags，啥意思呢，就是在GitLab的当前项目下，创建标签的时候，就会开始跑stages的release节点的配置内容。此处我们等下还要介绍。目前只要知道有这回事就好。

那tags属性又是咋回事：

紧接着，是tags属性，还写了’130.80-Linux-bash’，啥意思？这传标签还记得吧？刚刚在Runner配置的编译服务器，对，就是LINUX那台，就是让他去编译这个源代码吧。啊？怎么编译？问得好，那就script属性的事了。

script属性：

让我们来看看下面，忽略前面的”-“

cd WT.AutomatedDeployment.WebSite
dotnet build
dotnet publish -c Release -o bin/Release/net5.0/publish/
rm -f bin/Release/net5.0/publish/web.config \
      && rm -f bin/Release/net5.0/publish/appsettings.json \
      && rm -f bin/Release/net5.0/publish/appsettings.Development.json \
      && rm -f bin/Release/net5.0/publish/appsettings.Production.json

这一大坨是啥？Linux命令啊！和你在你的Linux编译服务器上手K代码去编译的事情没区别，喂喂，别啥都抄啊，这是我的项目，不是你的，抄了没用的，还看不懂？就这样，我一行行来吧，

1:打开当前用户下的WT.AutomatedDeployment.WebSite文件夹

2:用dotnet build编译下这个源码

3:发布项目，目录是在本地服务器的bin/Release/net5.0/publish/文件夹，并且在发布后，移除配置文件appsettings.json、appsettings.Development.json、appsettings.Production.json，这样可以防止覆盖生产环境时，这只是针对我的项目情况，不要轻易替换了生产的配置，当然，如果你的项目生产的配置一直在appsettings.Production.json中保持完好，当然也不需要移除这些文件了。

当然，你的项目还可能是Node.js、Java……，你的用npm build之类之类的命令，还不懂？那算了，可能你得找个Linux和以及你用的项目框架的书看看了。

那artifacts又是啥：

artifacts 关键字来定义在构建完成后需要保存的工件（如日志文件、测试报告、二进制文件等）。如果你想在后续的作业中复用这些工件，你可以通过 dependencies 关键字来指定依赖项。说人话，就是我得把这编译出的结果先保存起来，搞到WINDOWS里去，编译的结果在“WT.AutomatedDeployment.WebSite/bin/Release/net5.0/publish/”文件夹，让它1天过期足够用了。

artifacts:
    paths:
      - WT.AutomatedDeployment.WebSite/bin/Release/net5.0/publish/
    expire_in: 1 day

接下来开始部署了deploy：

这里是部署服务器要做的事，让我们来看看下面这段内容，同样，有一些熟悉的属性朋友，这里不再介绍，认识下几个生面孔

deploy:
  stage: deploy
  when: manual
  tags:
    - '31.85-Windows-Powershell'
  dependencies:
    - release
  script:
    - chcp 65001
    - xcopy /E /I /EXCLUDE:D:\web\AutomatedDeployment20230111\exclude.txt D:\web\AutomatedDeployment20230111 C:\Users\wt-jx\Desktop\自动发布系统备份\%CI_COMMIT_TAG%
    - sc stop AutomatedDeployment
    - ping 127.0.0.1 -n 3 > nul
    - xcopy /E /I /Y WT.AutomatedDeployment.WebSite\bin\Release\net5.0\publish D:\web\AutomatedDeployment20230111
    - sc start AutomatedDeployment

when:属性是做啥

when属性用于配置作业的运行条件，这里我选用了“manual”，啥意思呢？就是在上面的“release”自动完成之后，必须要人工确认无误后，在“流水线”手动点击确认执行“deploy”，那才能继续自动执行部署，“流水线”是什么鬼？这里稍后也会继续演示，稍安勿躁。

dependencies：是干嘛的

还记得刚刚搞的“artifacts”吗？把编译结果存下来的，刚刚提过的，所以，我们要把这个属性指向刚刚的节点，就是“release”节点，这样，我们就能用他编译出来存到artifacts的结果。对，1天过期了。

script：为啥和之前不一样？

这是在WINDOWS正式服务器里面呢，看看标签“31.85-Windows-Powershell”，还记得一开始的Runner配置的吗？刚刚是LINUX服务器，一样一行一行看吧

1：改变当前活动代码页为UTF-8,让当前的批处理窗口支持UTF-8格式的文件

2：把D:\web\AutomatedDeployment20230111复制到C:\Users\wt-jx\Desktop\自动发布系统备份\%CI_COMMIT_TAG%，并且排除D:\web\AutomatedDeployment20230111\exclude.txt，对，我在做备份，等下还原的时候用，那“%CI_COMMIT_TAG%”这是啥？问的好，这个就是标签名称，等下你会亲自创建它，这里就是把当前的版本，备份到指定的目录下，方便还原

3：停止我的服务，不停没法更新啊

4：ping一下，看看服务死透了没

5：把artifacts中保存的，编译好的WT.AutomatedDeployment.WebSite\bin\Release\net5.0\publish 复制到D:\web\AutomatedDeployment20230111之中。对，这个就是我当前生产程序运行的文件夹的根目录。到此未知，生产的文件已经被更新

6：把服务开回来

看完了，还不懂？如果你是Node.js的程序，你可能需要pm2 reload之类的，如果是docker部署的，你可能需要docker build啥的，按照你自己的服务器，你平时手K的维护代码，维护上去就好

再看看rollback：

这个还是部署服务器做的，一般都是客户支持那边决定回滚，我们会手工在工作流里执行

rollback:
  stage: rollback
  when: manual
  tags:
    - '31.85-Windows-Powershell'
  dependencies:
    - deploy
  script:
    - chcp 65001
    - sc stop AutomatedDeployment
    - ping 127.0.0.1 -n 3 > nul
    - xcopy /E /I /Y C:\Users\wt-jx\Desktop\自动发布系统备份\%CI_COMMIT_TAG% D:\web\AutomatedDeployment20230111
    - sc start AutomatedDeployment

这里，我就不在细说了，都是熟悉的面孔，比如，这里是要在deploy完成之后才能执行，回滚是manual的，需要手工在“流水线”点击才能回滚。这里还在把deploy备份好的之前生产文件捡回来，复制到生产根目录，然后重启系统，总之，操作后，原先的服务就回来了。

标签

好了，我们脚本写完了，然后呢？怎么做，还记得吗？我们上面release维护了一个only，叫tags，这就意味着，我们在GitLab创建标签，就能自动开始编译，让我们打开“仓库->标签->新建标签”

此时，标签保存完毕后，编译服务器就自动开始触发编译了。

流水线

点击流水线，我们会发现，我们创建的release、deploy、rollback都出来了，这时，我们只要依次点击（还记得我们之前维护的是手动“manual”吗？），就可以看到GitLab正在帮我们执行编译、部署……

截止，关于.gitlab-ci.yml介绍完毕。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注