Enabling GitOps - Architecture for Implementation

Enabling GitOps - Architecture for Implementation

• 1.
  GitOps (Tagging Optimized) Bao Huynh SiteReliability Engineering Team
• 2.
  Agenda ● GitOps ● GitOpsbranch name convention (optimized) ● Jenkins destiny ?
• 3.
  1. GitOps -Why ●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
• 4.
  1. GitOps branches& environments
• 5.
  1. GitOps flow -thanos - ironman - hulk
• 6.
  1. GitOps withDEV ●Source code changes (validation/checkdup/…) ●Gitops-helm (app-backend/validation.yaml /checkdup.yaml /…..)
• 7.
  2. GitOps -Branch name convention Branch name for DEV should be one of below: ● mabu ● growth ● fse ● me ● uat ● master => no “tagging-number” (0.0.5) at the end of branch name
• 8.
  2. GitOps -Reuse branch after merge GitOps support re-use dev-branch after code changes was merge to master. => Helps a lot in removing unnecessary branches (with tagging- number) => Only keep 2 branches for SDLC (uat & dev)
• 9.
  2. GitOps -Tag bumping (on Master) TAG for release will be bumped automatically whenever there's a commit merge (on Master) Support title parsing in Merge commit message: ● [MINOR] → increase minor version & push new tag ● [MAJOR] → increase major version & push new tag ● Default → increase patch version & push new tag ● [SKIP] → do not bump & do not push tag
• 10.
  3. GitOps -Jenkins replacement ● Replace Jenkins for K8S deployment action (Staging/Production) * For microservice on K8S only
• 11.
  Questions & Answers