如何通过Azure DevOps管道在Azure Web服务部署多GitHub仓Angular与Node.js应用

你已经跑通Angular前端的Azure Web App部署的话，基础的Azure服务授权、DevOps项目权限这类前置配置基本都已经就绪，Node.js后端因为是独立仓库，单独建一条对应管道配置就行，整体逻辑和前端部署类似，只需要适配Node的构建、启动规则，具体流程如下：

• 提前在Azure上建好给Node后端用的独立Web App资源，运行时栈选和你本地开发一致的Node.js版本，Linux整体对Node生态适配更好，优先选
• 确认Azure DevOps项目已经和你的Azure订阅做好了资源管理服务连接（部署前端时已经配过的话直接复用就行，没配就去项目设置-服务连接里新建Azure Resource Manager类型的连接，授权对应订阅权限即可）
• 后端代码根目录必须有合法的package.json，scripts字段里要写好start命令，比如"start": "node src/index.js"；如果用TypeScript写的后端，要提前配好build编译脚本，别把编译步骤丢到线上启动阶段跑
• 代码里监听服务端口不要硬写固定值，统一读process.env.PORT，Azure平台会自动注入这个端口值，写死会直接导致服务启动失败

在DevOps项目里新建管道，代码源选择存放Node后端代码的GitHub仓库，完成授权后按顺序添加以下任务：

• Node版本指定任务：用内置的Node工具安装任务，选和线上Web App一致的Node版本，避免版本兼容导致的依赖安装失败、语法报错问题
• 依赖安装任务：执行npm ci --production，这个命令会严格按照lock文件安装依赖，比普通npm install稳定性高很多，加--production参数会跳过开发依赖，缩减部署包体积
• （可选）校验/构建任务：如果有单元测试、TS编译、代码压缩这类需求，加对应的命令行任务执行npm run test、npm run build即可，测试失败直接终止管道，避免问题版本上线
• 归档任务：把项目代码、安装好的生产依赖（提前做了编译的话把编译输出目录也带上）打包成zip压缩包，排除.git、测试用例、本地开发配置这类不需要上线的文件
• 部署任务：添加Azure Web App部署任务，参数选之前配好的Azure服务连接，应用类型对应你建的Web App操作系统，选中给后端创建的Web App实例，包路径选上一步生成的zip包。如果你用pm2做进程守护，直接在任务的启动命令栏填对应pm2启动指令就行，默认不填的话平台会自动执行npm start启动服务。

• 环境变量不要硬写在代码里，数据库连接串、JWT密钥、跨域白名单这类敏感/环境差异化配置，直接去Azure Web App的「配置-应用程序设置」里添加，服务启动时会自动注入到环境变量里，安全性更高
• 第一次跑管道的时候注意看任务日志，如果报启动失败，直接去Azure Web App的日志流里看具体报错，大概率是start脚本写错、Node版本不匹配、端口写死这几个问题
• 部署完成后先访问你写的健康检查接口确认服务正常，再把前端代码里配置的后端API地址改成这个后端Web App的域名，记得在后端的跨域配置里加上前端域名，不然前端请求会被浏览器拦截
• 如果要做灰度发布，可以给后端Web App加部署槽，管道配置成合并到开发分支就部署到测试槽、合并到主分支就部署到生产槽，测试没问题再切流量，不影响线上服务。

小提示：如果选Windows系统的Web App托管Node，平台会自动生成适配的IIS反向代理配置文件，不用自己手动传web.config，乱加反而容易导致路由异常。

常见踩坑点

• 不要把本地的node_modules文件夹传到GitHub仓库，也不要打进部署包，不同操作系统的依赖二进制文件不兼容，容易报莫名其妙的运行错误
• 如果后端有文件上传这类持久化存储需求，不要把文件存在Web App的本地文件系统里，实例重启后文件会丢失，要挂载专门的存储服务
• 部署完如果接口报500，先去Azure门户的日志流看实时报错，比在DevOps日志里找启动错误效率高很多

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