CI/CD Pipeline – Deployment Automation in 2026

TL;DR

CI/CD (Continuous Integration/Continuous Deployment) automates tests, build and deployments. It reduces errors, speeds up development and improves code quality. Here's how to configure CI/CD pipeline in 2026.

Who is this for

• Developers wanting to automate deployments
• Companies planning DevOps practices
• Teams working on multiple projects

Keywords (SEO)

ci cd pipeline, continuous integration, continuous deployment, github actions, devops automation

What is CI/CD?

CI (Continuous Integration):

• Automatic tests on every commit
• Early error detection
• Automatic build
• Code quality checks

CD (Continuous Deployment/Delivery):

• Automatic deployments
• Zero-downtime deployments
• Rollback capabilities
• Environment management

Benefits:

• Faster deployments
• Fewer errors in production
• Better code quality
• More confidence in changes

CI/CD Workflow

1. Developer pushes code

git add .
git commit -m "Add new feature"
git push origin main

2. CI Pipeline runs automatically

Steps:

1. Lint check (ESLint, Prettier)
2. Unit tests
3. Integration tests
4. Build application
5. Security scan
6. Deploy to staging

3. CD Pipeline deploys to production

After CI success:

1. Deploy to production
2. Smoke tests
3. Health checks
4. Rollback if error

GitHub Actions

Basic Configuration

.github/workflows/ci.yml:

name: CI

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'
        cache: 'npm'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Run linter
      run: npm run lint
    
    - name: Run tests
      run: npm test
    
    - name: Build
      run: npm run build

Deployment Workflow

.github/workflows/deploy.yml:

name: Deploy

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: test
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Build
      run: npm run build
    
    - name: Deploy to production
      run: |
        # Your deployment script
        npm run deploy
      env:
        DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}

Matrix Builds (Multiple Versions)

jobs:
  test:
    strategy:
      matrix:
        node-version: [16, 18, 20]
        os: [ubuntu-latest, windows-latest, macos-latest]
    
    runs-on: ${{ matrix.os }}
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
    
    - run: npm ci
    - run: npm test

GitLab CI

Basic Configuration

.gitlab-ci.yml:

stages:
  - test
  - build
  - deploy

variables:
  NODE_VERSION: "18"

before_script:
  - npm ci

test:
  stage: test
  script:
    - npm run lint
    - npm test
  only:
    - merge_requests
    - main

build:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 hour
  only:
    - main

deploy_staging:
  stage: deploy
  script:
    - npm run deploy:staging
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - develop

deploy_production:
  stage: deploy
  script:
    - npm run deploy:production
  environment:
    name: production
    url: https://example.com
  when: manual
  only:
    - main

Jenkins

Jenkinsfile (Pipeline as Code)

pipeline {
    agent any
    
    environment {
        NODE_VERSION = '18'
        DEPLOY_ENV = 'production'
    }
    
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }
        
        stage('Test') {
            steps {
                sh 'npm run lint'
                sh 'npm test'
            }
        }
        
        stage('Build') {
            steps {
                sh 'npm run build'
            }
        }
        
        stage('Deploy') {
            steps {
                sh 'npm run deploy'
            }
        }
    }
    
    post {
        success {
            echo 'Pipeline succeeded!'
        }
        failure {
            echo 'Pipeline failed!'
        }
    }
}

Best Practices

1. Fast Feedback

Quick tests:

• Run fast tests first
• Long tests in separate jobs
• Parallel execution

jobs:
  quick-tests:
    runs-on: ubuntu-latest
    steps:
      - run: npm run test:unit  # Fast
  
  slow-tests:
    runs-on: ubuntu-latest
    steps:
      - run: npm run test:e2e   # Slow

2. Cache Dependencies

Faster builds:

- name: Cache node modules
  uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

3. Environment Variables

Secure secrets:

env:
  DATABASE_URL: ${{ secrets.DATABASE_URL }}
  API_KEY: ${{ secrets.API_KEY }}

Don't commit:

• API keys
• Passwords
• Private keys
• Tokens

4. Conditional Deployments

Deploy only from main:

deploy:
  if: github.ref == 'refs/heads/main'
  steps:
    - run: npm run deploy

Manual approval:

deploy_production:
  when: manual  # GitLab CI
  # Or use environment protection rules in GitHub Actions

5. Rollback Strategy

Automatic rollback:

- name: Deploy
  run: npm run deploy

- name: Health check
  run: |
    sleep 30
    curl -f https://example.com/health || exit 1

- name: Rollback on failure
  if: failure()
  run: npm run rollback

6. Notifications

Status notifications:

- name: Notify on failure
  if: failure()
  uses: 8398a7/action-slack@v3
  with:
    status: failure
    text: 'Deployment failed!'
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

Deployment Strategies

1. Blue-Green Deployment

Two environments:

• Blue (production)
• Green (new version)

Process:

1. Deploy to Green
2. Tests on Green
3. Switch traffic Blue → Green
4. Blue as backup

Advantages:

• Zero downtime
• Fast rollback
• Safe deployments

2. Canary Deployment

Gradual deployment:

1. Deploy to small user group (5%)
2. Monitoring
3. Gradually increase (25%, 50%, 100%)
4. Rollback if problems

Advantages:

• Early problem detection
• Minimal impact
• Safe production testing

3. Rolling Deployment

Gradual updates:

1. Update servers one by one
2. Each server offline briefly
3. Health checks between updates

Advantages:

• Zero downtime (for multiple servers)
• Simple deployment
• Resource efficient

Monitoring and Alerting

Health Checks

- name: Health check
  run: |
    for i in {1..10}; do
      if curl -f https://example.com/health; then
        echo "Health check passed"
        exit 0
      fi
      sleep 10
    done
    echo "Health check failed"
    exit 1

Metrics

Monitor:

• Deployment success rate
• Build time
• Test coverage
• Error rate after deploy

FAQ

How Long Does CI/CD Setup Take?

For simple project: 1-2 days. For complex: a week. Worth investing time - saves it long-term.

Is CI/CD Needed for Small Projects?

Yes, even for small projects. GitHub Actions is free for public repos, GitLab CI also has free tier.

How Often to Deploy?

Depends on project. Some companies deploy multiple times per day. Important: small, frequent deploys are safer than large, rare ones.

Want to Configure CI/CD for Your Project?

• Contact