I’ve been doing work with Azure Devops lately and since there’s things to learn, there will be blog posts.

Now I am well known for my vitriolic views on Microsoft’s approach to ALM (Application Lifecycle Management) which were mainly represented in TFS, a behemoth that is now in its 5th (?) rebranding phase. Only this time it looks more like a reincarnation. It has been 13 years since they first gave it a go after all.

First impressions

The complexity is now mostly gone, hidden away. This is a good thing. You can still trace Microsoft’s need to satisfy enterprise policies and wierd gate-keeping bureaucracy, but these things are mostly hidden in security and access policy configuration pages. And the defaults are finally sane.

The mainly point-and-click GUI driven way of doing everything is still there and it is still offered as the “way to do things” but at least the docs make it obvious that there is a way to script everything and that it is there from the beginning.

So, usable and dare I say, promising.

Things to come

There’s very little I will be able to say about issue tracking, the default Agile/Scrum issue tracker with the standard boards more than covers whatever requirements I have for maintaining a backlog. My job is to get automation up and running: builds, tests, packaging and deployment.

You will notice I avoid saying “DevOps” and CI. The first does not apply to me individually, but to my team, and the second is a byproduct of getting all the things right (i.e. if we get the automation right and we apply it to every change then we will have CI)

On the other hand, expect a lot on pipelines and how they get implemented in Azure Devops. Getting a single build for a single tech up and running is ridiculously easy - the system analyzes your code and pretty much serves you the build jobs on a platter.

But I never have a single build or a system that uses a single tech, do I?