The document discusses CICD pipelines using GitOps architecture. It describes how GitOps allows for automated deployment to all environments from a single codebase, enhanced auditing of deployments by tracking changes in Git, and improved observability through monitoring for divergences between desired and actual infrastructure states. The architecture uses Git as the single source of truth for infrastructure configuration and deployment. Continuous integration pipelines build and push container images, while continuous delivery pipelines deploy configuration changes to Kubernetes clusters using a GitOps operator.

1. CICD Pipelines
with GitOps Arch.
Bao Huynh
Site Reliability Engineer

2. ● Automated deployment: one source code for all deployment
& all ENV
● Enhanced audit: keep track of system deployment (who,
when, which version,...) by GIT
● Observability: Ability to detect divergence between “desired
state” and “actual state” by using diff tools → alerting for non-
authorized deployment
1. GitOps - What & Why

3. 2. GitOps - Architecture (1/5)
Consider:
- Replace branch “release/1.3.0” by
permanent “release”
- When merge branch dev->uat, new
changes will be updated to “release”.
Benefits:
- Remove duplicated “create/delete” branch
“release/x.y.z”
- Provide the ability to persists .gitlab-ci.yaml
for branch “release*”

4. 2. GitOps - Architecture (1/5)
Deploy to corresponding K8S:
- For tags (uat-1.2.0 / 1.2.0)
- For branches
(uat/master)

5. cluster-test
cluster-live
2. GitOps - Architecture (2/5)

6. ●Source code
flappy-shopee-fe (Django)
checkdup (Go)
●Gitops-helm
app-game/flappy-shopee-fe.yaml
app-auction/checkdup.yaml
2. GitOps - Architecture (5/5)

7. Continuous Integration (CI) Part:
INPUT
● service_name: parsing
● tag: parsing from git
● env: get branch name
● Commit-id: parsing
● Credentials GCR: get from gitlab-env
OUTPUT
● Docker image push to GCR with proper tag
git.com/<svc_name>:<env>-<tag>-<commit-id>
● Commit to “gitops-helm” repo via “helm-
operator” API:commit
2. GitOps - Architecture (3/5)

8. cluster-test
cluster-live
Continuous Delivery (CD) Part:
INPUT
● service_name: parsing from
<svc_name>.yaml
● image_version: ……….
● namespace: .………
● SHA_COMMIT: parsing from git
→ to download latest code
● Chart_name: common helm chart
OUTPUT
● Deploy to GKE via “helm-operator”
API:deploy
2. GitOps - Architecture (4/5)

9. Payload send to “helm-operator” (CD Service)
API: v1/commit
{
"docker-tag": “$DOCKER_TAG",
"branch": “$CI_BUILD_REF_NAME",
}
3. GitOps - Internal Tools API (1/2)
UPDATE ImageVersion

10. Payload send to helm-operator (CD Service)
API: v1/deploy
{
"sha1": “$CI_COMMIT_SHA",
"branch": “$CI_BUILD_REF_NAME",
“namespace”: “$NAME_SPACE”,
“charts-name”: “$CHART_NAME”
"charts-version": “$CHART_VERSION"
}
3. GitOps - Internal Tools API (1/2)
Parsing Command Deploy to K8S
GKE
Test/Live
Helm install <svc>