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.
With this post I want to share my approach to naming Azure DevOps variable groups. This post is the 3rd in the naming convention series .
In my experience there are a lot of different way’s Azure DevOps projects are organized. Also in contrary to the Azure resource naming variable groups are renamable and don’t possess an ability to hold additional metadata like tagging. This changes the approach to naming to focus much more on meaningful and descriptive naming within the context of the Azure DevOps project. Therefore a truly holistic naming of variable groups is challenging to achieve. But abiding the The 10 commandments for Azure naming conventions should still be feasible.
This post is the 2nd in the naming convention series . With this post I want to share my approach to naming Azure resources. Why a naming convention is important is already covered by my previous post . However I do believe that some background is required to understand this approach. So, lets dig in.
Check out the full naming convention series :
There are many Azure related naming conventions guides but this one is mine! For every 10 engineers and architects asked you will get 10 different replies on such a topic as naming conventions. With this blog post I would like to kick-off a small series of blog posts sharing my view points about Azure related naming conventions. In this post starting with why a proper naming convention is important and the 10 commandments I generally follow when working on a naming convention.
Back when all the Cloud and SaaS offerings where a brand new concept most IT administrators ended up choosing the domain name of a tenant. This choice would be then reflected in the SharePoint Online url and the only way to change it was to create brand new tenant. Either due to the somewhat poor choice from the IT administrators, due to mergers, rebranding or acquisitions some organization ended up with lets say less desirable domain name for their SharePoint URL.
Responding to clients with a “no it is not possible to change that” always bothered me back then. So when I learned that this option is now available (in preview) I immediately decided to try it. Via this post I want to share what I learned testing this option.