This is a continuation of Monorepo versus Polyrepo.
This is a story about a project I worked on. We had some pain points related to many different source repositories.
At first, we thought that the shared code would stabilize. This did not happen. This meant a large number of pull requests with only package version changes.
We wanted to change code in the shared libraries along new core requirements. We had confusion around package versions due to the sheer amount of package changes. During retrospectives the team expressed frustration with the amount of unnecessary work.
We decided to merge the repositories into a shared repository for the .net code. This meant that we changed the NuGet packages to project references.
We also needed to support work on two major branches. For this particular business, there is a need to get legal to sign off on any major release. When we develop a major version we also bugfix the previous major version.
We looked into using git submodule. We decided that it was not the right choice for the team: everyone would need to learn how to use it. Git submodule requires the team to learn additional commands to do pull and checkout in the main repository. We noticed was that you can use git subtree in similar way as git submodule. Difference is that only a few persons need to learn the extra commands.
You can fetch changes from different repositories into a merged repository.
Our CI triggered a build for every new branch for every service.
Making changes to shared libraries become easier. We could use existing tools to make the transition (git subtree).
Do you want to send a comment or give me a hint about any issues with a blog post: Open up an issue on GitHub.
Do you want to fix an error or add a comment published on the blog? You can do a fork of this post and do a pull request on github.
Comments