极狐GitLab CI 助力 .Net 项目研发效率和质量双提升

目录

.NET nuget 自动生成测试包（prerelease）版本号

.NET 版本号规范

持续集成自动打包

持续集成自动修改版本号

.NET 行级增量代码规范——拯救老项目

本地全量代码规范

行级增量代码规范

---

很多团队或开发者都会使用 C#、VB 等语言开发 .Net 应用。.NET 版本号的管理与对应代码的质量管理是一个比较充满挑战的话题。本文将介绍使用极狐GitLab CI 来实现 .NET 应用的版本号自动生成以及代码的增量扫描，从而提高 .NET 应用的研发效率。

.NET nuget 自动生成测试包（prerelease）版本号

---

NET 包（nuget）的版本号位于项目配置文件中（比如 Foo.csproj），比如这个包是 1.1.0 版本：

"Microsoft.NET.Sdk">
  
    netstandard2.0
    1.1.0
  

当开发新版时（比如 1.2.0），可能需要发布测试包，供联调和测试，当测试通过时，才会发布正式包。

可以使用这种 Git 工作流（也有其他工作流，大同小异）：

• 开发分支（如 feature-123）或合并请求（MR/PR）时：发布测试包；

• 主干分支或 Tag 时：发布正式包。

.NET 版本号规范

---

.NET 测试包的官方术语是 prerelease（预发行版），在 Visual Studio 包管理界面有一个开关：

版本号遵循语义化版本规范，常用如下命名：

• alpha：Alpha 版本，通常用于在制品和试验品

• beta：Beta 版本，通常指可用于下一计划版本的功能完整的版本，但可能包含已知 bug。

• rc：候选发布，通常可能为最终（稳定）版本，除非出现重大 bug。

如果项目测试流程不是很复杂，采用其中一个就够了，本文采用 beta。

所以版本号的变化历程可能是这样的：1.1.0 → 1.2.0-beta.1 → 1.2.0-beta.2 → 1.2.0-beta.3 → 1.2.0

如果手动修改，多次改代码很容易忘记改版本号。

有没有办法自动修改版本号？可以！那就是持续集成。

持续集成自动打包

---

提交代码，触发程序自动打包，这是持续集成的典型用途。使用 GitLab 持续集成配置 .NET 自动打包非常简单：

vi MyDotnetLibrary/.gitlab-ci.yml

.gitlab-ci.yml 的内容如下：

image: mcr.microsoft.com/dotnet/sdk:6.0
 
default:
  before_script:
    - dotnet nuget add source "$CI_SERVER_URL/api/v4/projects/$CI_PROJECT_ID/packages/nuget/index.json" -n GitLab -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD --store-password-in-clear-text
 
build_release:
  stage: build
  only:
    - main
  script:
    - rm -rf *.Tests
    - dotnet pack **/*.csproj -c Release
    - dotnet nuget push **/bin/Release/*.nupkg -s GitLab

可以看到上面代码判断了 only: - main，也就是主干分支时才打包。

持续集成自动修改版本号

---

开发新版本时，只需要修改一次版本号（比如 1.2.0）：

"Microsoft.NET.Sdk">
  
    netstandard2.0
    1.2.0
  

然后，让持续集成自动判断：

• 合并请求：在版本号后面添加测试版本号，变成 1.2.0-beta.123；

• 主干分支：不添加，保持 1.2.0。

GitLab 流水线内置了很多变量，有几个适合做测试版本号：

• CI_PIPELINE_IID：项目内的流水线 ID，从 1 开始自增，每次提交触发流水线都会自增；

• CI_MERGE_REQUEST_IID：项目内的合并请求 ID，从 1 开始自增，每次新建合并自增，但多次提交不会变。

可以看出 CI_PIPELINE_IID 适合做测试包的构建号。

拼接出想要的格式，使用 sed 命令替换：

export CI_PIPELINE_IID=123
sed "s||-beta.$CI_PIPELINE_IID|g" **/*.csproj

本地跑通命令，再把它复制到 .gitlab-ci.yml 中：

image: mcr.microsoft.com/dotnet/sdk:6.0
 
default:
  before_script:
    - dotnet nuget add source "$CI_SERVER_URL/api/v4/projects/$CI_PROJECT_ID/packages/nuget/index.json" -n GitLab -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD --store-password-in-clear-text
 
build_prerelease:
  stage: build
  only:
    - merge_requests
  script:
    - rm -rf *.Tests
    - sed -i "s||-beta.$CI_PIPELINE_IID|g" **/*.csproj
    - dotnet pack **/*.csproj -p:IncludeSymbols=true -p:SymbolPackageFormat=snupkg -c Debug
    - dotnet nuget push **/bin/Debug/*.nupkg -s GitLab
 
build_release:
  stage: build
  only:
    - main
  script:
    - rm -rf *.Tests
    - dotnet pack **/*.csproj -p:IncludeSymbols=true -p:SymbolPackageFormat=snupkg -c Release
    - dotnet nuget push **/bin/Release/*.nupkg -s GitLab

运行效果：

.NET 行级增量代码规范——拯救老项目

---

从 .NET 5 开始，SDK 内置了代码分析器，可以检查 C# 和 Visual Basic 的代码质量和样式问题，无需安装第三方工具，非常方便。

本地全量代码规范

---

修改项目配置文件（如 Foo.csproj、Bar.vbproj），加入 AnalysisMode 和 ErrorLog 属性：

  
    All
    compiler-diagnostics.sarif
  

AnalysisMode 允许这些值，按照从松到严排序为：

• None；

• Default；

• Minimum；

• Recommended；

• All。

配置完成，即可在编译时检查代码规范，可在 VS 界面点击或使用命令：

dotnet build

如果本地电脑语言为中文，.NET 会输出部分中文（3 条），但大部分信息还是英文的（96 条）。

可以看出全量扫描发现很多问题，怎么办？

• 一个人清理干净，其他人暂停提交。显然不合适；

• 所有人暂停工作，一起清理。也不合适，老代码改了可能出 bug；

• 增量代码规范，逐渐修复。是个好办法，在本地很难做到，可以借助 GitLab 服务端实现。

行级增量代码规范

---

配置 GitLab 持续集成 .gitlab-ci.yml：

image: mcr.microsoft.com/dotnet/sdk:6.0
 
build:
  stage: build
  allow_failure: true
  script:
    - dotnet build
  after_script:
    - export PATH="/root/.dotnet/tools:$PATH"
    # 此工具要求 .NET 6.0+，如果项目是 .NET 5.0，也使用 6.0 SDK 构建即可
    - dotnet tool install --global CodeQualityToGitlab
    - cq sarif compiler-diagnostics.sarif gl-code-quality-report.json $(pwd)/
  artifacts:
    reports:
      codequality: gl-code-quality-report.json

第一次 MR（提交 .gitlab-ci.yml） 会发现「全量的很多问题」或「代码质量没有变化」，没关系，先合并进去。

第二次 MR（修改老代码）会在 MR 页面提示修改的代码行是否产生了新问题，是否修复了老问题。

这就是 GitLab 的行级增量代码规范功能，它有几个特点：

• 配置简单——配置全量扫描命令，自动变成增量；

• 除了报错模式，还支持警告模式（allow_failure）——由评审人员决定「代码不规范时能否合并」，一般不允许合并，如果线上紧急故障可以合并；

• 提升开发效率——把代码质量问题直接显示在合并请求页面中，而无需到 CI 日志中翻找；

• 开放——公开代码质量报告 JSON 格式，各种语言的扫描工具都可以对接（很多工具已经有热心开发者对接，比如 Java Checkstyle、pylint、eslint）。

希望本文能帮助更多的开发者拯救老项目，落地代码规范。