.NET DevOps 接入指南 | 创建第一条流水线

使用流水线编辑器

GitLab提供了流水线编辑器,方便在线创建流水线。创建路径为:CI/CD->编辑器->创建新的 CI/CD 流水线。打开后如下图所示:
image

可以通过点击可视化标签页查看当前流水线的总体概貌,如下图所示:

image

从图中可以明显看出,整个流水线分为三个阶段:Build 、Test和Deploy阶段,其中Test 阶段包含两个Job,unit-test-joblint-test-job。下面就在原有示例的基础上,实现每次往develop分支推送时,进行自动构建与测试,并支持手动部署。

配置自动构建Job

ASP.NET Core 项目的构建需要依赖dotnet Sdk,因此要确保运行Job的Runner上拥有该依赖,GitLab 通过在定义Job时允许通过image参数指定依赖的镜像来解决环境依赖问题,因此对于.NET 项目可以根据项目依赖的dotnet runntime(运行时)选择对应的镜像依赖。修改build-job如下:

build-job:
    image: mcr.microsoft.com/dotnet/sdk:5.0 # 指定dotnet sdk 镜像
    stage: build # 指定所属阶段
    script:
        - dotnet build # 执行构建脚本
        - echo "build passed"

提交后,流水线会自动触发运行,经过一段时间后,通过点击CI/CD->流水线即可看到所有流水线的执行状态概览,如下图所示:

image

点击流水线,又可以看到每个阶段各个job的执行状态,如下图所示,也可以通过点击图中的Job来查看单个Job执行日志。
image

配置自动测试Job

有了上面自动构建的经验,自动测试的Job就很好写了,脚本如下:

unit-test-job:   
  image: mcr.microsoft.com/dotnet/sdk:5.0  # 指定dotnet sdk 镜像
  stage: test    # 指定所属阶段
  script:
    - dotnet test # 执行测试命令
    - echo "test passed"
image

再次提交,触发流水线后,发现本次流水线的测试阶段,毫无疑问的失败了,如上图所示。打开unit-test-job的查看执行日志如下:

// 省略部分日志
[xUnit.net 00:00:01.07]     AspNetCore.CiCd.Web.Tests.UnitTest1.IsPrime_InputIs1_ShouldReturnFalse [FAIL]
  Failed AspNetCore.CiCd.Web.Tests.UnitTest1.IsPrime_InputIs1_ShouldReturnFalse [2 ms]
  Error Message:
   System.NotImplementedException : Not implemented yet!
  Stack Trace:
     at AspNetCore.CiCd.Web.PrimeCheckService.IsPrimeNumber(Int32 num) in /builds/hBgzwyRz/0/demos/aspnetcore.cicd.demo/AspNetCore.CiCd.Web/PrimeCheckService.cs:line 14
   at AspNetCore.CiCd.Web.Tests.UnitTest1.IsPrime_InputIs1_ShouldReturnFalse() in /builds/hBgzwyRz/0/demos/aspnetcore.cicd.demo/AspNetCore.CiCd.Web.Tests/UnitTest1.cs:line 10
Failed!  - Failed:     1, Passed:     0, Skipped:     0, Total:     1, Duration: < 1 ms - /builds/hBgzwyRz/0/demos/aspnetcore.cicd.demo/AspNetCore.CiCd.Web.Tests/bin/Debug/net5.0/AspNetCore.CiCd.Web.Tests.dll (net5.0)
Cleaning up file based variables
00:01
ERROR: Job failed: command terminated with exit code 1

通过这个构建脚本来说明通过持续构建的自动测试脚本,可以帮助识别项目中的潜在问题,以保证代码质量。发现问题后,就可以创建Issue跟踪修复了。将判断逻辑修复如下,重新运行流水线即可成功。

public static class PrimeCheckService
{
    /// <summary>
    /// 素数:大于1的自然数,除了1和它自身外,不能被其他自然数整除的数叫做质数。
    /// </summary>
    /// <param name="num"></param>
    /// <returns></returns>
    public static bool IsPrimeNumber(int num)
    {
        if (num <= 1) return false;
        for (int i = 2; i < num; i++)
        {
            if (num % i == 0) return false;
        }
        return true;
    }
}

配置手动部署Job

对于部署,这里仅演示如何手动触发打包流程,并通过artifact支持下载打包应用。对于.NET Core 应用的打包主要借助于dotnet publish命令,因此可以添加publish-job如下所示:

publish-job:
  image: mcr.microsoft.com/dotnet/sdk:5.0  # 指定dotnet sdk 镜像
  stage: deploy    # 指定所属阶段
  when: manual # 指定手动触发该Job
  script:
    - dotnet publish --no-restore -o publish # 执行发布命令
    - echo "publish passed"
  artifacts:
    paths:
      - publish/    

再次提交,触发流水线后,发现publish-job并未执行,如下图所示,需要手动点击触发。

image

手动触发,执行完毕后,回到流水线列表,就可以下载发布产物,如下图所示:
image

优化Job提升性能

如果仔细观察会发现一个问题,那就是三个Job每次执行时都要重新还原NuGet包并构建,这是一个可以优化的点,针对这个点,有两种优化手段:

  1. 将自动构建、测试和发布合并到同一个Job,由于在同一个Runner中,因此可以避免重复还原和构建,该方法简单粗暴:
build-job:
    image: mcr.microsoft.com/dotnet/sdk:5.0 # 指定dotnet sdk 镜像
    stage: build # 指定所属阶段
    script:
        - dotnet build # 执行构建脚本
        - echo "build passed"
            - dotnet test # 执行测试命令
            - echo "test passed"
            - dotnet publish --no-restore -o publish # 执行发布命令
            - echo "publish passed"
  1. 使用cache关键字进行Nuget包的缓存:

  2. 添加全局缓存,并定义before_script

variables:
  NUGET_PACKAGES_DIRECTORY: ".nuget" # 定义变量,指定nuget包的还原路径
  NUGET_PACKAGES_CACHE_KEY: "$CI_PROJECT_PATH_SLUG" # 通过引用预置变量指定缓存的Key,对于当前项目值为:demos-aspnetcore-cicd-demo

before_script: 
  - dotnet restore --packages $NUGET_PACKAGES_DIRECTORY # 还原nuget包到指定.nuget文件夹

cache: &global_cache # 定义变量用于后续引用
  key: $NUGET_PACKAGES_CACHE_KEY # 指定缓存的Key
  policy: pull-push # 默认配置,即在Job开始时尝试拉取,在结束时上传
  paths:
    - $NUGET_PACKAGES_DIRECTORY # 缓存.nuget文件夹
    - './*/obj/project.assets.json' # 该文件记录项目的所有依赖和还原位置,该文件是确保--no-restore参数可用的关键
  1. 修改build-job,指定--no-restore参数:
build-job:
  image: mcr.microsoft.com/dotnet/sdk:5.0 # 指定dotnet sdk 镜像
  stage: build # 指定所属阶段
  script:
    - dotnet build --no-restore # 执行构建脚本,但不还原Nuget包
    - echo "build passed"
  1. 修改unit-test-job,指定--no-restore参数:
unit-test-job:   
  image: mcr.microsoft.com/dotnet/sdk:5.0  # 指定dotnet sdk 镜像
  stage: test    # 指定所属阶段
  script:    
    - dotnet test --no-restore # 执行测试命令,但不还原Nuget包
    - echo "test passed"
  cache:
    <<: *global_cache # 继承Cache
    policy: pull # 覆盖cache策略为仅拉取
  1. 修改publish-job,指定--no-restore参数:
publish-job:
  image: mcr.microsoft.com/dotnet/sdk:5.0  # 指定dotnet sdk 镜像
  stage: deploy    # 指定所属阶段
  when: manual # 指定手动触发该Job
  script:
    - dotnet publish --no-restore -o publish # 执行发布命令
    - echo "publish passed"
  cache:
    <<: *global_cache # 继承Cache
    policy: pull # 覆盖cache策略为仅拉取    
  artifacts:
    paths:
      - publish/   

至此,完成了第一条流水线的配置和优化,后续将继续介绍如何通过GitLab CI/CD实现构建镜像并部署到Kubernetes。

推荐阅读更多精彩内容