Cicd Pipelines

Continuous Integration is a development practice where developers frequently merge code changes into a shared repository, often multiple times a day. Each merge triggers an automated build and test process to detect integration errors early.

Key benefits:Early bug detectionReduced integration conflictsFaster feedback loopsConsistent build process

Continuous Delivery ensures code is always in a deployable state but requires a manual approval step before production release.

Continuous Deployment goes further: every change that passes all pipeline stages is automatically deployed to production with no human intervention.

Delivery = ready to deploy on demand
Deployment = auto-deployed every time

A standard CI/CD pipeline includes these stages:Source – code checkout from version controlBuild – compile code and resolve dependenciesTest – run unit, integration, and end-to-end testsStatic Analysis – linting, code quality checksSecurity Scan – SAST, dependency scanningPackage – create deployable artifactsDeploy – push to staging or productionRelease – make available to users

A GitHub Actions workflow is an automated process defined in a YAML file under .github/workflows/. It is triggered by events such as push, pull_request, or schedule.

A workflow contains one or more jobs, each consisting of steps that run commands or use actions.

Example trigger:
on: [push, pull_request]

Jobs – independent units of work that run on a runner. Jobs run in parallel by default but can depend on each other using needs.Steps – individual tasks within a job, executed sequentially. Each step either runs a shell command (run:) or uses an action (uses:).Actions – reusable packaged tasks from the GitHub Marketplace or custom repositories, referenced as uses: actions/checkout@v4.

Runners are servers that execute workflow jobs. GitHub provides:GitHub-hosted runners – managed VMs (Ubuntu, Windows, macOS) that are provisioned fresh for each jobSelf-hosted runners – machines you manage yourself, useful for custom hardware, private networks, or cost controlSpecified with:
runs-on: ubuntu-latest

A matrix build runs a job across multiple combinations of variables like OS, language version, or config. It uses the strategy.matrix keyword.

Example:
strategy:
  matrix:
    node: [16, 18, 20]
    os: [ubuntu-latest, windows-latest]

This creates 6 parallel jobs (3 versions × 2 OSes), ensuring compatibility across environments.

Reusable workflows allow you to define a workflow once and call it from other workflows using workflow_call.

The called workflow lives in a .github/workflows/ file and declares inputs and secrets.

Caller syntax:
jobs:
  call-workflow:
    uses: org/repo/.github/workflows/ci.yml@main
    with:
      env: production

This promotes DRY principles across repositories.

workflow_dispatch allows you to manually trigger a workflow from the GitHub UI, API, or CLI. You can define custom input parameters.

Example:
on:
  workflow_dispatch:
    inputs:
      environment:
        type: choice
        options: [staging, production]

Useful for ad-hoc deployments and maintenance tasks.

A Jenkinsfile is a text file that defines a Jenkins pipeline using code (Pipeline as Code). It is checked into the repository root.

Two syntax styles:Declarative – structured, opinionated syntax with pipeline { } blockScripted – flexible Groovy-based syntax with node { } blockDeclarative is recommended for most use cases due to readability and built-in validation.

pipeline {
  agent any
  stages {
    stage('Build') {
      steps { sh 'make build' }
    }
    stage('Test') {
      steps { sh 'make test' }
    }
    stage('Deploy') {
      steps { sh 'make deploy' }
    }
  }
}

Key blocks: agent (where to run), stages (what to do), steps (individual commands), and optional post (cleanup/notifications).

An agent specifies where a pipeline or stage runs. Options include:agent any – run on any available executoragent none – no global agent; each stage specifies its ownagent { label 'linux' } – run on a node with the given labelagent { docker { image 'node:18' } } – run inside a Docker containerAgents enable distributed builds across multiple machines.