Some teams of developer prefer to gather the source code of all the applications they are working on in a single repository instead of the traditional one repo per application. This code organization strategy is often called “mono repository” or “monorepo” in short. Deploying such applications requires some configuration. Follow our steps to deploy multiple applications from code hosted in a mono repository.
Why a monorepo?
Imagine your project follows the monorepo pattern and has the following code structure:
my-app ├── api ├── front ├── admin └── cockpit
It’s easy to imagine that these applications form a homogeneous whole with a standardized communication method (synchronous HTTP calls, message queuing, etc.) between them.
Monorepos have several advantages:
- Simplified organization
- Easy to coordinate changes across applications
- Simplified dependencies
- Single lint, build, test and release process
- Single place to report issues
- Tests across modules are run together → finds bugs that touch multiple modules easier
- Simplify large-scale code refactoring – Since developers have access to the entire project, refactors can ensure that every piece of the project continues to function after a refactor.
- Smooth collaboration across teams
- Code reuse
In our example, a release is the release of the whole set of api, front, admin and cockpit applications and by setting up a robust Continuous Integration pipeline you can ensure that the 4 applications will work correctly together.
And by the way, Google uses monorepo.
Deployments on Scalingo
With such a setup, you will need to create 4 applications on Scalingo: one for the API and 3 for the other applications. You can use the web dashboard or the CLI to do so.
Using the GitHub integration
In the “Code” section of each application on the web dashboard, enable the GitHub integration with your mono repository. You can activate the auto-deploy on one of the branch so that the application automatically get deployed when a commit is pushed on this branch. It’s better if you choose the same branch for the 4 applications.
With the code of each application being in a different subfolder, you must teach Scalingo where to find the source code by defining the
PROJECT_DIR environment variable of each application to match the corresponding folder. For
instance, the API application should have the following environment variable:
If you’ve set up the GitHub integration and activate the Auto Deploy feature, you can also activate Review Apps. Review Apps are applications built dynamically every time a Pull Request is open against the connected GitHub repo. Of course this feature will work as well in the case of a monorepo!
For example, if the PR #42 is opened against our example monorepo, Scalingo will automatically build and deploy 4 Scalingo applications named api-42, front-42, admin-42 and cockpit-42 available behind their own scalingo.io domains. And they will follow the standard Review Apps workflow: when the PR is closed these 4 temporary applications will be destroyed by Scalingo.
The Git Only Alternative
If your code is not hosted on GitHub, the workflow is a bit more manual. We will configure Git to
send the code to different
remote. After creating the 4 apps on Scalingo, go to the root directory
of your project and add the 4 remotes with:
git remote set-url scalingo --push --add email@example.com:api.git git remote set-url scalingo --push --add firstname.lastname@example.org:front.git git remote set-url scalingo --push --add email@example.com:admin.git git remote set-url scalingo --push --add firstname.lastname@example.org:cockpit.git
When you want to deploy a modification, just push to the
git push scalingo master
If you want to deploy a branch with a different name than master (e.g.
the previous commands with
With this setup, you are now ready to be super efficient in the deployment of your applications. Just add a custom domain name and keep coding!
If you want to dig deeper the subject of monorepo you can begin to read this super awesome list of tools and readings.