Travelio Tech Talks 2022 presentation The recommended workflow for implementing GitOps with Kubernetes manifests is known as trunk-based development. This method defines one branch as the "trunk" and carries out development on each environment in a different short-lived branch. When development is complete for that environment, the developer creates a pull request for the branch to the trunk. Developers can also create a fork to work on an environment, and then create a branch to merge the fork into the trunk. Once the proper approvals are done, the pull request (or the branch from the fork) gets merged into the trunk. The branch for that feature is deleted, keeping your branches to a minimum. Trunk-based development trades branches for directories. You can think of the trunk as a "main" or primary branch. production and prod are popular names for the trunk branch. Trunk-based development came about to enable continuous integration and continuous delivery by supplying a development model focused on the fast delivery of changes to applications. But this model also works for GitOps repositories because it keeps things simple and more in tune with how Kustomize and Helm work. When you record deltas between environments, you can clearly see what changes will be merged into the trunk. You won’t have to cherry-pick nearly as often, and you’ll have the confidence that what is in your Git repository is what is actually going into your environment. This is what you want in a GitOps workflow.

1. Understanding
the GitOps Workflow and CICD Pipeline
What It Is, Why It Matters?
Gibran Badrulzaman
DevOps Engineer at Travelio
#TravelioTechTalks | October, 26 2022

2. Gibran Badrulzaman
DevOps Engineer at Travelio
Who Am I ?

3. The Session
● Some basic concepts
● GitOps? What is it?
● The GitOps Operators
● The GitOps Pipeline
● Scenario
● Demo
● Questions and Discussions

4. Trunk Based Development (TBD) Model

5. Pros:
● Faster to iterate
● Small number of Branch to
maintain
Limitation:
● Higher technical difficulties for
releasing code to production
even use Continuous
Integration
Suggestion:
● Feature flags might be needed
Source: https://www.boldare.com/blog/what-is-trunk-based-development

6. The Basic Concepts of CICD

7. CI:
Continuous
Integration
● A software development practice where all developers merge
code changes in a central repository (Git).
● Each change in code (commit) triggers an automated build-and-
test stage for the given repo and provides feedback to the
developer(s) who made the changes.
● Automates the build and unit test process of the new code
changes.

8. CD:
Continuous
Delivery
A software engineering approach in which teams produce software in
short cycles, ensuring that the software can be reliably released at
any time and, when releasing the software, doing so manually.

9. CD:
Continuous
Deployments
A software engineering approach in which software functionalities are
delivered frequently through automated deployments.

10. CICD means…
Continuous Integration
+
Continuous Delivery / Deployments

12. Key Concepts
Continuous Delivery
In Continuous Delivery Pipelines, the main characteristic is that there is a human involved to
promote a new version to production.

13. Key Concepts
Continuous Deployments
On the other hand, in Continuous Deployment Pipelines, there is NO human involved. When
a developer commits to the main branch, all the changes are propagated through all
environments reaching the Production Environment.

14. What is GitOps?

15. “GitOps is a modern cloud native approach to centralizes
the development and operations process that leverages the
Git version control/source control system as a single source
of truth for all configuration, infrastructure, and operational
procedures“

16. Source: https://blogs.vmware.com/cloud/2021/02/24/gitops-cloud-operating-model

17. GitOps Operators

18. ● Spinnaker is an open-source, multi-cloud
continuous delivery platform for releasing
software changes with high velocity and
confidence.
● Require Halyard CLI to manage the
Spinnaker lifecycle.
● Can deploy apps into any on-premise VMs or
cloud data centers like AWS, GCP, Azure,
and Kubernetes.

19. ● ArgoCD is a declarative GitOps continuous
deployment tool for Kubernetes.
● Includes a command line tool and an
excellent graphical user interface
● Focused on enterprise use-cases (security,
RBAC, SSO, centralized multi-tenancy multi-
cluster management).

20. Let’s talk about CICD Pipeline and GitOps

21. A typical CICD Pipeline
( push-based model for deployments )

22. GitOps Pipeline
( pull-based model for deployments )

23. Scenario at Travelio

24. TBD + GitOps
( version 1.0.0 )

25. GitOps benefits
● Improved developer productivity and experience by saving time and effort. By pushing code, not
containers.
● Increased speed with continuous deployment automation.
● Improved CI/CD endurance since it provides an easy tracking mechanism.
● Higher security since Git used as a single source of truth.
● Consistency and uniformity of end-to-end workflows.

26. GitOps: the bad and the ugly
● You need to structure the environment repo and your pipelines to prevent concurrent push
on the same repo (since remote may be out of sync): multiple Cl processes can end up writing to
the same GitOps repo, causing conflicts or errors.
● Doesn't give you an opinionated way to deal with secret management (Git repositories are not
great places to store secrets, as you have to encrypt and decrypt them)

27. GitOps — Suggestions?
● Use two repos: one for app source code, another for manifest
● Never store secrets or key in manifest repo or even in your app as plain text and yes, base64 is
plain text too! (plan how to manage secrets)

28. Demo

29. Questions and Discussions

30. It’s Pizza 🍕 Time!
Catch me on gibz.wtf