Anduin Xue
Anduin Xue

Anduin's Tech Blog

Azure DevOps

20
JUL

Restore a deleted branch from Azure DevOps using it's SDK

本文介绍了如何通过Azure DevOps SDK恢复被误删的代码分支的技术方案。文章指出当开发分支被删除后，可以通过Azure DevOps提供的Git API获取分支最后的提交记录，并利用Git引用更新机制重建分支。开发者需要先通过VssConnection建立认证连接，使用GitHttpClient获取分支的推送历史，找到被删除前的提交ID，再通过UpdateRefsAsync方法将分支引用重新指向该提交。这个过程涉及对Git底层引用机制的深入理解，包括如何处理旧对象ID与新对象ID的映射关系。代码示例展示了如何构建GitPushSearchCriteria查询参数，解析返回的RefUpdates数据，并构造GitRefUpdate请求体。特别值得注意的是，文章揭示了在更新引用时将OldObjectId设为全零占位符的技巧，这是实现分支恢复的关键技术点。技术实现过程中涉及的权限控制、项目名称与仓库ID的匹配等问题，为开发者提供了思考空间。当本地执行git fetch后，删除的分支会重新出现在版本历史中。这引发我们思考：如何在团队协作中设计分支保护策略？当多用户同时操作时，这种恢复机制是否具有原子性？如果在不同版本的Azure DevOps中执行该操作，可能会遇到哪些兼容性问题？--Qwen3

C# git Azure Azure DevOps SDK Git Branch Restore
01
APR

Use JetBrains code quality analyzer to prevent checking-in bad C# code

本文介绍了如何通过JetBrains ReSharper代码质量分析工具在Azure DevOps和GitHub Actions中自动拦截不符合规范的C#代码提交。文章展示了在持续集成流水线中集成ReSharper的YAML配置方案，包括安装代码质量分析插件、定义检查任务优先级以及通过.editorconfig文件自定义规则集的完整实践路径。特别指出在Azure DevOps中将代码检查任务置于构建之后测试之前可避免无效代码测试浪费资源，并揭示了无需购买ReSharper授权即可通过dotnet工具链实现本地代码质量检测的免费方案。文章引发思考：当自动化代码检查与团队开发习惯产生冲突时，如何平衡代码质量标准与实际开发灵活性？如何通过规则调整既避免过度约束又确保核心代码规范？读者或许会好奇：在云原生开发盛行的当下，如何将静态代码分析与动态测试策略结合形成更全面的质量保障体系？--Qwen3

C# Azure DevOps JetBrains Resharper Code Quality Pipelines
09
DEC

Display code coverage information for .NET Core project using Azure DevOps.

本文深入解析了如何在Azure DevOps中为.NET Core项目展示代码覆盖率数据，通过构建管道配置和测试结果分析，揭示了软件质量保障的关键路径。文章不仅提供了从构建管道创建到覆盖率徽章生成的完整操作链，更引发了对测试覆盖度与代码质量关系的深层思考——当测试覆盖率显示为87%时我们是否应该满足？如何通过覆盖率数据识别潜在的测试盲区？在跨平台开发场景中Linux系统仍不支持代码覆盖率收集这一现状是否会影响开发策略？文章通过Windows平台专有的构建配置要求，提示开发者在选择CI/CD环境时需权衡工具链兼容性与测试完整性。当覆盖率徽章以动态形式展示在readme文件中时这种可视化手段如何影响团队对代码质量的感知？更重要的是当测试通过率与覆盖率指标出现偏差时我们该如何解读这两组数据背后的技术含义？最终文章抛出一个值得所有开发者思考的问题：在追求100%覆盖率的过程中我们是否忽略了测试用例设计本身的质量？这种对测试方法论的反思或许比单纯追求数字更为重要。--Qwen3

.NET Core Azure DevOps .NET Test MSTest Integration Test Code coverage GitHub
05
MAR

Publish app from Azure DevOps to non-global Azure like Azure CN

如何将Azure DevOps构建的应用发布到非全球Azure环境例如Azure CN？这篇文章系统解析了跨环境部署的技术路径。当开发者习惯于Azure Global的便捷部署时，面对Azure China Cloud等隔离环境时常常陷入权限配置的困境——如何让自动化流水线突破订阅可见性的限制？文章通过构建服务主体的完整链路给出答案：从Azure AD注册应用开始，通过生成密钥和分配贡献者权限建立身份信任，最终在Azure DevOps中配置自定义云环境的服务连接。这个过程揭示了多云架构下身份认证的核心逻辑：当订阅ID和租户ID成为连接不同云环境的密码时，如何通过服务主体实现自动化部署的权限穿透？尤其值得关注的是手动配置服务连接时的环境选择机制，它打破了自动配置仅显示全球订阅的限制，为混合云场景下的持续交付提供了技术范式。当开发者面对复杂的多云环境时，是否应该重新思考统一身份管理的架构设计？在服务主体密钥的安全存储与权限最小化原则之间，又该如何平衡自动化部署的效率与风险？这些开放性问题为读者打开了持续集成的深度思考空间。--Qwen3

Azure App Service Azure Azure DevOps DevOps Azure CN China
  • 1