Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

global variables naming convention

jagercode August 23, 2024

Hi all,

We specify in each plan and repository full paths to external stuff like svn repos, test files or test file repos, etc. 

If we change the location of one of those things the result is a lot of work to update paths per plan/repo.

So my plan is to use global variables for the things in our software development ecosystem. We have never done this before, so we do not yet have discovered our best practices.

I've started out with "subversionBaseUrl", accessed via ${bamboo.subversonBaseUrl} which works fine in the current situation. 

Now I do have some questions regarding best practices to future proof this approach before I scale things up.

A) Would it be convenient to distinguish variables that point to elements in our ecosystem by a prefix or something? Like, bamboo.devtools.subversionInternalReposUrl?

B) If we are migrating repos from one server to another in small batches of 10 at a time and we want the plans to continue to work, what would be the best practice for naming the global variables?
I've come up with changing the value of bamboo.subversionBaseUrl to the new location and add bamboo.subversionBaseUrl.old for as long as the old path exists. Remove it when the path no longer exists. What do you think?

I consider also a slightly different approach I learned from the school of Systems Engineering, which is to add a (revision) number to each variable. If you use the variable without number you always get the latest version. (I've tested if you can use the value of another variable and this works). So, when subversionBaseUrl.2 cannot be found anymore, a repo or project maintainer simply increments to subversionBaseUrl.3 and everything is back to normal. But maybe this is over-engineering the configuration? 

0 answers

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events