我正在尝试为示例原型创建CI / CD管道 . 因此，我已经开始简单地测试我的基础架构 - 我使用的是几乎未触及的ASP.NET Framework Web App样板（针对4.6.1） . 我完成的步骤是：
-
App已部署到Azure App Service .
-
其版本控件由Azure DevOps托管 .
-
已创建，设置和测试具有以下任务的构建管道（如果它执行（任务及其顺序，来自模板））：
-
Azure部署选项/设置绑定到存储库DevOps，因此构建也显示在Azure中，如果成功，则应在那里部署 .
-
Build Pipeline绑定到DevOps中的正确存储库
-
通过推送到主分支来触发构建
下一步是验证由于测试失败或任何其他原因导致的构建损坏是否已部署到Azure中的 生产环境 中 . 因为这个原因，我创建了一个失败的测试 .
这就是我被遗忘的地方 . 构建确实按预期失败，并且跳过“App Service Deploy”任务，因为构建任务在失败之前：
然而，那些破碎的构建 still 被部署到Azure和 生产环境 ，甚至没有等待管道完成 . 我正在验证小视觉更新实际上发生了变化 .
在DevOps中的管道完全遍历（或者甚至启动，如果找到代理需要更长时间）之前，只要发生推送，就在Azure中开始并完成构建：
（DevOps仍未完成）：
我在这做错了什么？我理解管道错了吗？我错过了某个设置步骤吗？我迷路了 .
Edit ：正如Josh所说，这也是我的触发器：
Edit 2.2 在Azure的App Service中，我对部署选项的更多说明，与Daniel的评论有关：
事实证明这是个问题 .
这是我将部署绑定到DevOps时唯一允许选择的选项 . 我不允许选择管道，只是一个项目和一个分支 . 在我所比较的教程中，设置是相同的（至少在此菜单中），但是构建不会从存储库触发，但是期望管道首先到达适当的步骤，这就是为什么我没有'认为这是罪魁祸首 . 是否有一些额外的设置，我错过了，表明它必须寻找管道，而不是直接从分支变化开火？
1 回答
您在Azure门户中设置的部署仅与源代码控制相关联，而不是与构建定义相关联 . 因此，每次您提交源代码控制时，会发生两件完全断开连接并且并行启动的事情，因为他们会收听相同的存储库以进行更改：
构建在管道中发射 .
Azure网站使用您刚推送到源代码管理的版本进行更新，因为其部署选项已绑定到该版本 .
删除＃2，你的问题就会消失 . 您在管道中设置要更新的App Service，您不需要在App Service本身中添加其他钩子 .