VS2017与VSTS中Azure ARM模板及源码部署技术问询

我给你逐一拆解这些问题，结合行业通用实践和实际踩过的坑来解答：

问题1：VS2017中管理源码与ARM模板的最佳行业实践是什么？ #

• 隔离式结构管理：把ARM模板单独放在一个Azure Resource Group项目里，和MVC、API应用源码彻底分开；如果不想单独建项目，至少在解决方案根目录建Templates顶级文件夹，再按资源类型（如Network、AppService、Database）细分子文件夹，避免代码和模板混在一起导致维护混乱。
• 参数化+模块化：用parameters.json分离不同环境（开发/测试/生产）的配置，把重复的资源片段（比如VNet子网、App Service计划）做成嵌套模板，在VS里通过链接模板引用，大幅提升模板复用性。
• 源码控制规范：ARM模板和应用代码一起提交到VSTS仓库，但要确保模板变更的提交信息清晰（比如“更新生产环境DB连接字符串参数”），方便后续追溯。另外提交前一定要用VS自带的模板验证功能（右键模板→Validate）检查语法错误。
• 敏感信息外置：绝对不要把生产密钥、连接字符串硬编码到模板里，用Azure Key Vault或者VSTS变量组管理这些敏感值，在VS的参数文件里通过表达式引用即可。

问题2：如何查看指定资源组中部署的ARM模板版本？ #

Azure ARM部署本身没有内置的“版本号”，但可以通过以下方式追踪对应版本：

• Azure Portal操作：进入目标资源组→左侧菜单选择「部署」→找到对应的部署记录，点击进入后在「模板」标签页就能查看当时部署的模板内容。如果你的发布定义里把VSTS提交ID、构建ID写入了部署名称，还能直接关联到源码仓库的具体版本。
• 命令行查询：用Azure CLI执行az deployment group list --resource-group <你的资源组名称>，或者用PowerShell执行Get-AzResourceGroupDeployment -ResourceGroupName <你的资源组名称>，获取所有部署历史。每个部署条目里会包含模板的引用信息，也可以导出模板内容，再结合VSTS构建记录对应到源码版本。
• 进阶追踪方案：在构建过程中给ARM模板添加自定义标签，比如把VSTS的构建ID、Git提交哈希作为标签附加到部署的资源上，后续就能通过标签快速查询对应版本的模板。

问题3：若仅修改应用代码仍同步部署ARM模板，该方式是否推荐？ #

绝对不推荐，核心原因如下：

• 风险不可控：即使模板没有变更，重复部署ARM模板可能触发资源的幂等检查，极端情况下会导致App Service重启、数据库配置刷新等意外操作，影响业务可用性。
• 降低发布效率：复杂ARM模板的部署耗时不短，每次都跑部署会拉长发布周期，浪费资源。
• 追溯困难：混淆了应用代码变更和基础设施变更的记录，出问题时很难快速定位是代码还是模板导致的。
• 替代方案：在VSTS发布定义里添加条件判断——只有当ARM模板文件夹下的文件有变更时，才执行ARM部署任务；否则直接跳过，只部署应用代码。

问题4：在VSTS中通过单一构建发布定义同时部署源码与ARM模板是否为推荐方案？ #

分场景来看：

• 小型项目/初期阶段：可以接受，流程简单易维护，适合快速迭代验证。
• 中大型企业项目：强烈不推荐，建议拆分基础设施和应用代码的流水线：
  • 单独创建ARM模板的构建定义：负责模板验证、打包，发布到VSTS工件库；
  • 单独创建应用代码的构建定义：负责编译、测试、打包应用，发布到工件库；
  • 发布定义分别引用这两个工件，按需选择部署基础设施或应用。
    这样做的好处：隔离变更风险、权限管控更灵活（比如运维管基础设施，开发管应用）、支持独立回滚基础设施或应用版本。

问题5：在web app与API app的ARM模板中配置应用设置及连接字符串是否推荐？ #

推荐，但要注意正确的姿势：

• 优势：把应用配置和基础设施作为代码统一管理，确保所有环境的配置一致性，避免手动配置的失误。
• 正确做法：
  • 敏感信息（数据库密码、API密钥）绝对不能硬编码，用ARM模板引用Azure Key Vault的秘密，比如："value": "[reference(variables('keyVaultId'), '2019-09-01').getSecret('dbPassword')]"；
  • 环境特定的配置（比如开发/生产的API地址）放在参数文件里，或者用VSTS变量组在发布时注入；
  • 动态配置（比如不需要版本控制的临时设置）可以在ARM部署完成后，通过VSTS的「Azure App Service Settings」任务单独更新，不用修改模板。
• 反例：直接在模板里写明文的连接字符串或密钥，会把敏感信息暴露在源码仓库中，严重违反安全规范。

问题6：使用VSTS将ARM模板与源码部署至Azure环境的企业级实施方案是什么？ #

推荐采用基础设施即代码（IaC）+ 流水线分离 + 环境分层 + 安全管控的完整方案，具体如下：

1. 代码结构规范 #

• 解决方案分为三大块：MVC应用项目、API应用项目、Azure Resource Group项目（存放ARM模板，按模块拆分：core-infra（VNet、Storage）、app-infra（App Service Plan、Web/API App）、data-infra（Database））；
• 每个模块模板对应parameters.dev.json、parameters.test.json、parameters.prod.json，存放环境特定参数。

2. 构建流水线分离 #

• 基础设施构建流水线：拉取模板代码→运行ARM模板验证（az deployment group validate）→用arm-ttk做lint检查→打包模板为zip→发布到VSTS通用工件库，版本号采用语义化版本（如1.0.0-$(Build.BuildId)）；
• 应用构建流水线：拉取应用代码→编译→运行单元/集成测试→打包MVC和API应用为zip→发布到VSTS工件库，版本号可与基础设施版本关联或独立管理。

3. 发布流水线分层 #

• 按环境分层：开发→测试→预生产→生产，每个环境设置审批闸门（比如测试环境需要QA审批，生产需要运维经理审批）；
• 发布阶段：
  1. 部署基础设施：从工件库拉取模板包→选择对应环境的参数文件→用「Azure Resource Group Deployment」任务部署，同时注入Key Vault敏感信息；
  2. 部署应用代码：从工件库拉取应用包→用「Azure App Service Deploy」任务部署到对应Web/API App→用「Azure App Service Settings」补充动态配置；
• 每个环境的发布都保留完整日志，支持一键回滚。

4. 安全与管控 #

• 用VSTS权限组划分角色：开发团队仅能触发开发环境的应用部署，运维团队管理基础设施和生产环境；
• 所有敏感信息存储在Azure Key Vault，VSTS服务主体通过RBAC获取访问权限，全程不明文存储；
• 启用VSTS审计日志，记录所有构建发布操作，满足合规要求。

5. 自动化验证 #

• 基础设施构建阶段添加模板lint检查，确保符合最佳实践；
• 应用构建阶段添加集成测试，验证应用与基础设施的连通性；
• 预生产环境发布后自动运行冒烟测试，验证应用和基础设施的可用性。

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