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

使用流水线编辑器

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

image

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

image

从图中可以明显看出，整个流水线分为三个阶段：Build 、Test和Deploy阶段，其中Test 阶段包含两个Job，unit-test-job和lint-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
{
    /// 

    /// 素数：大于1的自然数，除了1和它自身外，不能被其他自然数整除的数叫做质数。
    /// 
    /// 
    /// 
    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"

2. 使用cache关键字进行Nuget包的缓存：

3. 添加全局缓存，并定义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参数可用的关键

2. 修改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"

3. 修改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策略为仅拉取

4. 修改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。