The implication in the name Monorepo Is that only one – everything is included. But in Get rid of old codeI mentioned that 45 repositories would make it into the Monorepo. This means that 15 repositorys did not make the cut. When we strive for a monorepo, why were these repository excluded?
Our main goal is to collect the entire code, the infrastructure and the documentation in relation to our own development efforts in a single place. This is shown by the 45 repositorys, which were merged into a single repo.
A category that was excluded by the Monorepo was Forks for dependencies. We have some of the external dependencies that we rely on, such as eyalroz/printf And JuliaMath/openlibm. This could are merged into the Monorepo, but managing these projects outside the Monorepo makes it easier for us to remain synchronous with changes in the original repository. In addition, these projects will continue to be available in Monorepo via Meson’s subproject system.
- During the initial building step
subprojects/Folder. - We can commit and urge these projects without leaving the Monorepo.
- By including these projects via the dependency system, we can return to the original dependency repository if necessary.
We also have some repository that represent Forks of applicationsas the git And git-filter-repo Forks that we have created for support Maintaining and restoring signatures. We do not want to pollute our own project history with the commits from these projects – especially large ones like git. We also hope that we can fuse our changes upstream so that we can finally extinguish the forks and return to an official publication.
The remaining repository are independent efforts that do not fall into the area of our regular development work.
- We have a repository that stores the source code for our courses.
- This can be viewed as a separate monorepo, as we keep all exercises and solutions for each course in a repository.
- The Medtronic-PB560 Repository is used for analysisnot development (our analysis can be found in the Evaluation of the open ventilation design Course). We don’t have to pollute the Monorepo with code that we will never really use.
- Our websites (https://embeddedartistry.com/ And https://embeddedartatryconsulting.com/) Everyone has a repository that contains all published content.
- We never interact directly with these repositors.
- Instead, we have added a “Publication” command to our writer, with which content updates with these repositories are transferred to the website.
We will also exclude customer projects from the Monorepo. This is not our code, and these repositories are usually deleted from our organization after completing the project.
Although we still have several repository, we can only reduce our focus on a handful of repositors:
- All of our own development work takes place in the Monorepo – including working on forks external dependencies.
- Changes to the course-related source code are in the course code repository.
- Repositories for customer work, forked applications and forked dependencies will come and go as needed.
References
- Get rid of old code – a very recommended step, regardless of whether you want to switch to a Monorepo strategy or not