Kendra Little

14 October 2020

Recurring Schedules in Azure DevOps Release Pipelines – Artifacts and Stages

We had a recent forum question about Azure DevOps Release Pipelines that prompted me to look a bit into how schedules work in “classic” release pipelines.

While Microsoft has documentation on scheduling options, I found that there are multiple places where one can set a schedule. It wasn’t completely clear to me how these schedules interacted, so I did a bit of testing.

Here is a quick summary of what I found.

How changes flow from version control to the database

In the use case in question…

• The team is refreshing the database for an environment each night
• There is often work in progress in the database which is not ready to deploy, and they don’t want to lose it or have to manually apply it each day
• Their process is to check these changes into a branch in source control
• The team would like to automate the deployment of these changes to the environment each morning, after the database has been replaced

With a CI/CD solution like SQL Change Automation for SQL Server or Redgate Change Automation for Oracle, the flow of changes from version control to deployment in Azure DevOps is to:

1. Build and optionally test the code in the branch and output a build artifact
2. Run a task in a release pipeline taking the updated build artifact as an input which creates a release artifact against the target database
   • This is useful in case the team wants to review the history of exactly what was in the deployment at any time
3. Run a task in a release pipeline to deploy the release artifact to the target database

In this case, the desired behavior is to run the release pipeline steps on a predictable timed schedule.

But where exactly do you configure the schedule?

Azure DevOps Release Pipelines Schedules: Artifact and Stages

When you work in the “Classic” editor for a “release” pipeline in Azure DevOps, it is possible to set a schedule in the “Artifact” area, and it is also possible to set a schedule on the triggers for each stage.

It wasn’t 100% obvious to me how these schedules related.

After some experimentation, I have found two main things:

1) If you want the deployment to regularly kick off at a given time,  you definitely want to set a schedule on the Artifact

In other words, if you set a schedule on a Stage and don’t set a schedule on the artifact, the Stage won’t run. You need a schedule on the Artifact area to kick off picking up the build artifact to start the process.

There is a helpful option on the artifact schedule to “Only schedule releases if the source or pipeline has changed.”

2) You don’t have to set a schedule on the Stage

If you set a schedule in the Artifact area, you are free to leave the schedule blank on Stages if you would like.

In other words, each stage has a set of pre-deployment conditions, and the schedule is one of those pre-deployment conditions. You will only reach the Stage if the release itself is triggered in the first place — so the schedule on the Stage is only ever considered after the schedule on the Artifact has been met.

Is this intuitive?

After experimenting with this, I don’t find the behavior surprising or wrong.

However, I did need to do some tests to understand the behavior, so I wouldn’t say the “Classic” pipeline is fully intuitive in terms of scheduling. Hopefully this helps someone else out there with the same questions I had.