3 things that make my life easier in Azure DevOps pipelines
How I achieve more from my flows
“Imagination is more important than knowledge. For knowledge is limited, whereas imagination embraces the entire world, stimulating progress, giving birth to evolution.” - Albert Einstein
Intro
CI/CD systems nowadays give you much flexibility in achieving your goals. Azure DevOps is no different, with modules that you can install or build yourself and strategies that you can implement. On this note, you are limited only by your imagination in building your flows. Your project requirements can guide you in creating the perfect solution that suits your needs. In the following material, I will focus on 3 things that changed radically the way I approach CI/CD pipelines on Azure DevOps.
AZ CLI inside pipelines
The Azure Command-Line Interface (CLI) is a cross-platform command-line tool to connect to Azure and execute administrative commands on Azure resources. It allows the execution of commands through a terminal using interactive command-line prompts or a script. - from the official documentation
Almost all your flows on Azure DevOps end up on an Azure DevOps Agent that runs them on your infrastructure or systems. The agent itself is a Windows or Linux-based machine, that reads and runs your instructions. AZ CLI, as the definition states, is a command-line interface that communicates directly via API calls with Azure. This way, we can access all Azure DevOps and Azure Cloud resources using the Azure Agent.
Why is this interesting?
ideas from the top of my head
- While modules and plugins are easy to install and easy to use, essentially, they are just tools to call the Azure API and should be avoided, if possible, because they add extra time to your flows (to be used, they need to be downloaded and loaded on the agent, and that is time wasted for the flow) - Instead, if appropriate, use AZ CLI because it is a native solution, on the agent
- You need something that seems impossible, and you do not have any other solutions like modules or plugins (really not recommended; if possible avoid them :) - Search in AZ CLI and see your direct API calls solutions
- You need to access resources from Azure Cloud and do something very specific with them
General usage
a small overview of how to use AZ CLI inside your pipelines
AZ CLI, as you already noticed above, is a personal way of interacting with Azure and Azure DevOps API. Therefore, you as a person will need to interact with it. How can you automate this inside a pipeline? You will generate and use a personal access token or PAT in short.
A personal access token contains your security credentials for Azure DevOps. A PAT identifies you, your accessible organizations, and scopes of access. As such, they’re as critical as passwords, so you should treat them the same way.
If you’re working within Microsoft tools, then your Microsoft account (MSA) or Azure Active Directory (Azure AD) is an acceptable and well-supported approach. But, if you’re working with third-party tools that don’t support Microsoft or Azure AD accounts - or you don’t want to provide your primary credentials to the tool - use PATs to limit your risk. - from the official documentation
Following the documentation above, you will be able to generate a PAT for your very specific needs and very specific actions that your code needs to handle. After you have your PAT, you can use AZ CLI in your code through Bash or Powershell.
SHOW me some code! ANY code!
ok, ok hold your horses!
This is written in the Bash task, but you can use any scripting module for it:
- task: Bash@3
displayName: “Run AZ CLI to do something”
inputs:
targetType: ‘inline’
script: |
echo "Logging to Azure DevOps"
echo "$(PAT)" | az devops login --organization "$(org)" echo "Exporting PAT"
export AZURE_DEVOPS_EXT_PAT="$(PAT)" echo "Setting up the project used - MyAwesomeProject"
az devops configure --defaults project="$(project)" az cli or az devops commands will work now ...
For your code to work, you will need to map that generated PAT into a variable on the pipeline. Do not define the PAT variable in code because that way you will expose it — instead, use the GUI for this.*
*Just a small note here — neither the GUI, nor the variable in code does not offer complete protection of the PAT and both can be exposed, but at least in GUI, some effort is needed and it is not in plain text. To see more on how the secret variables can be exposed, have a look here.
- org and project are the default variables associated with your scope in Azure DevOps — can be defined in a variables.yaml file
- You need first to log in, so that is why we pipe the PAT into the login part
- AZURE_DEVOPS_EXT_PAT is the environment variable that we need to set on the agent, while we do our stuff
- You can default to one project or not, depending on your needs
- After the above steps, you will be able to run your AZ CLI commands from the agent, and do more with your flows
Automate triggering
This is an obvious choice when you like to automate everything but sometimes it gets overlooked.
Azure Pipelines provides several types of triggers to configure how your pipeline starts.
- Scheduled triggers start your pipeline based on a schedule, such as a nightly build. …
- Event-based triggers start your pipeline in response to events, such as creating a pull request or pushing to a branch. - from the official documentation
Using the scheduled triggering you can control your infrastructure with “control pipelines” that alert on deviations. When you want to chain 2 or more flows, you can do so with the event-based triggering.
Something that I like while chaining flows, is the fact that you can put the results from one flow in an artifact. Afterward, you can use the entire pipeline as a resource for another flow, that will consume the previous results from the artifact and so on.
Have I touched your curiosity? :) Will leave it as is for you to discover more about it.
Environment policies
An environment is a collection of resources that you can target with deployments from a pipeline. Typical examples of environment names are Dev, Test, QA, Staging, and Production. - from the official documentation
When working with environments you have more control over everything.
The options are on:
- the security part, where you define fine-grained controls on the teams and people that have access to the entire environment.
- the approvals and checks where you have multiple options of protecting your deployments or controlling the way they behave.
Depending on your project needs, this is a really good addition to your security baselines.
Before you go…
Either this inspired you or made you curious, I’m happy! Just push your flows for more, because it’s possible! Have other tips or ideas? Share them! Stay tuned, follow, subscribe, leave a comment, and be as social as possible for the sake of the Social Media Gods! I will sign out now and have a walk.
