我应该如何控制我的部署流程？

Question

新的管道最佳实践是什么？

文档随处可见，而且严重不完整。

允许你使用盖茨和检查的环境，就像一年前被标记为很快支持AppServices，这一部分已经被删除。

支持“你现在不必指定资源”的环境，这意味着我可以通过代码来做，现在已经被“Kubernetes资源和虚拟机资源类型当前支持”所取代。

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/environments?view=azure-devops#environment-resources

本应充当闸门的手动干预任务在等待了6个月后变成了一个美化的“睡眠”，现在它也只适用于服务器，而不适用于Microsoft托管的代理。

https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/manual-intervention?view=azure-devops#demands

当最佳实践被推到只有一个管道来运行验证、测试、构建、部署到开发、测试和生产时，你需要对发布流程进行该死的控制，而如何实现这一点却无处可寻。

这里的计划是什么？我如何实现这些目标？我是否打破了最佳实践，创建了多个管道？我是不是用遗留的发布管道把自己搞得一团糟？为什么发布管道功能和图形用户界面还没有移植到YAML？

至少可以说，设计和工作流程变得令人恼火，变得不必要的复杂和恼人。

我可能已经找到了一个解决方法：https://ochzhen.com/blog/manual-trigger-in-yaml-azure-pipelines

有谁可以帮助我解释或指出新的Azure管道的最佳实践的方向？

Answer 1

为了在管道中隔离不同的环境，我们使用变量和条件，就像这样的https://docs.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=azure-devops&tabs=yaml

# Special Run Description Variables
- name: IsPullRequest
  value: ${{ or(eq(variables['Build.Reason'], 'PullRequest'), eq(parameters.ForcePullRequest, true)) }}
   
- name: IsCIRun
  value: ${{ or(and(eq(variables['Build.SourceBranch'], 'refs/heads/develop'), in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI')), eq(parameters.DeployCI, true)) }}

- name: IsUatRun
  value: ${{ or(and(eq(variables['Build.SourceBranch'], 'refs/heads/main'), in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI')), eq(parameters.DeployUat, true)) }}

不确定这是否回答了你的问题，但希望这可以是一个很好的起点