最近后台和评论区的讨论很集中：GitHub Models 说关就关了，微软又在各种场合把开发者往 GitHub 上引，那还在用 Azure DevOps 的团队，是不是该连夜搬家了？
我把最近大半年微软的官方动作、媒体报道和社区讨论翻了一遍，先说结论：Azure DevOps 没有死，但微软的心确实在往 GitHub 偏。 现在最该做的不是恐慌迁移，而是对号入座，想清楚自己是"该留、该动、还是该看"。
一、先分清：哪些是收缩信号，哪些是照常维护
把传闻放一边，只看有据可查的事实，最近一年微软这边其实释放了两组完全相反的信号。
收缩这边，最扎眼的就是 GitHub Models。这个免费 AI 模型试验场在 7 月 30 日全面下线，Playground、模型目录、推理 API、BYOK 端点全关，6 月中旬就停了新用户注册，官方给的替代方案是 Azure AI Foundry。知乎再往前看，GitHub 界面改版的报道里也明确提到，这背后有微软推动用户从 Azure DevOps 向 GitHub 迁移的战略考量。微博类似的整合动作还有不少，比如 Teams 个人版退出中国大陆、GitHub Models 并入 Azure AI Foundry——微软正在把零散的免费服务收拢到几条主线上。
但另一边，维护信号同样真实。本地部署的 Azure DevOps Server 照常迭代，25H2 版本今年 4 月还在正常更新。知乎今年 3 月，Microsoft.Testing.Platform 在 Azure DevOps 中获得全面支持，说明云端 ADO 的功能更新并没有停。知乎6 月 NPM 供应链投毒事件里，微软官方建议开发者改用 Azure CLI、Azure DevOps Pipelines 和 VS Code——ADO 流水线在微软眼里依然是"可信构建通道"；上周（8 月 12 日）发布的 Visual Studio 2026 v18.9，仍然同时支持 GitHub 和 Azure DevOps 两种仓库。
二、看懂微软的真实算盘
这两组信号放在一起，其实指向同一个判断：微软不是在"砍掉" Azure DevOps，而是在做能力收敛。新的、面向未来的东西（AI 模型服务、Copilot 集成、安全能力）优先长在 GitHub 和 Azure AI Foundry 上，而 ADO 进入"维护期"——能用、会修安全问题、偶有功能补充，但大概率不再是重投入的方向。
对存量用户来说，这意味着一个窗口期：现在迁移不紧急，但越往后拖，生态势能差越大。B站上 Azure DevOps 的教程还在更新，CI/CD、Boards、Test Plans、AZ-400 备考内容都不少，但你能明显感觉到，新内容、新讨论的重心已经在往 GitHub Actions 和 GitHub Projects 那边移了。
三、对号入座：你属于哪一类
第一类，深度微软栈企业（.NET + Azure + Entra ID，代码和流水线全在 ADO 上）。建议：留在原地，立好观察哨。 ADO 和微软技术体系的绑定是它最深的护城河，Azure、Windows Server、.NET 和 Entra ID 的账号体系都能直接打通。知乎它的 Boards 工作项追踪、多阶段流水线审批、环境和权限体系，目前 GitHub 侧的对应能力还没完全追平，硬迁的成本大于收益。微软没有给出云端 ADO 的强制时间表之前，按兵不动是理性的。
第二类，代码已经在 GitHub、只用 ADO 跑流水线或看板的混合团队。建议：主动往 GitHub 收。 用 Actions 替代 Pipelines、用 Projects 替代 Boards，一次收拢，避免两套体系的长期维护成本。这类团队迁移阻力最小，收益最直接。
第三类，合规要求必须本地部署的行业（金融、政企、制造）。建议：该升级升级，这事跟你关系最小。 Azure DevOps Server 25H2 正常更新，本地版是目前最稳的形态，不用被云端的风向带节奏。
第四类，正在学 ADO 的个人开发者和学生。建议：把 GitHub Actions 当主线学，ADO 当加分项。 现有的 ADO 教程依然有效，企业招聘里 ADO 经验也值钱，但如果只能投入一份精力，押在 GitHub 生态上的长期回报更高。
四、如果决定要动，这份检查清单先收好
迁移翻车基本都翻在这几件事上：
工作项和迭代历史——Boards 里多年的需求、缺陷、迭代记录，是迁移里最重的一块，先确认目标平台能不能接住你的字段和工作流，接不住就要想清楚哪些历史数据值得保留。
流水线资产——YAML 流水线语法和 GitHub Actions 不通用，任务、变量组、服务连接都要逐个翻译；服务连接背后是权限和凭据，务必先盘点再动手。
扩展和市场依赖——ADO Marketplace 里装的扩展，很多在 GitHub 侧没有一对等替品，提前列清单。
权限模型——从 Entra ID 的组权限切到 GitHub 的团队权限，映射关系要提前设计，别等迁完才发现权限失控。
顺序——先建新、跑通、验证，再关旧。任何"先停旧再建新的"都是事故预定。
五、接下来盯住这三个信号
什么时候该从"观望"切换到"行动"？盯这三件事就够了：
微软是否开始限制新建 Azure DevOps 组织，或者官方正式公布云端 ADO 的退役时间表——这是最硬的发令枪；
官方迁移工具的成熟度——什么时候微软自己出 Boards/工作项的官方迁移通道，什么时候才是大规模迁移的合适时机；
GitHub Actions 和 Projects 的企业级能力补齐进度——审批流、权限治理、审计这些 ADO 的强项，GitHub 每补齐一块，迁移的天平就动一分。
最后总结一句：Azure DevOps 现在不是"沉船"，而是一艘进入保养期的老船——还能开，也安全，但新船都下在 GitHub 的船坞里了。深度绑定的团队不用急着跳船，混合团队可以开始收拢，学习者把主技能押在 GitHub 上。收藏这篇，等微软真的给出时间表那天，你照着清单动就行。
你在用 Azure DevOps 吗？是打算留守还是迁移？评论区聊聊你的团队现状。
