企业内部共享NuGet dll是否需独立仓库及AzureDevops版本号配置问题

1. 共享类库是否需要迁移到独立仓库？是否属于行业最佳实践？ #

如果你的类库已经是公司全组织范围共享的通用资产，迁移到独立仓库是行业通用的最佳实践，核心优势包括：

• 完全解耦类库和业务应用的迭代节奏，类库的版本更新、测试、发布流程不会受业务应用构建的影响
• 可以单独配置类库的权限管控、准入规则，比如仅类库维护团队有权提交代码、发布版本，避免业务应用的开发人员误修改共享代码
• 其他团队引入该共享类库时，不需要拉取整个业务应用的仓库代码，复用门槛更低
• 类库的变更日志、版本记录更清晰，不会和业务应用的提交记录混杂

当然也不是必须强制迁移，如果类库目前仍处于早期迭代阶段，仅支撑你当前开发的Web Api项目，和业务应用的改动高度绑定，暂时保留在同一解决方案中也可以，但长期要推广到全公司使用的话，还是建议迁移到独立仓库。

2. Azure DevOps中可以配置仅类库修改时才升级版本号吗？ #

当然可以，常见的实现方案有两种：

方案1：配置路径过滤的独立流水线 #

单独为共享类库创建一条构建发布流水线，在流水线触发规则中添加路径过滤，仅当类库对应目录下的文件发生变更时才触发流水线，自然也就只有类库改动时才会升级版本、打包发布。
参考YAML配置示例：

trigger:
  branches:
    include:
    - main # 替换为你要监听的分支
  paths:
    include:
    - src/YourSharedLib/** # 替换为你的共享类库在仓库中的路径
    exclude:
    - '*' # 排除所有其他路径的改动触发

方案2：同一流水线中添加变更判断逻辑 #

如果你不想拆分流水线，可以在原流水线中添加脚本任务，判断两次构建之间共享类库目录是否有变更，只有存在变更时才执行版本升级、打包、发布的后续步骤。
参考判断命令（bash）：

# 检查类库目录是否有改动
changed=$(git diff HEAD~1 HEAD --name-only | grep "src/YourSharedLib/" | wc -l)
echo "##vso[task.setvariable variable=libChanged]$changed"

之后在版本升级、打包任务的condition属性中配置eq(variables['libChanged'], '1')即可实现只有类库改动时才执行对应步骤。
另外建议搭配语义化版本规则使用，可以根据类库的提交信息（修复bug升补丁号、新增功能升次版本号、破坏性变更升主版本号）自动生成版本号，更符合共享类库的版本管理规范。

内容的提问来源于stack exchange，提问作者bartkub89