This project demonstrates an end-to-end CI/CD and GitOps workflow for deploying a three-tier voting application on Azure Kubernetes Service (AKS). The workflow uses Azure DevOps pipelines to build Docker images, push them to Azure Container Registry (ACR), update Kubernetes manifests, and allow Argo CD to synchronize the updated application state to AKS.
This repository uses Docker's open-source example voting application as the sample workload. The main focus of this project is the Azure DevOps, ACR, AKS, Kubernetes manifest, and Argo CD deployment workflow.
The project shows how application changes can move from source code to a running Kubernetes workload through an automated CI/CD and GitOps process.
Main workflow:
- A developer commits application or manifest changes.
- Azure DevOps pipeline is triggered.
- Docker image is built for the changed service.
- Image is pushed to Azure Container Registry.
- Kubernetes manifest is updated with the new image tag.
- Updated manifest is committed to the manifest repository.
- Argo CD detects the manifest change.
- Argo CD synchronizes the desired state to AKS.
- AKS pulls the updated image from ACR.
- Kubernetes rolls out the updated workload.
This diagram shows the complete deployment workflow. A source code or manifest change triggers the Azure DevOps pipeline. The pipeline builds the Docker image, pushes it to Azure Container Registry, updates the Kubernetes manifest with the new image tag, and commits the updated manifest to Git. Argo CD watches the manifest repository and synchronizes the desired state to AKS. AKS then pulls the updated image from ACR and performs the Kubernetes rollout.
This is the main architecture and process diagram for the project.
| Category | Tools and Services |
|---|---|
| Cloud Platform | Microsoft Azure |
| CI/CD | Azure DevOps Pipelines |
| Container Registry | Azure Container Registry |
| Container Platform | Azure Kubernetes Service |
| GitOps | Argo CD |
| Containerization | Docker |
| Orchestration | Kubernetes |
| Workload | Docker example voting app |
| Manifest Management | Kubernetes YAML files |
Table 1. Technology stack used in the project
The deployed workload is based on Docker's example voting application.
| Application Tier | Components |
|---|---|
| Frontend tier | vote web app and result web app |
| Processing tier | worker service |
| Data tier | Redis and PostgreSQL |
Table 2. Application tiers used as the sample workload
azure-devops-aks-gitops-voting-app/
├── docs/
├── healthchecks/
├── k8s-specifications/
├── result/
├── screenshots/
├── scripts/
├── seed-data/
├── vote/
├── worker/
├── .gitattributes
├── .gitignore
├── ATTRIBUTION.md
├── azure-pipelines-result.yml
├── azure-pipelines-vote.yml
├── azure-pipelines-worker.yml
├── docker-compose.yml
├── docker-compose.images.yml
├── docker-stack.yml
├── LICENSE
└── README.md
The Azure DevOps pipeline contains three major stages.
| Stage | Purpose |
|---|---|
| Build | Builds the Docker image from the application Dockerfile |
| Push | Pushes the image to Azure Container Registry |
| Update | Updates the Kubernetes manifest with the latest image tag |
Table 3. Azure DevOps pipeline stages
The following screenshots document the implementation and verification of the project.
This screenshot shows the full workflow used in this project. Azure DevOps handles the CI/CD portion by building and pushing images. Argo CD handles the GitOps portion by synchronizing Kubernetes manifests to AKS.
This matters because it explains the complete automation path from code commit to Kubernetes rollout.
This screenshot shows the inbound security rule configuration for the AKS node virtual machine scale set. The rule allows traffic to the required service port, which is needed when exposing the deployed application through the cluster node or service configuration.
This matters because application access often requires both Kubernetes service configuration and cloud network access configuration.
This screenshot shows the Argo CD resource topology for the deployed voting application. It displays Kubernetes resources such as services, deployments, replica sets, endpoints, and pods.
This matters because it confirms that Argo CD is tracking the deployed resources and that the application components are visible in the GitOps dashboard.
This screenshot shows the application in Argo CD with a Healthy and Synced status. This means the desired state stored in Git matches the actual state running in the AKS cluster.
This matters because Healthy and Synced status is the key confirmation that the GitOps deployment is working correctly.
This screenshot shows the Argo CD system pods running in the Kubernetes cluster. Components such as the application controller, repo server, Redis, Dex server, notifications controller, and Argo CD server are running.
This matters because Argo CD must be running properly before it can monitor Git and synchronize workloads to AKS.
This screenshot shows a successful Azure DevOps pipeline run with Build and Push stages completed. The Build stage creates the Docker image, and the Push stage uploads the image to Azure Container Registry.
This matters because it confirms that the CI portion of the workflow is functional.
This screenshot shows the Azure DevOps CI pipeline summary. It confirms that the pipeline was manually triggered and completed successfully.
This matters because it verifies that Azure DevOps can execute the build and push workflow on demand.
This screenshot shows detailed pipeline execution information, including the repository, branch, commit, elapsed time, and completed stages.
This matters because it provides traceability between the pipeline run, Git commit, and deployment workflow.
This screenshot shows the three main stages of the pipeline: Build, Push, and Update. Build creates the Docker image, Push uploads the image to ACR, and Update modifies the Kubernetes manifest with the new image tag.
This matters because it shows the complete CI/CD sequence used to prepare the application for GitOps synchronization.
This screenshot shows multiple successful Azure DevOps pipeline runs. It includes recent runs for pipeline setup, manifest updates, and application updates.
This matters because it shows repeatable pipeline execution rather than a one-time run.
This screenshot shows the update history for the pipeline. It displays successful runs connected to the main branch and their execution status.
This matters because it demonstrates that changes were tracked and deployed through the pipeline workflow.
This screenshot shows a successful pipeline execution where Build, Push, and Update stages all completed. It confirms that the pipeline performed the full automation sequence from image build to manifest update.
This matters because it is direct evidence of the end-to-end CI/CD pipeline working successfully.
The GitOps flow uses the manifest repository as the source of truth. After the pipeline updates the Kubernetes YAML file, Argo CD detects the change and compares it with the current state of the AKS cluster. If there is a difference, Argo CD applies the updated manifest to bring the cluster into the desired state.
Code or manifest change
↓
Azure DevOps Pipeline
↓
Build Docker image
↓
Push image to ACR
↓
Update Kubernetes manifest
↓
Commit manifest update to Git
↓
Argo CD detects Git change
↓
Argo CD syncs to AKS
↓
AKS pulls image from ACR
↓
Kubernetes rollout updates pods
Secrets should not be committed to this repository. Azure DevOps personal access tokens, service principal passwords, kubeconfig files, .env files, and registry credentials should be stored securely using Azure DevOps secure variables, variable groups, service connections, or Kubernetes secrets.
This project uses Docker's open-source example voting application as the sample workload. The original application code and architecture belong to the Docker samples project. The focus of this repository is the Azure DevOps CI/CD and GitOps deployment workflow on Azure Kubernetes Service.
This project demonstrates a complete cloud deployment automation workflow using Azure DevOps, Azure Container Registry, AKS, Kubernetes, and Argo CD. It shows how a containerized application can be built, pushed, updated, synchronized, and deployed using a repeatable CI/CD and GitOps process.