Answers: <p>@Shayki's <a href="https://devops.stackexchange.com/a/5703/11069">answer</a> was a large portion of what I was looking for (thanks!), but I was eventually able to figure out a solution that met all of my requirements. It involves a less than ideal use of the Release Description to propagate state between jobs.</p>
  
  <p>The updated flow diagram looks like this:</p>
  
  <p><a href="https://i.sstatic.net/p14fU.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/p14fU.png" alt="conditional flow solution"></a></p>
  
  <p>I was originally thinking of the conditional flow as an <code>if else</code> statement, but it is really more of multiple <code>if</code> statements where the condition is the same. If flag is set, do X; if flag is set, do Y; etc.</p>
  
  <h2>Details</h2>
  
  <p>Instead of running the agentless job when a previous condition fails (which would result in the entire deployment failing, a violation of one of my requirements), I created a custom condition that the agentless job runs as:</p>
  
  <p><a href="https://i.sstatic.net/6HRbE.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/6HRbE.png" alt="custom condition with variable expressions"></a></p>
  
  <p>If all the previous tasks have succeeded, and if the Release.ReleaseDescription variable contains the string defined in the _dbDeployErrors variable, then this job will execute (and the manual intervention task inside of it).</p>
  
  <p>The _dbDeployErrors variable isn't too important, I set it to <code>;DB_DEPLOY_ERRORS_$EnvironmentName</code>. The main idea is that, at least with the Web Designer, there is no way to pass information from an agent job to an agentless job. So I wrote a powershell script which uses the <a href="https://docs.microsoft.com/en-us/rest/api/azure/devops/release/releases/get%20release?view=azure-devops-rest-5.0" rel="nofollow noreferrer">Get Release</a> and <a href="https://docs.microsoft.com/en-us/rest/api/azure/devops/release/releases/update%20release?view=azure-devops-rest-5.0" rel="nofollow noreferrer">Update Release</a> Azure DevOps REST API to update the Release Description parameter on the release. This allows me to pass information to the next job in the deployment.</p>
  
  <p>The basic steps for setting this flag are:</p>
  
  <ol>
  <li>Run the db deployment</li>
  <li>If the deployment has errors, do not fail task, but instead set an agent variable</li>
  <li>Next task determines if the variable is set, and if so calls the Update Release API to append the flag to the release description</li>
  <li>Future jobs and tasks can now analyze the state of the release description variable</li>
  </ol>
  
  <p><em>Note: I set an agent variable instead of making the API call from the db-deploy script so that I can keep my deploy script clean and maintainable. I move the responsibility of calling the API to a dedicated script instead.</em></p>
  
  <p>If the Manual Intervention is resumed, then the third job executes as an agent job. It will attempt to deploy the db again, but this time it sets a <code>-Force</code> flag on the script to ignore possible data loss (it was approved by the one who performed the intervention). If this deployment succeeds, then a quick cleanup is run to call the Update Release API and clear the flag from the release description. Finally, the other tasks can resume as normal.</p>
  
  <p>Here is what the tasks in my final release definition looks like:</p>
  
  <p><a href="https://i.sstatic.net/dIhC0.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/dIhC0.png" alt="full release definition"></a></p>
  
Answers: CC BY-SA 4.0
Answers: 2018-12-13T23:59:27.987Z
Answers: 2018-12-13T23:59:27.987Z
Answers: AHaleIII
Answers: <p>Maybe is not a full resolution for you, but you can start with this:</p>
  
  <p>After the "Critical Task" add an "Agentless job"</p>
  
  <p><a href="https://i.sstatic.net/Ex1XG.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Ex1XG.png" alt="enter image description here"></a></p>
  
  <p>Add a "Manual Intervention" task</p>
  
  <p><a href="https://i.sstatic.net/UWRXW.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/UWRXW.png" alt="enter image description here"></a></p>
  
  <p>In the "Additional options" in the job specify "Run this job - Only when a previous job has failed"</p>
  
  <p><a href="https://i.sstatic.net/oHVND.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/oHVND.png" alt="enter image description here"></a></p>
  
Answers: CC BY-SA 4.0
Answers: 2018-12-12T14:11:16.370Z
Answers: 2018-12-12T14:11:16.370Z
Answers: Shayki Abramczyk
Body: <p>I am wondering if Azure DevOps has the ability to do conditional flow as part of a release definition.</p>
  
  <p><strong><em>My use case:</em></strong> I have a PowerShell script that deploys a SQL Server DACPAC to create or update a database. Sometimes this deployment will fail because a change was made that could potentially cause data loss. Instead of absolutely failing the deployment, I would like to trigger a manual intervention for a DBA to review the changes. If they resume, I would like to attempt the deployment again, but this time with a flag that will ignore potential data loss issues. </p>
  
  <p>Finally, if that second db deployment attempt is successful, I would like the flow to continue back to the rest of the deployment tasks.</p>
  
  <p><strong><em>Here is a general flow diagram:</em></strong></p>
  
  <p><a href="https://i.sstatic.net/mlXAx.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/mlXAx.png" alt="Azure DevOps Manual Intervention flow diagram"></a></p>
  
  <p><strong><em>Other requirements:</em></strong></p>
  
  <ul>
  <li>If the db deployment fails, but the manual intervention resumes and succeeds, I want the entire deployment to be marked as succeeded.</li>
  <li>I want the flow after resuming an intervention to merge back into existing tasks that would be run on db deployment success. Corollary: I do not want to maintain dual flows with identical tasks.</li>
  </ul>
  
  <p>I am using the Designer (Web UI) and not YAML for all my current builds/releases, but I am also interested if YAML has a solution for this.</p>
  
  <p><a href="https://docs.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=vsts&amp;tabs=yaml" rel="nofollow noreferrer">Azure DevOps has a section for Conditions</a>, but I did not find that particularly helpful. The number of conditions seems limited. <a href="https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=vsts&amp;tabs=yaml%2Cbatch#set-an-output-multi-job-variable" rel="nofollow noreferrer">It also looks like variables can be set on jobs</a>, but this appears to be only available with YAML.</p>
  
  <p>Is there a way to set up the conditionals at the end of phases/jobs or tasks to achieve this branching behavior?</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-05-02T21:53:02.513Z
Comments: I actually think you *can* handle this without the hacky step.  Let me see if I can set it up.
Comments: Sumo
Tags: <azure-devops><azure-pipelines>
Title: Azure DevOps Pipeline Conditional Flow with Manual Intervention
UserDisplayName: AHaleIII
ThreadText: # Azure DevOps Pipeline Conditional Flow with Manual Intervention
  
  (Asked by: username_0 on 2018-12-11)
  
  I am wondering if Azure DevOps has the ability to do conditional flow as part of a release definition.
  
  ***My use case:*** I have a PowerShell script that deploys a SQL Server DACPAC to create or update a database. Sometimes this deployment will fail because a change was made that could potentially cause data loss. Instead of absolutely failing the deployment, I would like to trigger a manual intervention for a DBA to review the changes. If they resume, I would like to attempt the deployment again, but this time with a flag that will ignore potential data loss issues.
  
  Finally, if that second db deployment attempt is successful, I would like the flow to continue back to the rest of the deployment tasks.
  
  ***Here is a general flow diagram:***
  
  [![Azure DevOps Manual Intervention flow diagram](https://i.sstatic.net/mlXAx.png)](https://i.sstatic.net/mlXAx.png)
  
  ***Other requirements:***
  
  * If the db deployment fails, but the manual intervention resumes and succeeds, I want the entire deployment to be marked as succeeded.
  * I want the flow after resuming an intervention to merge back into existing tasks that would be run on db deployment success. Corollary: I do not want to maintain dual flows with identical tasks.
  
  I am using the Designer (Web UI) and not YAML for all my current builds/releases, but I am also interested if YAML has a solution for this.
  
  [Azure DevOps has a section for Conditions](https://docs.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=vsts&tabs=yaml), but I did not find that particularly helpful. The number of conditions seems limited. [It also looks like variables can be set on jobs](https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=vsts&tabs=yaml%2Cbatch#set-an-output-multi-job-variable), but this appears to be only available with YAML.
  
  Is there a way to set up the conditionals at the end of phases/jobs or tasks to achieve this branching behavior?
  
  **Tags:** azure-devops, azure-pipelines
  
  > **Comments:**
  > **username_1**: I actually think you *can* handle this without the hacky step.  Let me see if I can set it up.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2018-12-13. Score: 2 | Accepted answer
  
  @username_2's [answer](https://devops.stackexchange.com/a/5703/11069) was a large portion of what I was looking for (thanks!), but I was eventually able to figure out a solution that met all of my requirements. It involves a less than ideal use of the Release Description to propagate state between jobs.
  
  The updated flow diagram looks like this:
  
  [![conditional flow solution](https://i.sstatic.net/p14fU.png)](https://i.sstatic.net/p14fU.png)
  
  I was originally thinking of the conditional flow as an `if else` statement, but it is really more of multiple `if` statements where the condition is the same. If flag is set, do X; if flag is set, do Y; etc.
  
  ## Details
  
  Instead of running the agentless job when a previous condition fails (which would result in the entire deployment failing, a violation of one of my requirements), I created a custom condition that the agentless job runs as:
  
  [![custom condition with variable expressions](https://i.sstatic.net/6HRbE.png)](https://i.sstatic.net/6HRbE.png)
  
  If all the previous tasks have succeeded, and if the Release.ReleaseDescription variable contains the string defined in the \_dbDeployErrors variable, then this job will execute (and the manual intervention task inside of it).
  
  The \_dbDeployErrors variable isn't too important, I set it to `;DB_DEPLOY_ERRORS_$EnvironmentName`. The main idea is that, at least with the Web Designer, there is no way to pass information from an agent job to an agentless job. So I wrote a powershell script which uses the [Get Release](https://docs.microsoft.com/en-us/rest/api/azure/devops/release/releases/get%20release?view=azure-devops-rest-5.0) and [Update Release](https://docs.microsoft.com/en-us/rest/api/azure/devops/release/releases/update%20release?view=azure-devops-rest-5.0) Azure DevOps REST API to update the Release Description parameter on the release. This allows me to pass information to the next job in the deployment.
  
  The basic steps for setting this flag are:
  
  1. Run the db deployment
  2. If the deployment has errors, do not fail task, but instead set an agent variable
  3. Next task determines if the variable is set, and if so calls the Update Release API to append the flag to the release description
  4. Future jobs and tasks can now analyze the state of the release description variable
  
  *Note: I set an agent variable instead of making the API call from the db-deploy script so that I can keep my deploy script clean and maintainable. I move the responsibility of calling the API to a dedicated script instead.*
  
  If the Manual Intervention is resumed, then the third job executes as an agent job. It will attempt to deploy the db again, but this time it sets a `-Force` flag on the script to ignore possible data loss (it was approved by the one who performed the intervention). If this deployment succeeds, then a quick cleanup is run to call the Update Release API and clear the flag from the release description. Finally, the other tasks can resume as normal.
  
  Here is what the tasks in my final release definition looks like:
  
  [![full release definition](https://i.sstatic.net/dIhC0.png)](https://i.sstatic.net/dIhC0.png)
  
  
  ---
  
  ### Answer by username_2 on 2018-12-12. Score: 1
  
  Maybe is not a full resolution for you, but you can start with this:
  
  After the "Critical Task" add an "Agentless job"
  
  [![enter image description here](https://i.sstatic.net/Ex1XG.png)](https://i.sstatic.net/Ex1XG.png)
  
  Add a "Manual Intervention" task
  
  [![enter image description here](https://i.sstatic.net/UWRXW.png)](https://i.sstatic.net/UWRXW.png)
  
  In the "Additional options" in the job specify "Run this job - Only when a previous job has failed"
  
  [![enter image description here](https://i.sstatic.net/oHVND.png)](https://i.sstatic.net/oHVND.png)
  
  
  ---
  
  