小松建设官方网站,网页设计的背景代码大全,wordpress 短代码按钮,中国建筑网官网查询报考目录
.NET nuget 自动生成测试包#xff08;prerelease#xff09;版本号
.NET 版本号规范
持续集成自动打包
持续集成自动修改版本号
.NET 行级增量代码规范——拯救老项目
本地全量代码规范
行级增量代码规范 很多团队或开发者都会使用 C#、VB 等语言开发 .Net 应用…目录
.NET nuget 自动生成测试包prerelease版本号
.NET 版本号规范
持续集成自动打包
持续集成自动修改版本号
.NET 行级增量代码规范——拯救老项目
本地全量代码规范
行级增量代码规范 很多团队或开发者都会使用 C#、VB 等语言开发 .Net 应用。.NET 版本号的管理与对应代码的质量管理是一个比较充满挑战的话题。本文将介绍使用极狐GitLab CI 来实现 .NET 应用的版本号自动生成以及代码的增量扫描从而提高 .NET 应用的研发效率。 .NET nuget 自动生成测试包prerelease版本号 NET 包nuget的版本号位于项目配置文件中比如 Foo.csproj比如这个包是 1.1.0 版本
Project SdkMicrosoft.NET.SdkPropertyGroupTargetFrameworknetstandard2.0/TargetFrameworkVersion1.1.0/Version/PropertyGroup
/Project当开发新版时比如 1.2.0可能需要发布测试包供联调和测试当测试通过时才会发布正式包。
可以使用这种 Git 工作流也有其他工作流大同小异 开发分支如 feature-123或合并请求MR/PR时发布测试包 主干分支或 Tag 时发布正式包。 .NET 版本号规范 .NET 测试包的官方术语是 prerelease预发行版在 Visual Studio 包管理界面有一个开关 版本号遵循语义化版本规范常用如下命名 alphaAlpha 版本通常用于在制品和试验品 betaBeta 版本通常指可用于下一计划版本的功能完整的版本但可能包含已知 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.0default: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-textbuild_release:stage: buildonly:- mainscript:- rm -rf *.Tests- dotnet pack **/*.csproj -c Release- dotnet nuget push **/bin/Release/*.nupkg -s GitLab可以看到上面代码判断了 only: - main也就是主干分支时才打包。 持续集成自动修改版本号 开发新版本时只需要修改一次版本号比如 1.2.0
Project SdkMicrosoft.NET.SdkPropertyGroupTargetFrameworknetstandard2.0/TargetFrameworkVersion1.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_IID123
sed s|/Version|-beta.$CI_PIPELINE_IID/Version|g **/*.csproj本地跑通命令再把它复制到 .gitlab-ci.yml 中
image: mcr.microsoft.com/dotnet/sdk:6.0default: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-textbuild_prerelease:stage: buildonly:- merge_requestsscript:- rm -rf *.Tests- sed -i s|/Version|-beta.$CI_PIPELINE_IID/Version|g **/*.csproj- dotnet pack **/*.csproj -p:IncludeSymbolstrue -p:SymbolPackageFormatsnupkg -c Debug- dotnet nuget push **/bin/Debug/*.nupkg -s GitLabbuild_release:stage: buildonly:- mainscript:- rm -rf *.Tests- dotnet pack **/*.csproj -p:IncludeSymbolstrue -p:SymbolPackageFormatsnupkg -c Release- dotnet nuget push **/bin/Release/*.nupkg -s GitLab运行效果 .NET 行级增量代码规范——拯救老项目 从 .NET 5 开始SDK 内置了代码分析器可以检查 C# 和 Visual Basic 的代码质量和样式问题无需安装第三方工具非常方便。 本地全量代码规范 修改项目配置文件如 Foo.csproj、Bar.vbproj加入 AnalysisMode 和 ErrorLog 属性
ProjectPropertyGroupAnalysisModeAll/AnalysisModeErrorLogcompiler-diagnostics.sarif/ErrorLog/PropertyGroup
/ProjectAnalysisMode 允许这些值按照从松到严排序为 None Default Minimum Recommended All。
配置完成即可在编译时检查代码规范可在 VS 界面点击或使用命令
dotnet build如果本地电脑语言为中文.NET 会输出部分中文3 条但大部分信息还是英文的96 条。
可以看出全量扫描发现很多问题怎么办 一个人清理干净其他人暂停提交。显然不合适 所有人暂停工作一起清理。也不合适老代码改了可能出 bug 增量代码规范逐渐修复。是个好办法在本地很难做到可以借助 GitLab 服务端实现。 行级增量代码规范 配置 GitLab 持续集成 .gitlab-ci.yml
image: mcr.microsoft.com/dotnet/sdk:6.0build:stage: buildallow_failure: truescript:- dotnet buildafter_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。
希望本文能帮助更多的开发者拯救老项目落地代码规范。
