VisualStudio.com TFS自动化发布至IIS的分支Bug修复构建方案咨询

这确实是单分支构建部署模式里的典型痛点——生产bug要修复，但DEV分支已经堆了一堆新开发的代码，总不能为了修生产问题把DEV的进度回滚吧？别慌，我给你一套适配VisualStudio.com TFS的优化方案，从分支策略到构建发布全环节调整：

首先要打破“单一分支包走全环境”的逻辑，给每个环境配专属的代码分支，再加上专门的修复分支：

• 分支与环境强绑定：明确PROD分支是生产环境的唯一代码来源，STG对应预发布环境，DEV专门放开发中的代码。三个分支各自独立，DEV的新开发完全不影响生产代码基线。
• 新增Hotfix分支处理生产bug：当生产出问题时，直接从PROD分支拉出一个hotfix/[bug编号或描述]分支，在这个分支上专注修复bug。修复完成后，先合并到PROD分支（部署生产），再把修复代码合并回DEV和STG分支——这样既解决了生产问题，又不会干扰DEV的新开发，还能让后续的开发代码包含这个修复。

在TFS的构建定义里做以下调整，确保每个分支的构建都是独立的：

• 分支专属触发规则：给每个构建定义设置对应的触发分支——比如DEV的构建定义只在DEV分支有提交时触发，PROD和Hotfix的构建定义只监听PROD和hotfix/*分支的变更。这样就不会出现用DEV分支的代码构建生产包的情况。
• 构建包打分支标签：给不同分支的构建包加上专属版本标识，比如dev-v1.0.20240520、prod-v1.0.12、hotfix-v1.0.13，这样后续发布时一眼就能识别包的来源，避免搞错。

发布环节要做两个关键调整：

• 支持手动选择构建包：在TFS的发布管道里，不要默认绑定“最新构建包”，而是允许手动选择指定版本的包。这样当需要部署Hotfix修复时，直接选hotfix分支生成的包就行，不用碰DEV的包。
• 加环境审批机制：比如从STG到PROD的部署，必须经过指定负责人的审批才能执行。同时，Hotfix包部署到生产后，一定要记得把修复代码同步回DEV和STG分支，保持所有分支的代码基线一致，避免后续出现重复bug。

• 分支保护规则：给PROD分支设置保护，禁止直接提交代码，必须通过Pull Request（如果用Git）或者变更集审核（如果用TFVC）才能合并，防止有人不小心把DEV的代码推到生产分支。
• 构建包保留策略：配置TFS保留每个分支最近的10-20个构建包，万一生产部署出问题，能快速找到历史包回滚，不用重新构建。

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