Azure DevOps 单个Build Artifact部署到多IIS站点及单站点部署咨询

最优落地思路：单条参数化动态发布管道 #

你列出的三个方案维护成本都偏高，更推荐用参数化的单条发布管道实现，既支持全量批量部署，也可以灵活选择单个/多个站点部署，不需要维护几十条管道或数十个独立阶段。

核心设计

• 把待部署客户端列表、部署目标服务器范围设为管道的可输入变量，支持单选、多选、全选，每次发布前按需选择即可。
• 客户端信息统一维护在独立配置（比如管道变量组、代码库内的JSON配置文件）中，后续新增/下架客户端只需修改配置，无需调整管道逻辑。

部署流程实现

1. 单份产物预拉取：先把构建产物拉取到所有目标服务器的本地临时目录，比如C:\Deploy\Temp\CurrentBuild，全量部署也仅需拉取一次产物，避免重复下载浪费带宽。
2. 动态遍历部署：根据输入的待部署客户端列表，循环执行以下操作：
   • 停止对应站点的IIS应用池：Stop-WebAppPool -Name "站点对应应用池名"
   • 用robocopy同步临时目录的产物到目标站点路径：robocopy C:\Deploy\Temp\CurrentBuild C:\Web\Sites\${ClientName} /MIR /NFL /NDL /NP，/MIR参数会自动对齐源目录和目标目录，清理冗余旧文件，比系统自带复制效率高很多。
   • 重启对应应用池：Start-WebAppPool -Name "站点对应应用池名"
3. 健康校验：每个站点部署完成后自动请求站点健康检查接口，校验启动状态，部署失败自动触发回滚。

可选优化项

• 新增备份逻辑：每次部署前先把目标站点的现有文件备份到C:\Deploy\Backup\${ClientName}\${BuildVersion}，出问题可以一键回滚到指定版本。
• 并行执行：利用部署组的并行执行能力，20台服务器同时执行部署任务，全量部署耗时和单站点部署耗时基本一致。
• 灰度能力：可以扩展参数支持按比例、按指定分组部署，适配灰度发布场景。

相比你列出方案的优势

• 维护成本极低：仅需维护1条管道，部署规则统一修改，不会出现多管道/多阶段逻辑不一致的问题。
• 灵活度完全满足需求：单选对应单站点部署，全选对应批量全量部署，多选对应部分站点升级，适配所有运维场景。
• 部署效率更高：全量部署仅拉取一次构建产物，相比30次独立部署节省大量时间。

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