Exercise - set up stages
In this demonstration, you'll investigate Stages.
Steps
Look at the other section in our release pipeline: Stages.
Click on Stage 1, and in the Stage properties pane, set Stage name to Development and close the pane.
Note
Stages can be based on templates. For example, you might deploy a web application using node.js or Python. For this walkthrough that won't matter because we're focusing on defining a strategy.
To add a second stage, click +Add in the Stages section and note the available options. You have a choice to create a new stage or clone an existing stage. Cloning a stage can help minimize the number of parameters that need to be configured. But for now, click New stage.
When the Select a template pane appears, scroll down to see the available templates. We don't need any of these, so click Empty job at the top, then in the Stage properties pane, set Stage name to Test, and then close the pane.
Hover over the Test stage and notice that two icons appear below. These are the same options that were available in the menu drop-down that we used before. Click the Clone icon to clone the stage to a new stage.
Click on the Copy of Test stage, and in the stage properties pane, set Stage name to Production and close the pane.
We've now defined a traditional deployment strategy. Each stage contains a set of tasks, and we'll look at those tasks later in the course.
Note
The same artifact sources move through each of the stages.
The lightning bolt icon on each stage shows that we can set a trigger as a pre-deployment condition. The person icon on both ends of a stage shows that we can have pre and post-deployment approvers.
Concurrent stages
You'll notice that now, we have all the stages one after each other in a sequence. It's also possible to have concurrent stages. Let's see an example.
Click the Test stage, and on the stage properties pane, set the Stage name to Test Team A and close the pane.
Hover over the Test Team A stage and click the Clone icon that appears to create a new cloned stage.
Click the Copy of Test Team A stage, and on the stage properties pane, set Stage name to Test Team B and close the pane.
Click the Pre-deployment conditions icon (that is, the lightning bolt) on Test Team B to open the pre-deployment settings.
In the Pre-deployment conditions pane, the stage can be triggered in three different ways:
The stage can immediately follow Release. (That is how the Development stage is currently configured). It can require manual triggering. Or, more commonly, it can follow another stage. Now, it's following Test Team A, but that's not what we want.
Choose Development from the Stages drop-down list**,** uncheck Test Team A, and then close the pane.
We now have two concurrent Test stages.
Stage versus Environment
You may have wondered why these items are called Stages and not Environments.
In the current configuration, we're using them for different environments. But it's not always the case. Here's a deployment strategy based upon regions instead:
Azure Pipelines are configurable and support a wide variety of deployment strategies. The name Stages is a better fit than Environment even though the stages can be used for environments.
Let's give the pipeline a better name and save the work.
At the top of the screen, hover over the New release pipeline name and click it to edit the name when a pencil appears. Type Release to all environments as the name and hit enter or click elsewhere on the screen.
For now, save the environment-based release pipeline you've created by clicking Save. Then, click OK in the Save dialog box.