返回文章列表
CI/CD | CodeReview | 源代码管理 | 2023-11-09

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

极狐GitLab
一体化安全 DevOps 平台

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

 

.NET nuget 自动生成测试包(prerelease)版本号

 

NET 包(nuget)的版本号位于项目配置文件中(比如 Foo.csproj),比如这个包是 1.1.0 版本:

 

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <Version>1.1.0</Version>
  </PropertyGroup>
</Project>

 

当开发新版时(比如 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):

 

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <Version>1.2.0</Version>
  </PropertyGroup>
</Project>

 

然后,让持续集成自动判断:

 

  • 合并请求:在版本号后面添加测试版本号,变成 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|</Version>|-beta.$CI_PIPELINE_IID</Version>|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|</Version>|-beta.$CI_PIPELINE_IID</Version>|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.csprojBar.vbproj),加入 AnalysisMode 和 ErrorLog 属性:

 

<Project>
  <PropertyGroup>
    <AnalysisMode>All</AnalysisMode>
    <ErrorLog>compiler-diagnostics.sarif</ErrorLog>
  </PropertyGroup>
</Project>

 

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)。

 

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

极狐GitLab 一体化DevOps平台 专为中国用户研发,免费试用60天专业版高级功能
售前咨询
联系电话
在线支持
预约演示