Make your Dev, Ops, and QA life great again with a mono repository
There’s a very simple trick applicable to most companies with IT development that helps making the development process much easier and more transparent, whilst enabling everyone in it to become more agile.
What is the trick, you ask? Stop developing in separate repositories and follow a mono-repository approach.
Or, let me rephrase: Whatever your company builds and needs to continuously integrate with each other has to be in the same repository. If your company develops a suite of different tools, not related whatsoever, then off you go, continue using separate repositories for that.
However, if your company develops anything else, such as a React web frontend with a Go backend in AWS and a legacy PHP backend plus a component library, try to put as much into the same repository as possible.
Don’t Over-Engineer It
Even the actual structure of the mono-repository doesn’t matter too much, as long as the apps/services (whatever you call them) in there are somehow separated (all different folders, or organized by business division, or … depending on your architecture’s maturity).
I’d even argue — you could just go to the folder on your computer where you have currently checked out all of your company’s repositories and check this folder in as one mono-repository, and you will already start making a big step towards becoming truly agile, having a DevOps culture, easier QA processes, and more.
The goal is not to have a big ball of mud. We don’t want to have a single huge application; we just want to have a single source of truth describing the product(s) your company sells, in where we can develop small, independent services but still easily can integrate them with the rest.
The idea is that once everything is in one place, you can make PRs across multiple services and also run your CI across multiple services (without workarounds to tell the CI which repos to deploy for your change), which greatly lowers the barrier to start moving things around, work full-stack, and think in terms of features instead of technical layers.
Just think back to when you and your team last implemented a feature. Did you have to make changes in several repositories; frontend, backend and maybe even an infrastructure repository with Ansible or Terraform files? With three separate Pull Requests, nobody being responsible for putting it all together, and nobody making sure that everything is merged before the next release?
Or, before you merged, did you run your CI across your platform and really continuously check the integration? Or did the CI just ended up run some unit tests, and the actual integration tests happened once everything was merged?
The Benefits of a Mono-Repository
Now, imagine a world where everything is in the same repository. The README.md in the root of the repository could greet new engineers with a short intro on how to get the code up and running, along with guiding principles applicable to everything, as well as e.g. a docker-compose file for local development.
There could be a central CI pipeline that kicks off tests on all changed services (depending on code changes per folder), plus integration tests; so no matter whether you make changes on one service or many, the CI always orchestrates the correct state and versions of your services, even if you need to make lots of changes in different parts entirely.
Additionally, merge requests can then show you the changes required for a feature across frontend/backend/infrastructure, which is helpful even for part-stack-developers as it’s much easier to see issues, or revert mistakes with the full picture view. Of course, developers can still work in their own branches, separated by layer if they want; the release branch or merge commit would still make it much easier to revert or keep track of changes.
All of this would also then be great for finally making the switch to service-centric terraform files, splitting code out from a too big service, or changing an internal API in frontend and backend, as finally moving stuff around in your platform is all versioned and can easily be reviewed and rolled back, and much more.
Regardless of how committed you are to having a central place for your code or whether you are interested in full-stack development, mono-repositories make life much easier without any drawbacks for most, as Git handles big numbers of files easily and most CI services cache git repositories anyhow.
