How to implement GitLab Flow branching model for microservices?

Question

Recently I’ve been looking into alternatives to the git flow branching model and since I’m already using GitLab, I stumbled upon their own branching model called GitLab flow. I’m currently trying to get my head around how to implement this properly for microservices. We will assume, that I am deploying all services to the same kubernetes cluster, each deployment should reside in its own namespace.

If I understand this model correctly, one should continuously deploy the master branch to a staging environment and deploy tagged commits occasionally to the production environment. While this works properly if there are only two environments, I’d also like to make use of the dynamic environments available in GitLab, i.e. for each branch off of master, I want to be able to create a review deployment.

Now if I have e.g. multiple microservices which make up a single application, what’s the best way to deploy all microservices to a separate kubernetes namespace for each branch, when pushing the repository of a single microservice using GitLab CI. I can’t think of a clean solution as soon as there are dynamic environments involved.

How am I supposed to handle the above use case properly for microservices? Are there branching models / git workflows which work better for microservices?

Answer 1

We also switched from Git Flow to GitLab Flow several months ago and so far we're very happy with our decision. It works very well with GitLab, it's easy to understand and less error-prone and you don't need additional Git commands (which are quite slow on Windows).

We use Docker Compose to organize our microservices and have a separate project/repository just for the staging and production compose file(s) of our actual application. In the project and CI of each service you can then combine such compose files with a specific one that just tells Docker to use the specific branch of the specific service (and maybe other branch specific settings).

The production compose file contains the production specific settings and tells each service to use a specific tag:

service1:
    image: examples/service1:1.5.4     
    ports: 
        - "8000:8000"
    volumes: 
        - "/data" 
service2:
    image: examples/service2:3.5.2

The staging compose file tells each service to use the image of the master branch:

service1:
    image: examples/service1/master:latest          
service2:
    image: examples/service2/master:latest

Then the compose file for a specific branch of service 1 just looks like that:

service1:
    image: examples/service1/some-branch-name:latest

When you deploy a review environment for the specific branch with all three compose files at once you'll get something like the following:

service1:
    image: examples/service1/some-branch-name:latest
    ports: 
        - "8000:8000"
    volumes: 
        - "/data" 
service2:
    image: examples/service2/master:latest