My road to an open source project: Azure Traffic Manager extension for Azure DevOps

As I mentioned in my last few posts, I have been working in my spare time to convert the existing scripts I had for Azure Traffic Manager into an Azure DevOps extension.

I finally managed a critical point to publish the code on GitHub! I am not a massive code person, it might feel like a drop in the ocean but it is something really big for me :-) It was also a great exercise on the actual end to end process of creating a working extension, which I found extremely interesting and valuable.

The extension does four things at the moment: enable and disable an Endpoint, promote and demote a priority-based Endpoint. It is fairly simple, but again this code stems from demos, labs and community efforts I did over the last 12 months so it is not something that was used by a company in production.

It is available in Public Preview here, and I am still ironing out a few issues both on the pipeline side and the code. Still, given the lack of an official Azure Traffic Manager extension I feel it can be a decent stopgap - at least with these basic features. I will try to make it even more complete over time so it can be even better!

The dev.azure.com URL - can I move away from the old visualstudio.com URL?

Plenty of reasons behind this, but you might want to move away from your <organisation>.visualstudio.com URL and onto the new dev.azure.com/<organisation> URL as a matter of standards.

It is fairly easy to do - straight from the Overview Settings page of the organisation:

If you configured your Build Agents on-premise with a PAT and the old URL you are covered, the configuration will still work, plan for this in advance anyway and make sure you are prepared 👀

The importance of the .gitignore file

A few days ago I spent a some time reviewing some old repositories of mine (mostly demos) and I realised how cluttered they were.

You know why? Because they were created years ago, went unmaintained for ages and they were lacking a .gitignore file.

Early in the days of learning Git, one of the things I left behind was - guess what - a proper usage of .gitignore files. Moving on I realised how important they are: they prevent your repository from becoming filled with temporary files you don't really need. If you go back to old repos you created when you were not as proficient as you are today, you are guaranteed to stumble into that like I did.

For example: if you create an empty MVP Application using ASP.NET Core and you run a git add --all you will surely add files like sqlite's db.lock file, which is utterly useless in a Version Control System.

Or the whole .vs folder, .suo files, the obj folders and so on...you don't need this stuff in a Git repository!

At the end of the day a .gitignore file is literally a list of files to ignore in order to maintain your repository lean and nimble. Spend five minutes (tops!) on it, and you will get the rewards way down the line.

If you are *that* lazy and you think you can't spend five minutes on it, there is a nice service (what isn't commoditised today?!) called gitignore.io that will create a default one for you based off your favourite IDE or environment.

Really, do it! 😁