Python for Automation in Azure DevOps

Anatoly Mironov

I recently discussed how Azure DevOps Work Items—particularly the Completed field—could be better utilized to aggregate a team’s burnup.

Suppose each project includes a backlog item or user story for time reporting, with every team member assigned a new task each week.

This discussion triggered me to learn more about the REST APIs in Azure DevOps, how to execute and how to automate the calls.

Hypothetical goal and Prompting

My hypothetical goal is to update the Completed field of “my” task (work item) and set it to 10, every Friday noon, completely automated. Let’s pretend I always work 10 hours a week in that project. All the deviations are okay to handle manually. My programming language of choice in this case is Python, because I feel like I want to practice more in Python.

I have prompted AI to get the bulk of the code and it worked pretty good. If you are curious, I have documented my prompts in a gist.

Automation Options Considered

The key is automation. I started by creating code in a python notebook. It worked well locally. So I considered my options for automation:

Running a scheduled task locally on my laptop doesn’t qualify as true automation, so I ruled that out

Power Automate. Theoretically I could achieve my goal, since they are connectors, but I can anticipate some problems:

  • I can anticipate how “dirty” (badly maintainable) some filter and extract operations can become, compared to the clean “pro dev” way in Python.
  • Azure DevOps actions are Power Automate Premium. While obtaining such a license is possible, I prefer not to depend on it for my automation setup.

Azure Function, Azure Automation, Azure Container App. A solution deployed to Azure is a good way, especially an Container App, but in my case, the solution is more “lightweight”, more towards “personal productivity”. Besides that, it would require a Service Principal (Managed Identity) and permissions which are hard to get nowadays.

Azure Pipelines for the win

Then there’s Azure Pipelines, which fits perfectly into my hypothetical scenario. You can see the details of the solution down below. It is my choice in this case. The advantages are:

  • It is in the same system as the work items, so no “integration” headache,
  • No extra Service Principals, no extra permissions
  • It runs on an existing infrastructure in Azure DevOps, on build agents
  • A lot of opportunities for further customization of the triggers and actions
  • The python file executed is no different from what I can run locally or have somewhere else. The Python code can be further developed to include additional steps such as data analysis and even generating and publishing burndown or burnup reports and charts.

Findings and thoughts

I have been using AI to generate the bulk of the code, although I had to make it work as a whole and come up with the idea of hosting it as an Azure Pipeline.

One concern I have is that Personal Access Tokens (PATs) remain the default recommendation in many official documents and online resources, for example in azure-devops-python-api. This is what you’ll get even when you ask AI to generate code. There are better authentication methods. Locally I use DefaultAzureCredential.

The API Versioning in Azure DevOps REST APIs are good for predictability but it’s not elegant.

There is a python package for Azure DevOps: azure-devops-python-api. I think I would have chosen it if I wrote my entire code by myself, the fact that AI could generate the “big” mass of code and it worked, didn’t trigger the developer laziness in me. A positive fact of not using an API wrapper (which the python package is) is that there is less can break. The bad thing is that my query calls have more lines of code, which in bigger scale impacts the maintainability in a negative way.

In order to call the api, the access token needs to be passed as an environment variable in the python environment where the script gets executed: SYSTEM_ACCESSTOKEN: $(System.AccessToken).

AI-generated solutions can sometimes be computationally expensive. Copilot or other code generators take your prompt and deliver a working solution. But it’s not necessarily the most efficient solution in terms of computation, cost and climate impact. In this case, it gets the entire list of child work items and then filters them locally, yes it succeeds, but let’s say there were a thousand of child items, what if there were paging or throttling. I as a developer have still the responsibility to cover those scenarios and make sure it does not utilize too much CPU power or bandwidth. It’s just a thought — perhaps better and consecutive prompting could improve the solution, but at the very least, developers should remain aware of these trade-offs. I imagine that in future code reviews, we’ll need to focus more on architectural qualities rather than just whether the code functions.

Final Solution with Azure Pipelines

Although I published this as a gist on GitHub, I am embedding them in the end of this post for reference. The solution consists of three files.

azure-pipelines.yaml orchestrates the code execution.

requirements.txt is a list of dependencies, in this case just one, but it may be more in the future.

report-time.py is the “heart” of the solution.