Welcome to DevJev.nl: Your Guide to Azure, Cloud Security, and DevOps Mastery

This is the 2nd post in the category Azure DevOps Fundamentals of the blog post series on working with Azure DevOps In this post the I will show how to create a new Project in Azure DevOps.

Since it much more fun to do research and play with technology in collaboration with others, Wesley Camargo will be covering some of the topics on he’s blog , while other topics are covered by my here. Naturally the all related posts will be referenced between the two blogs.

With this post am kicking off a blog post series on working with Azure DevOps . The subjects covered by this series are organized into three categories:

• Azure DevOps Fundamentals
• Azure DevOps Advanced
• Azure DevOps Expert

Starting with the basic of basics of Azure DevOps Fundamentals :

How to create an Organization in Azure DevOps?

Since it much more fun to do research and play with technology in collaboration with others, Wesley Camargo will be covering some of the topics on he’s blog , while other topics are covered by my here. Naturally the all related posts will be referenced between the two blogs.

A new post and a new addition to the naming convention series . With this post I want to share my approach to naming Azure Management groups .

What are Management groups and theirs limits

If you are wondering about reasons for this approach to naming please have a look at the Naming convention background chapter of the The perfect azure naming convention . With that out of the way lets dig in.

In my previous post I went trough my experiences with using the basic Winget commands. And mentioned that anyone who needs more control over the installation options will quickly note that when Winget uses the default installation options when installing packages. In this post I would like to share with you how I managed to solve this and get the control I need during the installation process.

Winget Advanced installation, the override command

The winget install documentation shows that an --override option is available, with an input “A string that will be passed directly to the installer”. Simply said it should allow to override the default installation options with custom ones, similar to the way a regular installer GUI allows to the user to change settings during the installation process. A.k.a. a custom installation and exactly what I need!

During my summer holiday I had a one day break from sunny weather so I decided to use the family tablet to fiddle with some PowerShell. As expected only the standard software was installed on the tablet. I could either start installing everything I need manually or use this opportunity dig a bit into winget . I hope you will enjoy both the basics and the advanced configuration experience shared via this post.

With this post I want to share my approach to Git branch naming. This is the 4th and final post in the naming convention series .

When working in large teams, managing branches can quickly become a hassle. Comparing branches to figure out their feature set, is a time consuming and error prone activity. This should be avoided as it significantly increases the chance of releasing wrong or even broken functionality.
The most ideal solution here would be to use a backlog tool (for example Azure Boards with Azure Repos or with Github) where the branches can be directly linked to backlog items and visa versa. And dotting it i’s by implementing a proper branch naming convention.
However teams that do not have these tools available to them would need to rely on just the naming convention to help organizing and ordering branches.