CI/CD & DevOps

Git's Object Model & Workflows

Git is a content-addressable filesystem. Every piece of data is stored as an object identified by its SHA-1 hash. Understanding the four object types and how they compose is the key to mastering Git.

The DAG, Refs & Index

Commits form a Directed Acyclic Graph (DAG) -- each commit points to its parent(s), never creating cycles. Branches and tags are simply refs: mutable pointers (files in .git/refs/) to commit hashes. HEAD is a symbolic ref pointing to the current branch.

The index (staging area) sits between your working directory and the repository. git add writes blobs and updates the index; git commit converts the index into a tree and creates a commit object.

Merge vs Rebase

CI: Fast Feedback on Every Commit

Continuous Integration is the practice of merging developer work into a shared mainline frequently -- ideally multiple times per day. Each integration triggers an automated pipeline that builds, tests, and reports results within minutes.

The Fast Feedback Loop

The core principle: developers should know within 10 minutes if their change broke something. This requires fast builds, parallelized test suites, and caching of dependencies and build artifacts. If CI is slow, developers batch changes and integration becomes painful.

Static Analysis (SAST)

Static Application Security Testing analyzes source code without executing it. Tools like SonarQube, Semgrep, and CodeQL scan for security vulnerabilities (SQL injection, XSS, hardcoded secrets), code smells, and style violations. SAST runs early in the pipeline because it needs no running environment.

Dependency Scanning (SCA)

Software Composition Analysis examines your dependency tree (package-lock.json, requirements.txt, go.sum) against known vulnerability databases (CVE/NVD). Tools like Dependabot, Snyk, and Trivy alert on vulnerable transitive dependencies and can auto-generate upgrade PRs.

CD: From Build to Production

Continuous Delivery ensures that code is always in a deployable state and that releasing to production is a one-click decision. Continuous Deployment goes further: every change that passes the pipeline is automatically deployed with no human gate.

Pipeline Stages

Artifact Management

Build artifacts (Docker images, JARs, binaries) are stored in a versioned registry (Docker Hub, ECR, Artifactory, Nexus). Each artifact is immutable and tagged with the commit SHA or semantic version. The same artifact that passes staging is the one deployed to production -- never rebuild for a different environment.

Environment Promotion

Code progresses through environments: dev → staging → production. Configuration differs per environment (via env vars or config files), but the artifact stays the same. This guarantees that what you tested is what you deploy. Promotion can be automated (continuous deployment) or gated by manual approval.

Rolling, Blue-Green, Canary & More

How you roll out changes to production determines your blast radius when things go wrong. Each strategy trades off between speed, safety, and infrastructure cost.

Database Migrations

Schema changes are the hardest part of zero-downtime deployments. The key principle: make migrations backward-compatible. Use the expand-contract pattern:

IaC: Terraform, CloudFormation & GitOps

Infrastructure as Code (IaC) means defining servers, networks, and services in version-controlled configuration files instead of clicking through consoles. This makes infrastructure reproducible, reviewable, and auditable.

Terraform State

Terraform's state file (terraform.tfstate) is a JSON mapping between your HCL resources and real-world infrastructure IDs. It enables terraform plan to diff desired vs. actual state. State must be stored remotely (S3, GCS, Terraform Cloud) with locking (DynamoDB) to prevent concurrent modifications.

# Terraform remote state backend
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

GitOps: ArgoCD & Flux

GitOps applies the Git workflow to infrastructure. The desired state of your Kubernetes cluster is declared in a Git repository. A controller (ArgoCD or Flux) continuously watches the repo and reconciles the cluster to match. Drift detection is automatic -- if someone manually changes the cluster, the controller reverts it.

Immutable Infra & Ansible

Two contrasting philosophies for managing servers: treat them as cattle (immutable, replaceable) or pets (mutable, carefully maintained). Modern practice strongly favors the cattle approach.

Immutable Infrastructure

With immutable infrastructure, you never modify a running server. Instead, you bake a new machine image (AMI, Docker image) with every change, test it, then replace running instances. This eliminates configuration drift and makes rollback as simple as pointing to the previous image version.

Configuration Management with Ansible

Ansible is an agentless configuration management tool that uses SSH to push configuration to servers. It uses YAML playbooks to declare desired state. While it's traditionally a "mutable infrastructure" tool, it's still widely used for provisioning base images and for environments where full immutability isn't practical.

# Ansible playbook example
- hosts: webservers
  become: yes
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present

    - name: Copy config
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: restart nginx

  handlers:
    - name: restart nginx
      service:
        name: nginx
        state: restarted