CI/CD / AWS

GitHub to EKS: a practical CI/CD flow

A simple production-oriented pipeline from source code to a running Kubernetes workload.

MANISH KUMAR SINGH · DEVOPS NOTES

The flow

  1. Developer pushes code to GitHub.
  2. Pipeline runs linting and automated tests.
  3. Docker image is built.
  4. Image is scanned and tagged with an immutable version such as the Git commit SHA.
  5. Image is pushed to Amazon ECR.
  6. Pipeline authenticates to AWS and deploys the new image to EKS.
  7. Deployment health is verified.
  8. If verification fails, roll back to the previous known-good version.

Why use an immutable image tag?

Using a commit SHA or release identifier makes it possible to know exactly which build is running. Avoid relying only on a mutable tag such as latest for production deployments.

Typical Kubernetes deployment

kubectl -n app set image deployment/app \
  app=ACCOUNT.dkr.ecr.REGION.amazonaws.com/app:COMMIT_SHA

kubectl -n app rollout status deployment/app

Where failures should be visible

Each pipeline stage should produce useful logs. A failed test should stop the build. A failed image push should prevent deployment. A failed rollout should trigger a controlled response rather than silently leaving a broken release in production.

Production principle: Build once, promote the same immutable artifact, verify the deployment and keep the previous version available for rollback.