Automate Azure Boards iteration using PowerShell and Azure Pipelines

I start planning for the following year in the last two weeks of December. I use Azure DevOps to track my work  -break down goals into features, and features into user stories, which I map into sprints. Creating iterations and adding them to projects is something that anyone can automate.

Last year I used the PowerShell script stored at my GitHub repo: add-iterations-to-azure-devops-project. I ran the PowerShell script from my local laptop, and the thought of automating that did not cross my mind because I thought I had to do it only once a year.

Since then, I have changed my laptop and no longer have the Azure CLI and Azure DevOps modules installed. I am also working on two Azure DevOps projects requiring separate iterations and sprints. Moreover, variables had hardcoded values based on my requirements in the previous version of the PowerShell script. And so this year, I not only converted the hard-coded variables to command-line arguments but also created an azure pipelines YAML file to automate the process.

Note: The PowerShell script continues to support execution from a local laptop. If that is the case, please refer to this detailed note  –create-azure-devops-iterations-using-powershell.

The process of creating Azure DevOps iterations using pipelines consists of 5 steps.
If you want the code repository handy as you walk through the steps, here’s the link to my GitHub repo: add-iterations-to-azure-devops-project.

Step 1: Create a PAT
You can create an access token by following the steps mentioned in  –create a PAT.

Step 2: Create a variable group
I stored all the variables required by the pipeline YAML in a variable group. If you are new, you can follow my note azure-devops-library to learn how to create variable groups in Azure DevOps.
The PowerShell script requires eight variables, and I stored all of them in the variable group: add-iterations-to-azure-devops-project.

If you desire to change any variable name here, including the variable group name, you must change that in the code, too  -the PowerShell script and the azure-pipelines YAML file. I have secured the Organization and PAT value, which is why it is hidden.

Step 3: Create a pipeline
If you are new to using pipelines in Azure DevOps, you can follow my note at create-a-yaml-build-pipeline. I used the azure-pipelines.yml that I stored in my GitHub repository: add-iterations-to-azure-devops-project. The rest of the process of creating the pipeline is quite intuitive.

Step 4: Run the pipeline
The last step is to trigger the pipeline. When I ran the script for the first time, I had to provide permission for the pipeline to access the variable group referenced in the pipeline.

I did not have to provide permission for subsequent runs. You can review the latest build run log at kunduso.add-iterations-to-azure-devops-project.
I am copying a section of the log file below where you can see the output generated from the PowerShell script.

After the build succeeded, I verified my Azure DevOps team project and found the iterations and sprints correctly created.
Verify: I clicked on the gear icon with “Project Settings” at the bottom left corner of my Azure DevOps team portal. Under settings -> Boards -> Team configuration -> Iterations, I could see that the pipeline ran correctly and created the iterations. The below image is a section of the list.

And under Project Settings -> Boards -> Project configuration -> Iterations, I could see the Iterations were created.

Step 5: Revoke the PAT
Now that the pipeline had created the iterations, there was no point in keeping the PAT alive, and hence I revoked the PAT. In the future, when I require this automation, I will generate a new PAT and store the value securely in the Library. And once used, I will revoke the PAT again.

What are the benefits of this automation?
The automation process is independent of what is installed on my laptop; I did not have to install Azure CLI or keep up with the latest version. I only had to ensure the vmImage I am referring to in the pipelines YAML has the latest tools installed, which is usually the case. The second benefit is that with a few variable updates, I could run the script for a different Azure DevOps project.

Which option you select  -running the PowerShell script locally or using the pipelines YAML depends on your specific use case. If you want to automate using Azure DevOps, this note should be helpful to you. Let me know if you have any suggestions or questions.