CI/CD Best Practices with Jenkins and AWS

A reliable CI/CD pipeline is the backbone of modern software delivery. Over the years, I have built and maintained pipelines that deploy to production dozens of times per day. Here are the patterns that consistently deliver results.

Modern CI/CD pipelines should be fast, reliable, and completely automated

Pipeline Architecture: The Seven Stages

Every production-grade pipeline I build follows this structure. Stages run sequentially, and the pipeline fails fast — no point running a 20-minute integration test suite if the linter catches an error in 10 seconds.

pipeline {
  agent { docker { image "node:18-alpine" } }

  stages {
    stage("Install")     { steps { sh "npm ci" } }
    stage("Lint")        { steps { sh "npm run lint" } }
    stage("Unit Test")   { steps { sh "npm run test:ci" } }
    stage("Build")       { steps { sh "npm run build:prod" } }
    stage("Security")    { steps { sh "npm audit --audit-level=high" } }
    stage("Deploy Staging") {
      when { branch "develop" }
      steps { sh "./deploy.sh staging" }
    }
    stage("Deploy Production") {
      when { branch "main" }
      steps {
        input message: "Deploy to production?"
        sh "./deploy.sh production"
      }
    }
  }

  post {
    failure { slackSend channel: "#deploys", message: "Pipeline FAILED" }
    success { slackSend channel: "#deploys", message: "Deployed successfully" }
  }
}

Docker Multi-Stage Builds

Container image size directly impacts deployment speed and cold start time. Multi-stage builds let you use a full Node.js image for building and a minimal image for running:

# Build stage
FROM node:18 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage
FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/main.js"]

This typically reduces image size from 1.2 GB to under 200 MB, which means faster pulls and faster deployments.

Multi-stage builds dramatically reduce container sizes and deployment times

Zero-Downtime Deployment on AWS

For production services that cannot afford downtime, I use blue-green deployment with AWS:

• Blue environment — The current production version handling live traffic
• Green environment — The new version deployed and tested in isolation
• ALB switching — Once green passes health checks, the load balancer switches traffic
• Instant rollback — If issues arise, switch back to blue in seconds

Combined with health check endpoints and automated smoke tests, this approach has given me zero-downtime deployments across hundreds of production releases.

The goal of CI/CD is not just automation — it is confidence. Every commit should build, test, and deploy with zero manual intervention and complete auditability.