ESI: An Intro to Azure DevOps

ESI: An Intro to Azure DevOps
Photo by UX Indonesia / Unsplash

For the next few weeks, I'd like to write a few blog posts as I go through the Enterprise Skills Initiative, a Microsoft website that seems to consist mostly of courses on learning Azure, with a little bit of GitHub and VSCode thrown in too. I got an email from my workplace about it, but I haven't heard of it before.

Over the last few years, I've really seen the value of "automating all the things", and it's the main reason I want to learn more about Azure DevOps (and similar tools). Not so I can spend days automating a 5 minute task that runs a few times, but so that I can know with confidence that the same task is running the same way every single time, all the more when it'll have to run hundreds or thousands of times over the course of years. They can be any kind of tasks - running a test suite, deploying code to a server farm, or creating PRs against our team branch whenever there's a commit to master. There's no reason to do any of those things manually.

Today, I'm starting with their "get started" learning path. We already use Azure DevOps at work and I have quite a bit of familiarity with using it, but that doesn't mean I won't learn something new - even from an intro.

Get started with Azure DevOps learning path - Learn
In this learning path, find out how Azure DevOps enables transparency and cooperation with continuous delivery and deployment for your development lifecycle.

I've heard a lot about DevOps in general (apart from any tool suite) - what it is, what it promises. Some people seem to set it up as the immediate elixir to every ailment a team could possibly have, which isn't accurate, nor is it useful when you're talking about a particular tool.

But then, there's DevOps tool suites like the one from Microsoft, and there's the DevOps principle. Like the "scientific method" is a guide for observing the world around us, DevOps is a general set of rules for observing the programming world, measuring it and understanding it better in order to improve it incrementally. To their credit, they do make it clear that no tool suite is a one-size-fits-all solution, stating that DevOps is not a methodology, specific piece of software, a quick fix, or a job title.

If you're new to Azure DevOps, I'd recommend checking this intro out, assuming you're here because you got access and wondered what it was. They do a nice job of helping you setup an account, create a board and a few tasks, and organize some sprints. Nothing too fancy, and all stuff I've seen before. There's lots of links to other learning material too, which I actually find overwhelming since then I feel compelled to bookmark them all for later. This one looks good though:

Azure DevOps Hands-On Labs
Learn how you can implement modern DevOps practices with Azure, Azure DevOps Services and Team Foundation Server

One of the things I'm left wondering about is how to increase the deployment frequency of a legacy, monolithic WinForms app, which a lot of us find ourselves working in. We do a decent job of automating the whole process at my current workplace, but there's always pieces that require manual intervention and extra TLC to get just right.

Another thing I'm wondering about is this sketch, which they use to illustrate the concept of value stream maps. They explain that the purpose is to "visually show where in the process a team creates value and where there's waste".

Source: Get started with Azure DevOps learning path | Microsoft

Only the "code" and "prod" steps are considered "value" steps, whereas everything else is something to be streamlined or cut entirely. The "Test" phase is considered a source of waste. I could actually get on board with that if we're talking about a single person manually running a test suite that a CI build could handle automatically, and maybe that's what they're referring to:

Amita manually tests the build. This process gets longer as the codebase grows. For now, let's say three days. She then emails Andy with bug reports. Testing doesn't add value, but it's necessary.

Testing most certainly adds value. And at some point, automated testing hits a wall and a real person should pound on the thing a bit just like the customer will. I'd hate to buy a car whose design hasn't been tested, or ride a rollercoaster that isn't regularly tested by a qualified engineer. Is that considered waste? Or just something to streamline as much as possible?