A naming convention to bring order to variable groups
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 .
The naming convention
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.
The solution to this challenge is to define a rationale from which the naming convention is derived. The rationale I use is described is as follows.
Rationale
-
The name of a variable group is scoped to an individual Azure DevOps project. This keeps the naming convention simple as a major part is already handled by the project name and it’s description.
-
The reason for starting with the product / team affix is to group the variable group’s by their concerning products and/or teams. Because some projects are used for hosting multiple products and are used by multiple teams it is important to be able to see at glance which variable groups are part of which products. So starting the name with the product / team affix references the product or team in question but also groups all variable groups.
-
The second segment can either reference the pipeline name if the variable group in question is only and only used by the single pipeline in question. Otherwise the segment should contain the purpose of the variable group. To allow for meaningful naming the purpose can be widely interpreted. For example; a variable group which contains
-ado-is purposed to host Azure DevOps variables. -
The final segment should contain the environment applicable to the variable group in question. The assumption here is that the variable groups are set-up to be environment specific.
Combined the rationale comes together into the following naming convention:
<product-affix|team-affix>-<[product|purpose]>-<environment [exp|dev|qa|uat|prd]>
Naming convention in practice
Lets use the naming convention on the following use case and derive a couple of examples from it: Digital Solutions workload contains a Payment Processing Application as one of the products. This feature is developed by the DevOps team. In an Azure DevOps project named like the workload, Digital Solutions.
Example 1: Product centric organized variable group naming
<product>-<purpose>-<env>
Example 2: Team organized variable group naming
<team>-<purpose>-<env>
Wrapping up
And that is all there is to tell about my approach to organizing variable groups trough a naming convention. Thanks for reading this post and if you haven’t please check out my previous post on this subject. I cant wait to share my next and final post in this series series.