Azure Devops/Kudusync部署Azure Function时错误推送程序包问题

可能成因 #

• 临时目录残留：你事后查看的D:\local\Temp\zipdeploy\extracted属于临时缓存目录，部署任务完成后该目录会被后续部署任务覆盖、清理，你看到的内容并非对应日志中那次部署实际使用的源目录，时间戳早于部署时间也验证了这一点，部署日志对应的源目录已被销毁无法追溯。
• 管道配置错误：Azure DevOps部署任务的目标参数被变量覆盖，比如部署B应用的任务误绑定了A应用的服务连接、应用名称参数，导致A的部署包被推送到B的部署流程中，你看到的部署日志实际是A的包部署到B时产生的记录。
• 构建打包错误：CI构建环节同时生成了A、B两个应用的产物，打包B的部署包时误将A的dll包含在内，部署时自然会将A的dll同步到wwwroot目录。
• Kudu增量同步异常：如果未开启完整部署清理，KuduSync默认采用增量同步逻辑，旧部署残留的A dll没有被清理，反而被新的部署流程识别为需要保留的文件，出现异常的删除、拷贝日志。
• 跨应用操作混淆：如果两个应用配置了部署槽位，误执行了跨应用的槽位内容复制、交换操作，也会导致非预期的dll出现在目标应用的wwwroot目录。

排查步骤 #

• 先固定构建产物证据：在CI管道中添加构建包存档步骤，每次构建后将生成的zip部署包保留至少7天，出现异常时直接解压存档包检查是否混入了另一个应用的dll，排除构建环节问题。
• 核对部署任务参数：导出异常部署对应Azure DevOps管道的完整运行日志，检查部署任务的azureSubscription（服务连接）、appName（目标应用名）输入参数是否和预期一致，排查是否存在变量组全局覆盖、任务参数写错的情况。
• 核对Kudu部署清单：进入目标应用Kudu的D:\home\site\deployments目录，找到对应时间的部署记录文件夹，打开文件夹内的manifest文件，该文件记录了本次部署应该同步的所有文件列表，确认清单中是否包含异常dll，判断是部署包本身问题还是Kudu同步逻辑问题。
• 检查应用配置：确认目标应用是否开启了WEBSITE_RUN_FROM_PACKAGE配置项，若开启则实际运行的包存放在D:\home\data\SitePackages目录下，wwwroot目录的内容为旧部署残留，没有参考意义；可查看D:\home\data\SitePackages\packagename.txt确认当前运行的包名，解压对应包核查内容即可确认部署包是否正确。
• 核查操作日志：在Azure门户查看目标Function App的「活动日志」，排查对应时间点是否有非预期的部署触发、槽位交换、内容还原操作。

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