A monorepo keeps multiple projects in one code repository. For a small microservices application, give each service its own subdirectory. This avoids setting up and managing a separate repository for every service while the application is still taking shape. section 10.4.3
One repository does not require one deployment schedule. Give each microservice its own continuous deployment (CD) workflow, scoped to changes in that service’s directory. Then a change to one service can rebuild and redeploy that service without redeploying the rest. section 12.2.2 section 10.10.4
Listing 10.16 Enabling a separate CD pipeline for the gateway
name: Deploy gateway #1
on:
push:
branches:
- main #2
paths:
- gateway/** #3
workflow_dispatch: #4
jobs:
deploy:
runs-on: ubuntu-latest
env:
VERSION: ${{ github.sha }} #5
CONTAINER_REGISTRY: ${{ secrets.CONTAINER_REGISTRY }}
REGISTRY_UN: ${{ secrets.REGISTRY_UN }}
REGISTRY_PW: ${{ secrets.REGISTRY_PW }}
NAME: gateway
DIRECTORY: gateway #5
steps:
- uses: actions/checkout@v3
- name: Build
run: ./scripts/cd/build-image.sh #6
- name: Publish
run: ./scripts/cd/push-image.sh #7
- uses: tale/kubectl-action@v1 #8
with:
base64-kube-config: ${{ secrets.KUBE_CONFIG }}
kubectl-version: v1.24.2
- name: Deploy
run: ./scripts/cd/deploy.sh #9
The gateway workflow uses the path filter `gateway/**` to run on pushes to `main` that change the gateway directory. Its `workflow_dispatch` entry also permits manual runs. section 10.10.4
Keep the monorepo while its simplicity helps. As the application and team grow, developers may encounter more merge conflicts, broken builds, or a repository that is hard to manage. Split it when those costs begin to restrict the team—not merely because the application uses microservices. section 12.2 section 12.2.2
When a split is needed:
- Create a repository for each microservice, including its deployment code. Create another for shared infrastructure code, such as Terraform configuration for the container registry and Kubernetes cluster. section 12.2.3
- For a straightforward move, run `git init` for each new repository, copy in its code, and commit it. Preserving existing history requires extra work; `git filter-branch --subdirectory-filter` is identified as one option. section 12.2.3
