In this session, we will compare traditional CI/CD and GitOps approaches to continuous deployment. Using practical examples, we will demonstrate how to implement both methods using Azure Pipelines and FluxCD. In traditional CI/CD workflows, code changes are pushed through a pipeline to reach production, while in GitOps, changes are submitted and detected by a GitOps agent that synchronizes them with the production environment. We will discuss the advantages and disadvantages of each method and how to optimize your continuous deployment process using Azure Pipelines and FluxCD. Attendees will learn which method is best suited for their needs and how to improve software development and deployment.

1. Continuous Deployment Showdown:
Traditional CI/CD vs. GitOps
Marc Müller
Principal Consultant
marc.mueller@4tecture.ch
@muellermarc
www.4tecture.ch

3. Slide Download
https://www.4tecture.ch/events/dotnetday2023

4. Agenda
▪ Intro
▪ Setup
▪ Implementing the Deployment
▪ Staging
▪ Automatic Updates
▪ Cluster Setup with Azure
Pipelines
▪ Conclusion

5. Intro

6. Once upon a time…
Source: https://pixabay.com/de/illustrations/ai-generiert-mann-designer-7974535/, https://imgflip.com/i/7x3amn, https://imgflip.com/i/7x3apt, https://imgflip.com/i/7x3at0
* pretty similar

7. Our playground…
▪ ASP.NET Core Application
▪ Dockerized
▪ Kubernetes deployment environment

8. Kubernetes Deployment
Deployment Pod
Service
Pod
Pod
Ingress
Secret
Secret
Secret
ConfigMap
HPA
ReplicaSet
dapr
component
Sidecar Pod

9. We focus on deployment …this is the build

10. Kustomize
▪ Standalone tool
▪ for customizing Kubernetes objects
▪ by using a declarative configuration language
▪ Built-in in kubectl since 1.14
▪ kustomization.yaml → procecces
resources
▪ Bases and overlays
▪ Patches, ConfigMaps and Secrets,
Variable substitution

11. Helm
▪ Package Manger for Kubernetes
▪ Define, install and upgrade Kubernetes
applications
▪ Configuration based on «Charts»
Source: https://helm.sh/

12. Helm Features
▪ Manage Complexity
▪ Charts describe even the most complex apps
▪ Provide repeatable application installation
▪ Serve as a single point of authority
▪ Easy Updates
▪ Take the pain out of updates
▪ In-place upgrades
▪ Custom hooks.
▪ Simple Sharing
▪ Versioning
▪ Easy to share, and host on public or private servers
▪ Rollbacks
▪ Use helm rollback to roll back to an older version of a release with ease.
Source: https://helm.sh/

13. Source: https://imgflip.com/i/7xal0f

14. GitOps
▪ Declarative Configuration:
▪ System state is described in a declarative manner, usually using files like YAML.
▪ Version-Controlled System State:
▪ Desired system state is stored in a version control system, typically Git.
▪ Git serves as the single source of truth.
▪ Automated Delivery:
▪ Changes in the Git repository trigger automatic system updates.
▪ Software Agents Ensure System Convergence:
▪ Tools continuously monitor and ensure the actual system state matches the desired state in the Git repository.
▪ Any discrepancies lead the system to self-correct to match the desired state.
▪ Infrastructure as Code (IaC):
▪ Infrastructure setup and configuration are defined and version-controlled as code.
▪ Enhanced Visibility and Traceability:
▪ All changes are tracked, auditable, and can be rolled back using Git's capabilities.
▪ Reduced Manual Intervention:
▪ Direct changes to production are discouraged.
▪ Changes are made via pull requests or commits to the repository.

15. GitOps
By following these principles, GitOps
aims to make operations and deployment
more consistent, repeatable, and secure.

16. Setup

17. General Setup
Deployment Target (k8s)
Config
(Git)
Artifacts
(Container Registry)
Deployer App
Container
Image
Helm
Chart

18. Azure Pipelines

19. Base
Infrastructure
CD
Service
CD
Pipeline Design
Base Infrastructure
Template
Resource Template
Resource Template
Dev/Test Prod
Service
CI
Build Stage
PR Stage
Testing PreProd Prod
Compile
Service
DB Schema
Compile
System Tests
Infrastructure
Artifacts
Pipeline
Artifacts
Task / Job Templates
Task / Job Templates
Resource Groups, vNets, VMs, Azure SQL,
CosmosDB, …
App Deployment, DB instance, DB Schema,
Managed Identities, Storage, …
Deplyoment Verification

20. Azure DevOps & AKS CI / CD
Azure DevOps
CI Pipeline
Azure DevOps
CD Pipeline
Container
Registry
Build App
Test
Build Container
Repo
Configuration
Helm Upgrade
AKS (Cluster)
Helm Chart
Package
Push
Cluster
Pull container image
Release
Pull
Helm
chart

21. Configuration as Code
▪ Pipelines, Templates, Variables / Values
files stored in Git
▪ Do not store secrets in Git!
▪ Mono-Repo / Repo per Service
▪ Staging is implemented by
▪ Feature Branches → PR → PR Deployment with QA → PR Approval / Integration
▪ Main Branch → Pre Production → Production (checks and approvals,
deployment rings)

24. helm upgrade --install azdodeploymentagent
.chartsdeploymentagent
--namespace azdoagent
--create-namespace
--set agent.pool=k8sdemodeployment
--set agent.token=xxxx

25. Flux

26. FluxCD
▪ Open-source GitOps toolkit for
Kubernetes
▪ Part of the CNCF
▪ Monitors Git repositories
▪ Automatically applies the changes to the
cluster

27. Flux Source Controller

28. Flux Kustomize Controller

29. Flux Helm Controller

30. Flux Notification Controller

31. Flux Image Update Automation

32. Setup Flux
▪ Install the CLI
▪ Installation in k8s
▪ flux bootstrap
▪ flux install
▪ Add kustomizations, sources, …
Deployment Target (k8s)
Config
(Git)
Artifacts
(Container Registry)
Flux
Controller
Flux
Controller
Flux
Controller
Flux
Controller

33. Implementing the
Deployment

34. Azure Pipelines

35. CD Pipeline with CI Resource

36. Define Versioning

37. Deployment Job

38. Deployment

39. Deployment

40. Configuration

41. Flux

42. Kustomization

43. Helm Repository

44. Helm Release

45. Configuration

46. Unique Resource Names

47. Staging

48. Azure Pipelines

49. Pipeline Stages

50. Environments

51. Dedicated Settings per Stage

52. Dedicated Settings per Stage

53. Flux

54. Structuring Best Practices
▪ Use base configuration with overlays
▪ Overlay config maps / secrets
▪ Overlay objects with patches
- apps
- application1
- base
- overlays
- dev
- prod
- application2
- base
- overlays
- dev
- prod

55. Structure

56. Overlay Kustomization

57. Overlay Values

58. Patch Release

59. Add dedicated objects

60. Automatic Updates

61. Azure Pipelines

62. Out-of-the box: triggers and branches
▪ Pipeline Triggers on Source Update
▪ Use a branching concept and PR workflow
▪ PR deployments
▪ Checks and Approvals

63. Flux

64. GitOps
▪ Git Repo defines what is deployed
▪ No update without new commit
Repo Updates
▪ Task after successful CI
▪ Listen for new images / Helm charts

65. Flux Image Automation
▪ Monitor Container Registry
▪ Analyze updates based on policy
▪ Change configuration – commit change in
GIT repo
▪ Standard GitOps flow is triggered

66. Image Repository

67. Image Policy

68. Image Update Automation

70. Updates

71. Updates

72. Cluster Setup
with Azure Pipelines

73. Deploy Cluster Services
▪ Cluster setup has a lot of Helm chart deployments
▪ Configuration as Code
▪ Pipeline automation on configuration object
▪ Runtime Parameters / Parameters support objects
▪ Define your cluster configuration as object

74. Parameter with all charts

76. Add and update Helm Repos

77. Install helm charts

78. Conclusion

79. Comparison
Pipelines
▪ Everything in Git
▪ Versatile
▪ Full DevOps Lifecycle
▪ End-to-end
Traceability
▪ Integrated Test
Automation
Flux
▪ Everything in Git
▪ K8s Deployments
▪ Focus on Continuous
Deployment
▪ Independent /
Various Sources

80. Conclusion
▪ Both provide a state-of-the-art deployment
▪ Git is the source of truth
▪ We use
▪ Azure Pipelines: Classic Development to
Deployment (CI/CD)
▪ Flux: disconnected from development / prod
cluster deployment

81. Q & A

82. Thank you for your attention!
If you have any questions do not hesitate to contact us:
4tecture GmbH Marc Müller
Industriestrasse 25 Principal Consultant
CH-8604 Volketswil
+41 44 508 37 00 marc.mueller@4tecture.ch
info@4tecture.ch @muellermarc
www.4tecture.ch www.powerofdevops.com