7

I have a complicated release that spans multiple deployment groups and I am planning to use the 3rd party vsts-git-release-tag extension to tag the release. Ideally, the entire release (all jobs) would succeed first before tagging the repository.

So I am trying to work out what the best way to accomplish that is. If this were a build pipeline rather than a release pipeline, it is clear I could just arrange them using dependsOn, as follows.

jobs:
- job: Deployment_Group_1
  steps:
  - script: echo hello from Deployment Group 1
- job: Deployment_Group_2
  steps:
  - script: echo hello from Deployment Group 2
- job: Tag_Repo
  steps:
  - script: echo this is where I would tag the Repo
  dependsOn:
  - Deployment_Group_1
  - Deployment_Group_2

However, there doesn't seem to be equivalent functionality (at least currently) in release pipelines as specified in this document.

Note

Running multiple jobs in parallel is supported only in build pipelines at present. It is not yet supported in release pipelines.

Although it doesn't specifically mention the dependsOn feature, there doesn't seem to be a way to utilize it in release pipelines (correct me if I am wrong).

I realize I could probably create a separate stage containing a single job and task to create the Git tag, but that feels like a hack. Is there a better way to run a specific release job after all other release jobs have completed?

NightOwl888
  • 55,572
  • 24
  • 139
  • 212
  • Looks like a duplicate question https://stackoverflow.com/questions/29978758/how-do-i-run-a-google-dataflow-pipeline-from-a-google-app-engine-app?r=SearchResults&s=2|55.0695 – Klaus Heinrich Aug 01 '19 at 16:51
  • 3
    @KlausHeinrich - The linked question is about google cloud engine, this question is about azure pipelines. How is it a duplicate? – NightOwl888 Aug 01 '19 at 18:40

4 Answers4

7

Just a suggestion: you could make use of multistage pipelines which then are also very clearly represented in the Azure Devops Ui.

Stages have jobs, jobs have steps: enter image description here

Example pipeline yml for this:

trigger:
  batch: true
  branches:
    include:
      - "*"


resources:
  containers:
    - container: ubuntu
      image: ubuntu:18.04

stages:
  - stage: STAGE1
    jobs:
     - job: PrintInfoStage1Job1
       container: ubuntu
       steps:
          - script: |
              echo "THIS IS STAGE 1, JOB 1"
            displayName: "JOB 1"
     - job: PrintInfoStage1Job2
       dependsOn: PrintInfoStage1Job1
       container: ubuntu
       steps:
          - script: |
              echo "THIS IS STAGE 1, JOB 2"
            displayName: "JOB 2"

  - stage: STAGE2
    dependsOn: STAGE1
    jobs:
      - job: PrintInfoStage2Job1
        dependsOn: []
        container: ubuntu
        steps:
          - script: |
               echo "THIS IS THE STAGE 2, JOB 1"
            displayName: "JOB 1"

      - job: PrintInfoStage2Job2
        container: ubuntu
        dependsOn: []
        steps:
          - script: |
               echo "THIS IS THE STAGE 2, JOB 2"
            displayName: "JOB 2"

Just be sure to not miss switch on this preview feature on in your user's settings.

chris polzer
  • 3,219
  • 3
  • 28
  • 44
  • Stages are only supported in build pipelines. This question is specifically about release pipelines, which currently don't support YAML configuration. – NightOwl888 Dec 28 '21 at 13:54
  • You dont really need to use release pipelines at all anymore. If approvals are needed for deployments, you can implement these via deployment jobs and the binding to environments or by forceing approvals on secure variables or files. – chris polzer Jul 06 '22 at 09:48
  • That doesn't work for us because we have manual intervention tasks that are not supported in build pipelines. In one of them we have a mandatory release vote that takes 72 hours before we can release and in another we have a manual database deployment for a legacy system that has not been automated (for various non-technical reasons). – NightOwl888 Jul 06 '22 at 12:44
  • Please include an example of using "approvals on secure variable or files" in your answer. If these are indeed viable alternatives to release pipelines for manual approvals, it would be good to see a demonstration of this. – NightOwl888 Nov 07 '22 at 06:00
  • Hello, adding an example for the approvals is not really doable. Based on variables, you will have a variable group defined in Azure DevOps. On top of your variable group there is the approval tab. the dialog opened is self describing. Another way to go is to us deployment jobs where the "environment" parameter's string content will create an environment under "Environments" in your azure devops menu. Thats where ou define your approvals based on environments. (Link deployment jobs docs: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops) – chris polzer Nov 07 '22 at 10:14
5

After creating a test project and adding several jobs to a release pipeline for it, then running it several times in a row, it appears that the order of the jobs is deterministic. That is, they always seem to run in the order that they physically appear in the portal.

I did several Google searches, and this behavior doesn't seem be documented anywhere. So, I don't know for sure if it is guaranteed. But it will probably work for my case.

Please leave a comment if there are any official sources that confirm that the job order is guaranteed.

NightOwl888
  • 55,572
  • 24
  • 139
  • 212
  • 1
    you can use dependsOn https://stackoverflow.com/questions/71524681/run-job-in-sequence-in-azure-devops – volody Oct 18 '22 at 00:00
  • @volody your comment should be the answer. Indeed my jobs were not executing in the order they were created in the yaml file and 'dependsOn' was what I needed. – Abdelhakim Nov 06 '22 at 11:15
  • @Abdelhakim - Nope. AFAIK, there is no way to specify `dependsOn` in a *release pipeline*, which is what the question is about. This has nothing to do with a *build pipeline*, which everyone seems to be including an answer for. Release pipelines are not configurable via YAML, so none of these answers are relevant. – NightOwl888 Nov 07 '22 at 05:54
  • I think with my above answer regarding deployment jobs, environments an approvals, everything needed should be available to get rid of those ui clicked, unmanageable release pipelines? Great questions and discussion I have to say! – chris polzer Nov 07 '22 at 10:42
  • regarding the dependson: as long as you are not definiing it, everything is automatically depending on its predecessor. I learned so the hard way useing dynamic stages with output variables which then where not available for those dynamically created in the successor's successor stage – chris polzer Nov 07 '22 at 10:48
3

Looking at the example that has been specified, you don't need to create different jobs for each of the steps. Every task could be added in a single job.

jobs:
- job: 
  steps:
  - script: echo hello from Deployment Group 1
  - script: echo hello from Deployment Group 2
  - script: echo this is where I would tag the Repo

You can also remove Jobs > Job in the code if you want.

I was facing a similar issue with my jobs not being exected in a defined order. Also, I was referencing other templates for jobs.I was under impression that every template has to be in a new job. Later, I managed to dissolve my jobs into tasks.

Points to note:

  • Job runs on a sperate agent. Which you might not want, if it is just a sequence of scripts that you want to execute. Job essentially contains steps, which is a group of tasks.
  • Tasks in steps are executed one-by-one, so you don't have to provide order explicitly.
Sudarshan_SMD
  • 2,549
  • 33
  • 23
1

You can use conditions:

jobs:
- job: Deployment_Group_1
  steps:
  - script: echo hello from Deployment Group 1
- job: Deployment_Group_2
  dependsOn: Deployment_Group_1
  condition: succeeded()
  steps:
  - script: echo hello from Deployment Group 2
- job: Tag_Repo
  steps:
  - script: echo this is where I would tag the Repo
  dependsOn:
  - Deployment_Group_1
  - Deployment_Group_2
RasmusEmil
  • 11
  • 2