使用流水线编辑器
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
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包并构建，这是一个可以优化的点，针对这个点，有两种优化手段：
- 将自动构建、测试和发布合并到同一个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"
使用
cache关键字进行Nuget包的缓存：添加全局缓存，并定义
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参数可用的关键
- 修改
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"
- 修改
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策略为仅拉取
- 修改
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。
