swan
swan

Reputation: 29

Best Practices for Azure DevOps - Managing Repo(s) for Related Initiatives

I am starting up a development team within my organization and we are managing all of our initiatives under a single Azure DevOps Project. To be clear I am trying to avoid using the word "projects" here to prevent confusion with the ADO Project terminology, so I am using "initiatives" in this post...

Over time we expect to maintain a large quantity of initiatives (likely hundreds over time) as we cater to many groups across our company. Some of our initiatives will be highly related to each other but should be managed independently for commit histories. For related initiatives we would prefer to manage them under a single Repo but separated into different folders. For example, we may have a dll that will be heavily utilized by many related plug-in like applications. The dll and plug-in applications would preferably be maintained within the same Repo as sub-repos if possible. Additionally, there will be many categories of related initiatives which would be hosted in other Repo(s).

My question is what is considered best practice to maintain a large number of initiatives, some related and some unrelated, in Azure Repos? I read some things about Git Submodules but am struggling to figure out how to make/manage distinguished submodules in Azure Repos. Is this the best approach, or is it even possible in ADO? Alternatively is it better practice to utilize independent repos for each initiative, and try to group them via a predetermined naming convention and just call upon multiple repositories in the Pipeline?

Thanks in advance! I am relatively new to ADO.

Upvotes: 2

Views: 2233

Answers (1)

ComputerKarate
ComputerKarate

Reputation: 21

I agree with mason that submodules can be complicated, it is worth effort

Let us say you are developing web app
You have repository "AwesomeApp" that houses code that needs to compile into production code

You could create repo of utilities "UtilitiesRepo"
This repo will never be public and exist just for your convenience

Under the "UtilitiesRepo", you will have some structure similar to following:

scripts/
development_build/AwesomeApp/
.gitmodules
azure_pipelines.yml

Directory "development_build" will become top level copy of "AwesomeApp" using submodules

At top level of "UtilitiesRepo", .gitmodules will have all information to pull down copy of "AwesomeApp" for build/test purposes

[submodule "AwesomeApp"]
    path = "development_build/AwesomeApp"
    url = https://dev.azure.com/AwesomeApp
    branch = CurrentDevBranch

Populate development_build/AwesomeApp with command:

git submodule update --init
Submodule path 'development_build/AwesomeApp': checked out 'CurrentDevBranch'

Now copy of all files will be in development_build/AwesomeApp/
If "AwesomeApp" needs library, you can add that as submodule since directory development_build is just placeholder for copies of other repos

Just add it as submodule and your "scripts" can access and build/test both:

development_build/AppLibrary/
development_build/AwesomeApp/

Upvotes: 1

Related Questions