Introduction
This is the third article in the Azure devops learning series. I have seen developers using devops are very much confused with variables and how they get replaced from the pipeline, their overrides and scope. In this article, I will be covering Azure devops variables, variable groups, and ARM template automation.
What are we covering in this article,
- Classic release and artifacts variables
- Variable groups
- Approvals
- Gates
If you want to learn more see the earlier labs in this series from the below links.
Classic release and artifacts variables
In a previous article we have created webapp and if you remember, we have chosen to hardcode the name in pipeline only. Let’s think of a few use cases where you need to reuse the same name in deploying pipeline for different stages like Dev, Staging, Prod.
Another use case where the same parameter value needs to be used across the pipelines meaning multiple pipelines has to use the same value.
Here is an answer for these user cases, pipeline variable and variable group.
Classic release and artifacts variables are used to send data throughout your pipeline. Each variable is stored as a string and its value can change as per scope of pipeline.
Classic release and artifacts variables are mainly of two types.
Default Variable
These are the variables which are used to get details for the execution context and its values are made available to run tasks through default variables. Your tasks and scripts use these variables to get information about the system, release, stage, or agent.
Default variables are read-only and their values are automatically set by the system except system.debug will explain later in this article.
Below are different default variables available to get details of different type.
- System variable
- Release variable
- Release stage variable -
- Agent variable-
- General Artifacts variable-
- Primary artifacts variable-
Custom Variable
There variables helps us define generic pipeline and then it can be customised to use variable value at stage or environment level.
It actually shares values across all of the tasks within one specific stage by using stage variables. Use a stage-level variable for values that vary from stage to stage (and are the same for all the tasks in a stage).
You define and manage these variables in the Variables tab of a release pipeline. In the Pipeline Variables page, open the Scope drop-down list and select the required stage. When you add a variable, set the Scope to the appropriate environment.
If you can see App service name is testapprnd here which will be getting deployed in azure as webapp and it is a hardcoded value.
Below from pipeline variable tab, you have the option to add a new variable and also an option to setup the scope for the variable. I have added a new parameter
arm_webapp_name which has value of testapprnd having scope set to Dev. The variable setup at stage level has higher precedence at release level. It will override the value.
The use case for this scenario is when you wanted to use a secret key which is different for all environments or connection strings, you can add three different parameters for Dev, Stage, Prod and can setup the scope.
You can see in the below diagram, there is an option of setting the variable name to release scope which shares values across all of the stages by using release pipeline variables.
The value release pipeline variable is when you need to use the same value across all the stages and tasks in the release pipeline, and you want to be able to change the value in a single place. One pipeline variable will be setup having release scope which is common across the environment.
At Task level variable name is pointed to app Service Name.
Another user case is when a variable value can be used across the pipelines. There is an option of using variable groups in the library which is globally available for all pipelines.
It actually shares values across all of the definitions in a project by using
variable groups.
You can also navigate to variable group from Library option from menu options.
I have created one variable group Rnd_Common and added one variable Appkey1 having test value in it.
To use this value in the pipeline we have to link this variable group to the pipeline where you wanted to use this variable value.
From the pipeline, there is a variable group menu which has the option to link all available variable groups. Right now, it has been linked to release scoped but you can change the scope at stage level also. Once linked these variable group values are available to pipelines where it is linked to send the value to the pipeline.
One option is secure the variable values used.You may want to secure the secrets and other sensitive information by clicking a lock button.
The values of the hidden (secret) variables are securely stored on the server and cannot be viewed by users after they are saved. During a deployment, the Azure Pipelines release service decrypts these values when referenced by the tasks and passes them to the agent over a secure HTTPS channel.
One important feature of Azure devops pipeline is you can view all the default and custom variables and their values after pipeline deployment steps named Initialize job.
Here the customeARM_webapp_Name value can be seen and other default pipelinevariables also.
Continuous Deployment
Trigger
Enabling the continuous deployment trigger will create a new release automatically every time a new build is available. Whenever there is a successful build available it will automatically create a new release ready to deploy.
This will deploy the new build to the environment depends on the pre deployment conditions. There are three options
- After Release
- After Stage
- Manual Only
If you use case id to deploy the new build automatically keep it after release. If it should be after any stage deployment like QA after Dev after stage should be chosen.
Manual is the way to deploy a release manually by deploy button.
Pre-deployment approvals
Approvers option let the user to dd who will approve the deployment. You can multiple user or group to provide approval for the deployment. Below are the options for multiple users to provide the approval either in any order, insequence or anyone user from the approved one.
- Any order
- In Sequence
- Any one user
There will be an option of approving from the Approve Button.
You can schedule deployment at a later date. You can also reassign approval to a different user. Release administrators can access and override all approval decisions also.
Gates
Gates feature allows user to have more control on the approval process, monitoring and provide a way to automate the approval process.
High level scenarios for Gates
- Incident and issues management
- External approvals
- Quality validation
- Security scan
- Infrastructure health
Gates allow you to configure automated calls to external services to which results are used to approve or reject a deployment. You can use gates to ensure that the release meets a wide range or criteria, without requiring user intervention.
There is option of enabling Gates for a particular stage.
On click of Add button there are a few options are available or extending the deployment approval process.
There are the below option for different user cases .
- Query Work items
Ensure the number of matching work items returned from a query is within a threshold
- Query Azure Monitor Alert
Observe the configured Azure monitor alert rules for active alerts
- Invoke Rest Api
Make a call to a REST API and continue if it returns a successful response.
- Invoke Azure Function
Trigger execution of an Azure function and ensure a successful completion.
- Check Azure policy compliance
This on resources within the scope of a given subscription and resource group, and optionally at a specific resource level.
The above are different options for the use cases to extend and have more control on approval process and the automation.
In Azure devops there isa feature, Query work item, which ensures the number of matching work items returned from a query is within a threshold which satisfies a condition to allow the automated approval for the deployment.
I have created an example shared query which has no QA Bugs having one task attached to it which is saved as task status is done.
Another very useful use case where the approval process is dependent on the external factor, rest API will be very useful. In this case let’s take a hypothetical situation where deployment needs to happen when an approving authority signs a paper and uploads a document. In this case you can create a rest api which can continuously poll to a scheduled interval to check the availability of document to certain secured location if it is available; then only it will automatically kick the deployment, otherwise wait for it.
Manual Intervention
This is also another feature in Gated approvals where you can specifically put the manual interventions for some tasks. There may be tasks that cannot be accomplished automatically.
For QA, let’s presume there is a use case where deployment needs a manual intervention. Then we can add an agentless job.
There is task step where Manual Intervention which can be added from market place.
This step has instructions to perform and also users or groups can be added which can be notified.
Users can click on the task where there is an option of putting up the comments and Resume/Reject the deployment depending on the output of the task assigned to him.
Conclusion
I hope this article will help you understand azure variables, variable groups, approvals and gates of CI/CD basic concept with azure devops. You can play around with it and learn more. Do provide your feedback in the comment section for better articles.
I will explain about ARM templates, infrastructure automation and Azure boards for managing the agile process in the next article. Until then, stay safe.
Keep learning and keep smiling.
Useful Resources
Thanks to the authors of the below links,
- https://docs.microsoft.com/en-us/azure/devops/pipelines/release/variables?view=azure-devops&tabs=powershell
- https://docs.microsoft.com/en-us/azure/devops/pipelines/release/deploy-using-approvals?view=azure-devops#configure-maninter
- https://docs.microsoft.com/en-us/azure/devops/pipelines/release/deploy-using-approvals?view=azure-devops