GitOps & the deployment branching models DevOps D-day Marseille 2021: GitOps is starting to be a well-known approach to delivering your software, but it does not provide a framework for representing different target environments or a solution for propagating changes from stage to stage. So what are the solutions to describe the Dev, QA or Production environment and especially how to propagate changes from one environment to another in an efficient, automated and secure way in a GitOps framework?

1. GitOps
& the deployment
Branching Models
© SOKUBE 2021
Yann Albou #CTO
https://www.linkedin.com/in/yann-albou/
@YannAlbou

2. 19
Company started in
July
2019
SoKube is a consulting company 100% dedicated
to the container & Kubernetes orchestration
ecosystem and the entire SDLC, including a
comprehensive approach with Agile, CI-CD,
DevOps / DevSecOps, SRE, GitOps practices.
Kubernetes and DevOps have reached a level of maturity that
any company can leverage as their next enterprise platform.
In the 2020s, Kubernetes will become the common ground
for multi-cloud strategies, alongside with PaaS services, just
as Virtualization took over Physical machines back in 2000s.
Top-Management adoption, Cultural Shift and Training
will be key catalysts in the evolution of companies
that were born before the Cloud-Native era.
Agile Expertise

3. © SOKUBE 2020
GitOps

4. #1. Declarative
The entire system is described declaratively
#3. Kubernetes Operator
Approved changes to the desired state are
automatically applied to the system
#4. Continuous Observability
Software agents ensure correctness and alert on
divergence
Sync & Alert
#2. Git as Single Source of Truth
Declarative changes let you think of changes as
transactions
GitOps ?

5. Continuous Delivery pipeline
Continuous Integration pipeline
Source: https://www.gitops.tech
Pull-based deployments

6. GitOps Downsides
• Not a one-size-fits-all solution
• Splitting CI and CD is more complicated
• Edge case with Dynamic Resources
• Rollback practices need to be defined
• Non technical Observability & auditing
• Continuous Deployment not natural
• Secret Management is your problem
GitOps doesn’t provide neither a frame to represent the different environments
nor a solution to propagate changes from one stage to the next one.

7. © SOKUBE 2021
Git Repo

8. Development side
Source code
DockerFile
Config files for local dev
Development
Docker image

9. Separation git repo: Applications / Deployment
• 2 different lifecycles
• Security aspects
• Pipelines are different
• Branching git models are different
• Multiple applications
• Mixing Git logs

10. Values.yaml
backend:
container:
registry: my-dev-registry
image: my-back-app
tag: latest
replicas: 1
resources:
requests:
cpu: 1500m
memory: 256Mi
limits:
cpu: 2000m
memory: 512Mi
probes: …
netpol: …
config:
db:
type: in-memory
username: admin
password: pwd
business:
myapp: val1
chart.yaml
name: my-app
...
dependencies:
- name: springboot
alias: backend
version: 2.0.0
repository: ...
...
The “Mille-feuille” Configuration
Infrastructure
Monitoring
Database
…
Security
Dev
Deployment Repo

11. Target env
Target environment on which you want to deploy your applications
Int Test QA UAT Pre-Prod Prod

12. © SOKUBE 2021
Branching Models

13. 1 env per Git Repo

14. 1 env per Git Repository
Dev / Sec / Ops
INT QA PROD
CD
YAML
Helm
Kustomize
PR / Patch
PR / Patch

15. 1 env per branch

16. Dev / Sec / Ops
INT QA PROD
CD
Pull
Request
Pull
Request
YAML
Helm
Kustomize
1 env per branch

17. 1 env per branch
• “Common” approach
• Simple filesystem / single set of resources
• RBAC per branch
• Pull Request process more complicated
• Flow of propagation must be respect (possible ?)
• Hot-fix ? → Merge hell
• Promotion of structural new element is harder: keys consistency

18. Values.yaml
backend:
container:
registry: my-dev-registry
image: my-back-app
tag: latest
replicas: 1
resources:
requests:
cpu: 1500m
memory: 256Mi
limits:
cpu: 2000m
memory: 512Mi
probes: …
netpol: …
config:
db:
type: in-memory
username: admin
password: pwd
business:
myapp: val1
mynewkey: newVal
chart.yaml
name: my-app
...
dependencies:
- name: springboot
alias: backend
version: 2.0.0
repository: ...
...
Values.yaml
backend:
container:
registry: my-qa-registry
image: my-back-app
tag: 1.2.1-9eabf5b
replicas: 3
resources:
requests:
cpu: 1000m
memory: 256Mi
limits:
cpu: 1000m
memory: 256Mi
probes: …
netpol: …
config:
db:
type: postgresql
username: user123
password: pwd123
business:
myapp: val2
chart.yaml
name: my-app
...
dependencies:
- name: springboot
alias: backend
version: 1.5.3
repository: ...
...
Values.yaml
backend:
container:
registry: my-prod-registry
image: my-back-app
tag: 1.1.12-5acdb2f
replicas: 6
resources:
requests:
cpu: 1500m
memory: 512Mi
limits:
cpu: 1500m
memory: 512Mi
probes: …
netpol: …
config:
db:
type: postgresql
username: user456
password: pwd456
business:
myapp: val3
chart.yaml
name: my-app
...
dependencies:
- name: springboot
alias: backend
version: 1.5.2
repository: ...
...
Env Configuration

19. Values.yaml
backend:
container:
registry: my-dev-registry
image: my-back-app
tag: latest
replicas: 1
resources:
requests:
cpu: 1500m
memory: 256Mi
limits:
cpu: 2000m
memory: 512Mi
probes: …
netpol: …
config:
db:
type: in-memory
username: admin
password: pwd
business:
myapp: val1
mynewkey: newVal
chart.yaml
name: my-app
...
dependencies:
- name: springboot
alias: backend
version: 2.0.0
repository: ...
...
Values.yaml
backend:
container:
registry: my-qa-registry
image: my-back-app
tag: 1.2.1-9eabf5b
replicas: 3
resources:
requests:
cpu: 1000m
memory: 256Mi
limits:
cpu: 1000m
memory: 256Mi
probes: …
netpol: …
config:
db:
type: postgresql
username: user123
password: pwd123
business:
myapp: val2
chart.yaml
name: my-app
...
dependencies:
- name: springboot
alias: backend
version: 1.5.3
repository: ...
...
Values.yaml
backend:
container:
registry: my-prod-registry
image: my-back-app
tag: 1.1.12-5acdb2f
replicas: 6
resources:
requests:
cpu: 1500m
memory: 512Mi
limits:
cpu: 1500m
memory: 512Mi
probes: …
netpol: …
config:
db:
type: postgresql
username: user456
password: pwd456
business:
myapp: val3
chart.yaml
name: my-app
...
dependencies:
- name: springboot
alias: backend
version: 1.5.2
repository: ...
...
Env Configuration

20. 1 env per dir / file

21. 1 env per directory / file
Dev / Sec / Ops
INT QA PROD
CD
YAML
Helm
Kustomize

22. 1 env per directory / file
• Env update/add/remove
• Pull Request process is simple
• Ability to factorize between environment
• Consistency of key values is a huge advantage
• Ability to switch from one env to another
• No adhesion to an env
• RBAC is not OOTB → CodeOwner
• Warning on common parameters

23. Git Flows
GitFlow GitHub Flow GitLab Flow

24. © SOKUBE 2021
Enterprise GitOps

25. Tools
KAM
Redhat

26. Enterprise GitOps
• Added value and benefits are important
• Need to be aware of current limitations or bad practices
• Solutions are more and more mature
• Must be adapted to your process without twisting the model
• Give you the opportunity to improve your process
• 1 env per directory/file with gitflow simplifies while allowing to manage
complex scenarios

27. Thanks to the SoKube Team
© SOKUBE 2021
Yann Albou #CTO
https://www.linkedin.com/in/yann-albou/
@YannAlbou
Sokube is hiring