Kubernetes Deployment Strategy Using Helm on Amazon EKS

There are multiple deployment strategies available for Kubernetes workloads. In our setup, we use a Helm chart–based deployment model to onboard and manage applications in an Amazon EKS (Elastic Kubernetes Service) cluster.

Helm Chart Management
For each microservice, a corresponding Helm chart is created to define Kubernetes resources such as Deployments, Services, ConfigMaps, and Ingresses.

• Helm charts are stored within the same GitHub repository as the application’s source code.

• This approach ensures version alignment between application code and deployment configuration.

We deploy or upgrade applications using the following Helm command:
helm upgrade -i <chart_name> <chart_path_location> -n --values <values_path_location>
This command installs the chart if it does not exist, or upgrades it if it is already deployed.

Docker Image Build
Each microservice repository contains a Dockerfile, which is used to build the application container image.

• The Dockerfile resides alongside the application source code.

• This ensures consistent and reproducible builds across environments.

Container Image Registry
For every application, a dedicated Amazon ECR (Elastic Container Registry) repository is created in the Preprod AWS account.

• Image repositories are currently created manually.

• All built images are pushed to ECR and reused across environments.

CI/CD Pipeline Overview
We use AWS CodePipeline to implement our CI/CD workflow.
Prerequisites

• The required GitHub repository must be connected to AWS via a GitHub connection.

• Proper IAM permissions must be configured for CodePipeline and CodeBuild.

Pipeline Stages

1. Source Stage (GitHub)

• Uses GitHub v2 as the source provider.

• The pipeline is configured to track a specific repository and branch.

• Automatic change detection is enabled, triggering the pipeline whenever changes are pushed to the configured branch.

2. Build Stage (AWS CodeBuild)
In this stage, the following activities take place:

• Application code compilation

• Docker image build

• Docker image push to Amazon ECR

Image Tagging Strategy

• Images are tagged using the first 7 characters of the GitHub commit SHA.

• This provides traceability between the deployed image and the source code commit.

All images are pushed to the staging account ECR registry.

3. Deployment Stage (AWS CodeBuild)
Since AWS CodeDeploy does not natively support EKS deployments, we use CodeBuild for deployment as well.

• A separate CodeBuild project is created for each environment.

• Deployment logic includes:

  • Establishing connectivity with the EKS cluster

  • Executing Helm upgrade/install commands

• Deployment commands are maintained in the buildspec.yml file.

Manual Approval

• A manual approval stage is added before deploying to Preprod and Production.

• This prevents unintended or automatic deployments to critical environments.

Environment-Specific Pipelines
Based on requirements, pipelines can be structured as follows:

• QA Pipeline

  • Typically uses the development branch

  • Supports frequent deployments for rapid testing

• Preprod & Prod Pipeline

  • Uses the master (or main) branch

  • Changes flow from QA → Preprod → Production after validation

This separation ensures controlled and stable deployments in higher environments.

Build Promotion Strategy
We follow a strict build promotion model:

• Images must be successfully deployed and validated in Preprod before they can reach Production.

• Direct deployment to Production is not allowed.

• Pipeline stages are sequential and dependent, ensuring that each stage completes successfully before progressing.

This approach enforces reliability, traceability, and governance across the deployment lifecycle.