Skip to content

CI/CD Pipelines

InteSys designs and implements CI/CD pipelines that automate your build, test, and deployment workflow. We specialize in GitLab CI and GitHub Actions but support any major CI/CD platform.

Pipeline Design Principles

A well-designed pipeline should be:

  • Fast — Parallel stages, caching, and incremental builds minimize feedback time
  • Reliable — Deterministic builds with pinned dependencies and reproducible environments
  • Secure — Secrets managed externally, images scanned, and least-privilege execution
  • Observable — Clear logs, artifacts, and status notifications

GitLab CI

GitLab CI is our recommended platform for teams using self-hosted or GitLab SaaS repositories.

Example Pipeline

stages:
  - test
  - build
  - deploy

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_TLS_CERTDIR: "/certs"

test:
  stage: test
  image: python:3.12-slim
  script:
    - pip install -r requirements.txt
    - pytest tests/ --junitxml=report.xml
  artifacts:
    reports:
      junit: report.xml

build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -t $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest
  only:
    - main

deploy:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl set image deployment/myapp myapp=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  environment:
    name: production
  only:
    - main
  when: manual

Key GitLab CI Features

  • Docker-in-Docker — Build container images inside CI jobs
  • Artifacts and caching — Share files between stages and speed up builds
  • Environments — Track deployments per environment with rollback support
  • Protected variables — Store secrets securely with environment-scoped access
  • Review apps — Spin up temporary environments for merge request review

GitHub Actions

For teams on GitHub, we build workflows using GitHub Actions with reusable components.

Example Workflow

name: CI/CD Pipeline

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest tests/

  build-and-push:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

Automated Testing in Pipelines

Test Type Stage Purpose
Unit tests test Validate individual functions and methods
Integration tests test Verify component interactions
Linting test Enforce code style and catch common errors
SAST test Static security analysis
Container scan build Detect vulnerabilities in Docker images
Smoke tests deploy Verify deployment health after release

Fail Fast

Run the fastest tests first (linting, unit tests) so developers get quick feedback. Move slower tests (integration, security scans) to later stages.

Deployment Strategies

Blue-Green Deployment

Maintain two identical environments. Deploy to the inactive one, verify, then switch traffic.

  • Zero downtime — Traffic switches instantly
  • Easy rollback — Switch back to the previous environment
  • Cost — Requires double the infrastructure during deployment

Canary Deployment

Gradually route a percentage of traffic to the new version.

  • Risk reduction — Issues affect only a small percentage of users
  • Metrics-driven — Promote or rollback based on error rates and latency
  • Complexity — Requires traffic splitting (Istio, Nginx, or cloud load balancer)

Rolling Update

Replace instances one at a time (Kubernetes default).

  • Resource efficient — No extra infrastructure needed
  • Gradual — Old and new versions run simultaneously during rollout
  • Rollback — Kubernetes automatically rolls back on failed health checks

Next Steps