As code repositories have become more complex to reflect the nature of the intricate microservices architecture that they support — and teams have started using multiple repos to manage different projects — challenges have started to appear in their management.
For starters, it is not always possible to maintain coding best practices in code repos when multiple projects are structured differently. There are also bottlenecks in packaging and deploying codes from multiple repositories.
Organizations are starting to transition from polyrepos to monorepos as a way to bring the complex structure back to a manageable level. Having multiple codebases for web and mobile applications alone can be quite complex. Is shifting from polyrepos to monorepos really the answer? How can such transition be done smoothly?
The Logic Behind Polyrepos
The simple reason behind keeping services, modules, and libraries in separate repositories is actually very easy to understand. You are dealing with different components, and many of them – while maybe interchangeable or used by multiple frontend components – are developed by different teams. Keeping them in separate repositories keeps things tidy.
However, problems start to occur when you try to integrate components from multiple repositories as the development cycle comes to its conclusion. A change in UI element, for example, can have a significant effect on how the entire app functions, and keeping track of that specific change is not easy when there are multiple codebases to track.
Other issues are starting to become more common too. The overhead needed to maintain multiple repositories can be huge when the project is not managed for efficiency. A set of services may require the same modules and dependencies, and each repo needs to configure those dependencies separately for the development to work.
Slowdowns become quite common. Simple tasks such as fixing bugs require thorough assessment, and the process itself becomes incredibly slow at times. Even with microservices in multiple repos linked correctly, it is still not always possible to assess the effects of a major change to the rest of the app.
The biggest concern with polyrepos is the complexity involved in tracking revisions and package updates. You cannot pinpoint which particular revision solves a specific bug, which means rollbacks and annotations are unnecessary complexes too. These small difficulties add up, and they result in polyrepos becoming unsuitable for some organizations.
To make matters worse, teams with their own repositories don’t always use standardized tools and frameworks. Each team could have their own preferred tools, and they often introduce unnecessary differences in configurations; when I say differences, I mean variations that still require adjustments by the time you have to integrate microservices and push updates.
#microservices #code #repository management #repositories #monorepos #polyrepos
