Make your Dev, Ops, and QA life great again with a mono repository

Markus Hanslik
May 23, 2019 · 4 min read
Image for post
Image for post
Photo by Yung Chang on Unsplash

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.

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?

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.

The Startup

Medium's largest active publication, followed by +771K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store