Using the Basic Process Template in Azure DevOps to make support management easier

I love the introduction of a Basic Process Template in Azure DevOps, and I will tell you why – it provides a very simple structure for projects that do not want or require a more complex set of prescriptions, but it still feeds from the best practices and the consensus of Agile methodologies so you are not left totally in the dark or to yourself.

An example is support management (as well as escalation management – for the sake of this post I will only refer to support, but many of these concepts apply to both). While there are tools like Service Now which provide an end-to-end lifecycle for support tickets, for certain teams or organisation it can be like hammering a nail for a picture on the wall with a sledgehammer. Doable, but at what cost? Let’s use this scenario as an example.

For starters, you don’t really need Iterations here. While you could use them – nothing wrong with iterations within a support team – you can do equally well without them, it is up to the team and how it is organised. Areas are what you might need: at least an area per product. Don’t be tempted to add many sub-areas under each product, you can easily leverage tags and be way tidier that way.

Also – don’t be scared if you see this error message:

It is perfectly normal, you don’t have bugs in this project! You have Issues instead. So disregard that.

Onto your backlog now, you can start by clicking on the button to create a new Work Item – which is going to be an Issue:

You can go on for a while. I also really like the fact that you can define where the new Work Item goes: top, bottom or at selection. Really neat IMHO.

Once you have a backlog, people start working on it – Azure Boards come in very handy at this, and they are already pre-set in a way that many people will find intuitive:

If you think about it, support management is the perfect example of a Lean project in practice. Stuff comes in, it’s worked on for a while and it comes out on the other side with a status. That’s really it, and the Basic Process Template is a perfect starting point for this kind of approach.

And let me stress that – it is a starting point. You can customise it like any other Process Template and you can change everything about it, but IMHO its real value is in the simplified angle from where it tries to make life simpler for these teams or situations where other structures might be overkill.

The continuous quest for automation in DevOps, and the Azure ML Studio example

When you think about it, most of the tasks you carry on in a DevOps environment revolve around automation.

Infrastructure as Code? It’s automation, right? Cool. Testing? As automated as possible. Integration with 3^rd party systems (SonarQube, WhiteSource, Azure DevOps, Jira, anything you retrieve data from or send data to) – it is automated.

You might think I live in a DevOps bubble. Let’s expand then – SRE? Data processing? How many things we rely on in modern development that have automation to their core? Excellent, you got your answer.

Mind that, it is not a Cloud exclusive. At the end of the day it’s technology we are talking about – hence my mantra “A technology problem is never really a problem. Technology can be bent at will.”

Now, I am working upon a client at the moment which has many efforts going on, and I was asked if I know of a way of automating deployment of Azure Machine Learning Experiments from Azure ML Studio.

Being completely oblivious to the technology I spent some time on it, and despite being a machine learning tool it is quite WYSIWYG. Hence no automation whatsoever, at the moment. Being a cloud-based product there isn’t the shadow of a doubt that eventually it will be implemented (given enough demand, obviously), but it is manual today. And I need to do this today, so there was no other option than going down a custom route.

Let’s pretend for a minute that I am not living under a rock, I don’t know how to use a search engine. The first step here would be to fire up Fiddler and see what happens when you press your buttons in the tool’s UI.

It is a modern web-based tool so there is communication between the UI and some API layer. There will be some sort of authentication involved. You can work your way around it. Eventually, you will be able to replicate this interaction with a script, and put it in your pipeline.

Given I do not live under a rock and I know how to use a browser the first search result would be the excellent Azure ML PS. Using it in a set of PowerShell scripts, stored in a Git repository, to be then consumed by an Azure PowerShell task in Azure DevOps Pipelines is really trivial. Again, this is a valid proposition for both on-premise systems as well as cloud-based systems.

Pipelines are brilliant for this – and I mean it. If you have something ready, or something that cannot use a task, just throw it within a PowerShell or a Bash script and you are in business. Use a Windows agent or a Unix agent, I don’t really care to be fair – as long as you can interact with the target system with a script everything is good in my view.

Sure, there will be situations where automating gets really difficult. Sometimes you can’t avoid doing manual things. Some other times you will be better off rewriting the whole thing. But usually, we are in a quest for continuous automation and it is what keeps us going. Keep automating!

How to reorder your stages in Azure Pipelines

It might seem funny, it might seem stupid... but this might happen to someone else, so it can be handy for the future. How do you re-order your stages in a pipeline?

Let's take this example:









Now, if you want to move Stage 2 to the end, you will try and click on the Stage UI or in the Tasks and you will not find how this is possible.

The answer is in the Pre-deployment conditions:









There you can find the triggers that can be linked to a Stage, which in this case is the completion of  a previous stage:



























Changing that value will make your re-ordering needs a reality 😊