Answers: <p>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).</p>
  
  <p>We use <a href="https://docs.docker.com/compose/" rel="nofollow noreferrer">Docker Compose</a> 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).</p>
  
  <p>The production compose file contains the production specific settings and tells each service to use a specific tag:</p>
  
  <pre><code>service1:
      image: examples/service1:1.5.4     
      ports: 
          - "8000:8000"
      volumes: 
          - "/data" 
  service2:
      image: examples/service2:3.5.2
  </code></pre>
  
  <p>The staging compose file tells each service to use the image of the master branch:</p>
  
  <pre><code>service1:
      image: examples/service1/master:latest          
  service2:
      image: examples/service2/master:latest
  </code></pre>
  
  <p>Then the compose file for a specific branch of service 1 just looks like that:</p>
  
  <pre><code>service1:
      image: examples/service1/some-branch-name:latest
  </code></pre>
  
  <p>When you deploy a review environment for the specific branch with all three compose files at once you'll get something like the following:</p>
  
  <pre><code>service1:
      image: examples/service1/some-branch-name:latest
      ports: 
          - "8000:8000"
      volumes: 
          - "/data" 
  service2:
      image: examples/service2/master:latest
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2019-10-20T16:01:22.340Z
Answers: 2019-10-21T07:43:04.850Z
Answers: 2019-10-21T07:43:04.850Z
Answers: lukket
Body: <p>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 <a href="https://docs.gitlab.com/ee/workflow/gitlab_flow.html" rel="nofollow noreferrer">GitLab flow</a>. 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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>How am I supposed to handle the above use case properly for microservices? Are there branching models / git workflows which work better for microservices?</p>
  
Tags: <git><gitlab><project-management>
Title: How to implement GitLab Flow branching model for microservices?
UserDisplayName: Claudio
ThreadText: # How to implement GitLab Flow branching model for microservices?
  
  (Asked by: username_0 on 2018-11-01)
  
  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](https://docs.gitlab.com/ee/workflow/gitlab_flow.html). 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?
  
  **Tags:** git, gitlab, project-management
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-10-20. Score: 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](https://docs.docker.com/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
  
  ```
  
  
  ---
  
  