因此,我的团队使用 azure devops 管道阶段来部署到不同的环境。这些阶段中的大多数都与我们的发布升级环境相关(例如:我们有一个集成环境、rc 环境、prod 临时环境,最后是 prod),并且它的构建使得您必须通过之前的每个阶段才能升级到下一个阶段(以及一大群管理人员和 itops 批准者)。在日常工作中不存在意外升级到我们的开发环境的风险。
也就是说,我们确实拥有三个上游环境,由大约 10 名贡献者级别的团队成员共享,并且没有任何审批流程;有时有人会选择他们的分支并启动,在所有阶段/环境上启动执行。这会导致大约一个小时的严重破坏,因为上游环境突然不再有代码来支持预期的功能,并且 QA 会编写各种无效的错误。此外,如果管理层和 ITOP 的审批者关注他们的电子邮件,他们会看到有关升级到产品周期的审批阶段的消息,这会带来令人尴尬的“流程”问题。
是否可以让阶段分为选择加入和选择退出,这样开发人员就必须选择他想要部署到的特定环境?我知道另一种选择是在所有环境中设置批准门,但这会导致人们只是(隐式地)选择所有内容并仅批准他们想要的内容,从而导致大量垃圾批准电子邮件。
TL;博士;当我在运行管道时单击“阶段”时,我希望看到默认情况下未选中的所有复选框,如果我不单击“阶段”并直接启动,我希望管道不执行任何操作。
当我在运行管道时单击“阶段”时,我希望看到默认情况下未选中的所有复选框
我认为这是不可能的。
如果我不单击“阶段”并直接启动,我希望管道什么都不做
“什么也不做”到底是什么意思?请注意,管道必须至少有一个阶段和/或一个作业,否则当您尝试对新构建进行排队时,它将失败。
您可以使用布尔参数来控制哪些阶段将运行或不运行。
类似:
在管道代码中,您可以使用条件根据布尔参数的值生成阶段:
name: test-pipeline-1
parameters:
- name: runOnProductionMode
displayName: 'Run on production mode'
type: boolean
default: true
trigger: none
pool: Default
stages:
- ${{ if parameters.runOnProductionMode }}:
- stage: Build
jobs:
- job: Build
steps:
- script: echo "Building the application"
- stage: Test
jobs:
- job: Test
steps:
- script: echo "Testing the application"
- stage: Deploy
jobs:
- job: Deploy
steps:
- script: echo "Deploying the application"
- ${{ if not(parameters.runOnProductionMode) }}:
- stage: Foo
jobs:
- job: foo
steps:
- script: echo "Foo"
- stage: Bar
jobs:
- job: bar
steps:
- script: echo "Bar"