0
votes

With the classic Azure DevOps release pipeline our release flow was very easy to setup. We had a build pipeline running many times during the day. On success it deployed to our development environment. Every night the latest successful deployment to dev was released to our test environment (running automated tests for hours), before it deployed to UAT. But often we also need to deploy to test during the day, if we have a new change which needs to go directly into test or UAT. The classic pipelines allowed us to skip a stage, or deploy if the previous was only partly successful.

1) Development - automatic
2) Test - nightly or manually
3) UAT - nightly or manually
4) Staging - manual approval
5) Production - manual approval

With the multi-stage pipelines the same flow seems to be very difficult to do. At least when it comes to making it as a single deployment pipeline. The first part is fine. We can have our build trigger the development deployment. But how can we hold back the release to the test environment until 0:30am, while still retain the ability to also release it manually? If I created a separate test environment pipeline, then it could work if it had no triggers, but a schedule. Same with the UAT, as we also need the flexibility to manually run UAT deployments, then it would also need to go into its own pipeline. Releases to our staging and production environment we "gate" with manual approvals, which is fine.

While this technically could work, if we split the deployment pipeline into multiple pipelines it really gets difficult to manage "a release". Not to say that it kind of goes against the whole multi-stage pipeline principle if we create a separate pipeline per stage.

But with this being so easy to setup like this in the classic pipelines, then I cannot really imaging that other companies have not run into the same limitations. Is it just me who cannot see the light, or cannot this really not be done with multi-stage pipelines?

2
Hi, Just checking in to see whether this issue is still blocking you now? Any update for this issue?Vito Liu

2 Answers

1
votes

manually run UAT deployments

We could add Azure DevOps Multi-Stage Pipelines Approval Strategies in the yaml build.

Steps:

Open the tab Environments and click the button New environment-> Click the button approvals and checks-> My environment name is TEST.

enter image description here

Then use it in the yaml pipeline(just a sample):

trigger: none
 
pool:
  vmImage: 'ubuntu-latest'
 
stages:
- stage: A
  jobs:
  - deployment: 'MyDeployment'
    displayName: MyDeployment
    environment: 'TEST'
  - job: A1
    steps:
     - script: echo "##vso[task.setvariable variable=skipsubsequent;isOutput=true]false"
       name: printvar
 
- stage: B
  condition: and(succeeded(), ne(stageDependencies.A.A1.outputs['printvar.skipsubsequent'], 'true'))
  dependsOn: A
  jobs:
  - job: B1
    steps:
    - script: echo hello from Stage B

Result:

enter image description here

We could also configure schedule Trigger and use them in the multi-stage pipelines.

Note: The schedule trigger and Approval Strategies are using in the stage level.

0
votes

For scheduled jobs: you can use something like this in your YAML:

(Copied from Microsoft documentation)

schedules:
- cron: string # cron syntax defining a schedule
  displayName: string # friendly name given to a specific schedule
  branches:
    include: [ string ] # which branches the schedule applies to
    exclude: [ string ] # which branches to exclude from the schedule
  always: boolean # whether to always run the pipeline or only if there have been source code changes since the last successful scheduled run. The default is false.

For manual jobs, you can use the Create Release button to create and deploy a release manually. Do note that sometimes this can create a conflict with the schedule. Also, to "hold back a release" put an approver on the release, and then when approving, defer the release:

Defer

noting that it's in UTC, and it defaults to tomorrow - you can change it to any time after now.