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:
- Build and optionally test the code in the branch and output a build artifact
- 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
- 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.
Was this article helpful?