DevOps and CI/CD basics

In short

DevOps is a working practice that merges software development and IT operations so that code moves from a developer's laptop to production in small, frequent, automated and reversible steps. Its engine is the CI/CD pipeline: continuous integration builds and tests every commit, continuous delivery keeps every build releasable, and continuous deployment pushes passing builds to production automatically. It matters because manual builds and quarterly "big bang" releases are the main source of integration conflicts, failed deployments and long outages. It is examined in AICTE/CBCS electives on Software Engineering, DevOps and Agile Software Development, and asked in almost every Indian IT placement interview — TCS, Infosys, Wipro, Accenture, Cognizant, HCLTech, LTIMindtree, Tech Mahindra and product firms such as Zoho, Flipkart, Razorpay and Freshworks hire explicitly for "DevOps engineer" and "SRE/build engineer" roles. Expect questions on pipeline stages, Git branching, Jenkinsfiles, IaC and deployment strategies rather than heavy mathematics.

Explained

Why DevOps exists: the wall of confusion

• Traditional model: developers were rewarded for shipping features fast, operations for keeping systems stable. Conflicting incentives created a hand-off "wall" where releases queued up and blame circulated.
• Waterfall/release-train symptoms: large batches of change, long-lived branches, painful merges ("merge hell"), manual deployment runbooks, environment drift between dev, test, UAT and production ("it works on my machine").
• DevOps answer: shared ownership ("you build it, you run it"), automation of every repeatable step, small batch sizes, fast feedback, and measurement.
• CALMS framework: Culture (shared responsibility), Automation (build, test, deploy, infra), Lean (small batches, remove waiting), Measurement (metrics on flow and failure), Sharing (common tooling and post-mortems).
• Three Ways (The Phoenix Project / DevOps Handbook): 1) flow — optimise left-to-right delivery; 2) feedback — fast signals right-to-left; 3) continual learning and experimentation (blameless post-mortems).
• DevOps is not a tool, a job title alone, or "one person who does deployments"; a single gatekeeper is an anti-pattern.

Version control and branching (the foundation)

• Everything in one source of truth: application code, test code, build scripts, database migrations, infrastructure definitions, pipeline definitions, configuration templates. Secrets are the exception — never in Git.
• Git essentials: clone, branch, commit, push, pull, merge, rebase, tag, cherry-pick, pull/merge request with peer review and required status checks.
• Trunk-based development: short-lived branches (hours to 2 days) merged into main; incomplete work hidden behind feature flags. Preferred for genuine CI.
• Git Flow: main, develop, feature/*, release/*, hotfix/*. Structured but slow; long-lived branches delay integration — unsuitable for several-times-a-day releases.
• GitHub Flow: main + feature branches + PR + deploy. Simple middle ground.
• Semantic versioning (SemVer): MAJOR.MINOR.PATCH — MAJOR for breaking changes, MINOR for backward-compatible features, PATCH for fixes. Pipelines usually tag builds 1.4.2+build.87.
• Monorepo vs polyrepo: monorepo simplifies atomic cross-service changes and shared libraries; polyrepo gives independent release cadence and smaller CI scope.

Continuous Integration (CI)

• Definition: every developer integrates work into the shared mainline at least daily; each integration is verified by an automated build and test run.
• Pre-conditions: a single automated build command, a self-testing build, a fast build (10-minute rule), a CI server triggered on every commit, and a team norm that a broken build is fixed before anything else ("stop the line").
• Typical CI stages: 1) checkout; 2) dependency resolution and cache restore; 3) compile; 4) unit tests; 5) static analysis / lint; 6) security scan (SAST, dependency/SCA scan); 7) package artefact; 8) publish to artefact repository.
• Build tools: Maven/Gradle (Java), npm/Vite (JavaScript), pip/poetry (Python), MSBuild (.NET), Make/CMake (C/C++). Builds must be reproducible — pinned dependency versions, no "latest".
• Artefact repository: Nexus, JFrog Artifactory, GitHub Packages, Amazon ECR for images. The rule is build once, promote the same artefact through environments; never rebuild per environment.
• Test pyramid: many fast unit tests → fewer integration/API tests → fewest slow end-to-end UI tests. An inverted pyramid ("ice-cream cone") makes pipelines slow and flaky.
• Shift-left testing: quality checks run as early as possible — pre-commit hooks, PR checks, not a testing phase at the end.
• Quality gate: build fails if coverage falls below a threshold, critical SonarQube issues appear, or a high-severity CVE is found.

Continuous Delivery, Continuous Deployment and pipelines

• Continuous Delivery: every build that passes the pipeline is *proven releasable* and could be deployed at the press of a button; the final push is a business decision.
• Continuous Deployment: the push is automatic — no human gate — so a green pipeline reaches production.
• Deployment pipeline (Humble & Farley): commit stage → automated acceptance tests → performance/capacity tests → manual/exploratory and UAT → production release. Later stages are slower and run on fewer builds.
• Environments: dev → SIT/QA → staging/pre-prod (production-like) → production. Differences are only in configuration, injected at deploy time (environment variables, config service, Kubernetes ConfigMap/Secret, AWS Parameter Store, HashiCorp Vault).
• Pipeline-as-code: Jenkinsfile (Groovy declarative), .github/workflows/*.yml (GitHub Actions), .gitlab-ci.yml, azure-pipelines.yml, bitbucket-pipelines.yml, .circleci/config.yml. Stored in the repo, reviewed like code, versioned with the application.
• Jenkins vocabulary: controller/agent (master/node), freestyle vs pipeline job, declarative vs scripted pipeline, stage, step, post, agent, webhook trigger, poll SCM, shared libraries, Blue Ocean UI.
• Runners/agents: ephemeral containers are preferred — a clean workspace each run prevents "works only on agent-3" problems.
• Release strategies:
  • Recreate (big bang): stop old, start new — simple, causes downtime.
  • Rolling update: replace instances in batches; default in Kubernetes Deployments.
  • Blue-green: two identical production stacks; switch the load balancer from blue to green; instant rollback by switching back. Doubles infrastructure cost briefly.
  • Canary: send 1-5% of traffic to the new version, watch error rate and latency, then increase. Needs good monitoring.
  • A/B testing: traffic split by user attribute to compare behaviour, not just safety.
  • Feature flags / dark launch: code deployed but inactive; decouples *deploy* from *release*, enables kill switches.
• Rollback vs roll-forward: stateless services roll back easily; database changes must be backward compatible (expand-contract: add column → dual write → migrate → remove), because you cannot un-drop a column.
• Database CI/CD: versioned migration scripts with Flyway or Liquibase, applied automatically and idempotently.

Infrastructure as Code, containers and configuration

• IaC definition: infrastructure described in version-controlled text files and created by tooling, so environments are reproducible and auditable.
• Declarative vs imperative: declarative states the desired end state (Terraform, CloudFormation, Kubernetes manifests) and converges to it; imperative lists commands (shell scripts).
• Provisioning vs configuration management: Terraform/CloudFormation/Pulumi create the servers, networks and databases; Ansible/Chef/Puppet/SaltStack configure what runs inside them. Ansible is agentless over SSH and most common in Indian shops.
• Idempotency: running the same IaC or playbook twice leaves the same end state — essential for safe re-runs.
• Terraform workflow: init → validate → plan (preview the diff) → apply → destroy; state file in a remote backend (S3 + DynamoDB lock) so teams do not corrupt it.
• Immutable infrastructure: never patch a running server; build a new image (Packer/Dockerfile) and replace it. Opposite of mutable/snowflake servers, which drift.
• Containers in the pipeline: the CI job builds an image, tags it with the commit SHA, scans it (Trivy/Clair), pushes it to a registry; the deploy job updates the manifest. Depth on Docker/Kubernetes internals belongs to the containers topic.
• GitOps: Git is the single source of truth for *desired cluster state*; an in-cluster agent (Argo CD, Flux) continuously reconciles the cluster to the repo — pull-based rather than the pipeline pushing credentials in.
• Secrets management: Vault, AWS Secrets Manager, Azure Key Vault, Kubernetes Secrets (base64, so encrypt at rest or use Sealed Secrets); rotate keys; inject at runtime. Hardcoded credentials in a public repo are the most common real-world DevOps breach in India.

DevSecOps, measurement and governance

• DevSecOps: security as a pipeline stage, not a pre-release audit — SAST (SonarQube, Semgrep), DAST (OWASP ZAP), SCA/dependency scanning (OWASP Dependency-Check, Snyk), container image scanning, IaC scanning (Checkov, tfsec), secret scanning (gitleaks), signed artefacts and SBOM.
• Least privilege: pipeline credentials scoped per environment; use OIDC federation instead of long-lived cloud keys; production deploy jobs require approval and are audit-logged.
• DORA four key metrics: deployment frequency, lead time for changes, change failure rate, and mean time to restore (MTTR). Reliability was later added as a fifth metric. Elite performers deploy on demand with lead times under an hour; low performers deploy monthly or less.
• Other useful metrics: build success rate, mean build duration, flaky-test rate, test coverage trend, deployment rollback count, cycle time.
• Indian regulatory and compliance context: the Digital Personal Data Protection Act, 2023 governs personal data in your pipelines and logs — do not copy production personal data into test environments; mask or synthesise it. RBI IT governance and outsourcing directions, and SEBI's cyber security and cyber resilience framework, require change-management records, segregation of duties, maker-checker approval and audit trails — so regulated Indian BFSI pipelines keep a human approval gate and immutable deployment logs even with full automation. CERT-In directions require logs to be retained (reported as 180 days, rolling) and incidents reported within 6 hours; MeitY empanelment and ISO/IEC 27001:2022, and ISO/IEC 20000-1 for service management, are commonly cited in Indian IT contracts. Rules under these frameworks are revised periodically — confirm the current text before quoting in an audit.
• Change management overlap: DevOps does not remove change control; it automates evidence. Low-risk, pre-approved standard changes flow through the pipeline; ITIL-style CAB review is reserved for high-risk changes.

Key points

• DevOps - culture plus automation that shortens the path from commit to production with fast feedback and shared ownership.
• CALMS - Culture, Automation, Lean, Measurement, Sharing; the usual exam framework for "what is DevOps".
• Continuous Integration - merge to mainline at least daily, every commit automatically built and tested.
• Continuous Delivery - every green build is releasable; the release itself is a one-click business decision.
• Continuous Deployment - no manual gate; passing builds go live automatically.
• Build once, promote - the same artefact moves dev → staging → prod; only configuration changes.
• Pipeline-as-code - Jenkinsfile / YAML workflow in the repo, versioned and reviewed with the application.
• Test pyramid - many unit, fewer integration, fewest UI tests; keeps the commit stage under ~10 minutes.
• Quality gate - automated pass/fail on coverage, static-analysis and vulnerability thresholds.
• Trunk-based development - short-lived branches plus feature flags; the branching model that makes CI real.
• Feature flag - decouples deployment from release and gives an instant kill switch.
• Blue-green vs canary - blue-green switches all traffic between two stacks; canary ramps a small percentage gradually.
• IaC - version-controlled, declarative, idempotent infrastructure definitions (Terraform, Ansible, CloudFormation).
• Immutable infrastructure - replace servers/images instead of patching them, eliminating configuration drift.
• GitOps - a cluster agent (Argo CD/Flux) pulls desired state from Git and reconciles continuously.
• DORA metrics - deployment frequency, lead time for changes, change failure rate, MTTR (plus reliability).
• DevSecOps - SAST, DAST, SCA, image and IaC scanning, secret scanning run inside the pipeline.
• Expand-contract migration - backward-compatible database changes so a rollback does not lose data.

Formulas and examples

Example 1 - DORA metrics for a release train. A Pune fintech team made 48 production deployments in 30 days. Five caused incidents needing a rollback or hotfix. Total restoration time across those five was 7 hours 30 minutes. Median commit-to-production time was 9 hours.

• Deployment frequency = 48 ÷ 30 = 1.6 deployments per day.
• Change failure rate = (5 ÷ 48) × 100 = 10.42%.
• MTTR = 450 min ÷ 5 = 90 minutes.
• Lead time 9 hours → by the DORA bands this is "high" on frequency and lead time, and a change failure rate in the acceptable 0-15% band; the improvement lever is lead time, not stability.

Example 2 - cutting pipeline time by parallelising. A Jenkins pipeline has: checkout 1 min, compile 4 min, unit tests 12 min, SonarQube scan 6 min, image build 3 min, push 2 min.

• Sequential total = 1 + 4 + 12 + 6 + 3 + 2 = 28 minutes.
• Unit tests and the Sonar scan are made parallel after compile: that block takes max(12, 6) = 12 min.
• New total = 1 + 4 + 12 + 3 + 2 = 22 minutes, a saving of 6 min (21.4%).
• Unit tests are then split across 4 agents; 12 min is 90% parallelisable, so that stage = 12 × (0.10 + 0.90/4) = 12 × 0.325 = 3.9 min; block = max(3.9, 6) = 6 min → total = 1 + 4 + 6 + 3 + 2 = 16 minutes. Overall reduction from 28 to 16 min = 42.9%.
• Lesson: after the first split the Sonar scan, not the tests, is the bottleneck — optimise the critical path, not the loudest stage.

Example 3 - cost of a self-hosted runner versus hosted minutes. A team runs 60 builds a day, 22 working days a month, each build 16 minutes.

• Monthly minutes = 60 × 22 × 16 = 21,120 minutes (352 hours).
• Hosted CI minutes at ₹0.70 per minute = 21,120 × 0.70 = ₹14,784 per month.
• Self-hosted alternative: two cloud VMs at ₹9,500 each per month = ₹19,000, plus ~6 engineer-hours of maintenance at ₹1,200/hour = ₹7,200 → ₹26,200 per month.
• Hosted is cheaper here by ₹11,416 per month. Break-even on hosted minutes = 26,200 ÷ 0.70 = 37,429 minutes/month, i.e. about 2,340 builds a month at 16 minutes each; beyond that, self-hosting wins. (Vendor prices change — treat the rates as inputs.)

Example 4 - canary release risk arithmetic. A new build has an unknown defect that would fail 2% of requests. The service takes 500 requests per second and the canary carries 5% of traffic for 10 minutes before automatic rollback.

• Canary traffic = 500 × 0.05 = 25 req/s; over 600 s = 15,000 requests.
• Failed requests = 15,000 × 0.02 = 300 requests.
• Full "recreate" deployment instead: 500 × 600 = 300,000 requests × 0.02 = 6,000 failures — 20× worse, exactly the 1/0.05 traffic ratio.
• Error budget check: a 99.9% monthly SLO on 1.296 billion requests (500 × 2,592,000 s) allows 1,296,000 errors; 300 is negligible, 6,000 still small — but a 2-hour undetected outage would consume 3.6 million errors and blow the budget.

Example 5 - availability and the cost of a manual release window. A team releases monthly with a 90-minute planned downtime window; monthly period = 30 × 24 × 60 = 43,200 minutes.

• Availability = (43,200 − 90) ÷ 43,200 × 100 = 99.79% — below a 99.9% SLO (which allows only 43.2 min/month).
• Moving to blue-green with zero-downtime switchover removes the 90 minutes, giving 100% planned availability and leaving the whole 43.2-minute budget for unplanned events.

// Jenkinsfile - declarative pipeline, build once and promote
pipeline {
  agent { docker { image 'maven:3.9-eclipse-temurin-21' } }
  options { timeout(time: 20, unit: 'MINUTES') }
  environment { IMG = "registry.example.in/payments:${env.GIT_COMMIT.take(7)}" }
  stages {
    stage('Build')  { steps { sh 'mvn -B -ntp clean package' } }
    stage('Checks') {
      parallel {
        stage('Unit tests') { steps { sh 'mvn -B test' } }
        stage('SAST')       { steps { sh 'mvn -B sonar:sonar' } }
      }
    }
    stage('Image') { steps { sh "docker build -t $IMG . && trivy image --exit-code 1 --severity CRITICAL $IMG && docker push $IMG" } }
    stage('Deploy staging') { steps { sh "kubectl -n staging set image deploy/payments app=$IMG" } }
    stage('Approve prod')   { steps { timeout(time: 2, unit: 'HOURS') { input message: 'Release to production?' } } }
    stage('Deploy prod')    { steps { sh "kubectl -n prod set image deploy/payments app=$IMG" } }
  }
  post { always { junit 'target/surefire-reports/*.xml' } failure { echo 'Build broken - stop the line' } }
}

# .github/workflows/ci.yml - CI on every push and pull request
name: ci
on: { push: { branches: [main] }, pull_request: {} }
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '22', cache: 'npm' }
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - run: npm audit --audit-level=high
      - uses: actions/upload-artifact@v4
        with: { name: dist, path: dist/ }

Where it is used

• IT services and GCCs: TCS, Infosys, Wipro, HCLTech, Accenture, Cognizant, LTIMindtree and Capgemini staff large DevOps/platform-engineering practices that modernise client pipelines; "Jenkins + Ansible + Terraform + AWS" is a standard Indian job description.
• Indian product and consumer tech: Flipkart, Zomato, Swiggy, Zoho, Freshworks, Razorpay, PhonePe and Ola deploy many times a day using trunk-based development, feature flags and canary releases behind their own platform teams.
• BFSI and regulated workloads: banks, NBFCs and insurers run CI/CD with a mandatory approval gate, segregation of duties and audit trails to satisfy RBI/SEBI change-management and DPDP Act expectations; UPI-scale systems rely on blue-green switchovers.
• Public digital infrastructure: NIC, UIDAI/Aadhaar services, GSTN, IRCTC and DigiLocker-linked services use automated provisioning and staged rollouts on MeitY-empanelled cloud; CERT-In logging requirements shape pipeline audit design.
• Job roles: DevOps engineer, build-and-release engineer, platform/SRE engineer, cloud engineer, automation/QA engineer in CI; typical fresher-to-3-year DevOps salaries in India run roughly ₹4-12 lakh per annum, varying widely by city and employer.
• Certifications asked for: AWS Certified DevOps Engineer, Microsoft DevOps Engineer Expert (AZ-400), Certified Kubernetes Administrator, HashiCorp Terraform Associate, Docker/Jenkins vendor courses.

Interview questions

• Q: What is the difference between continuous delivery and continuous deployment? A: In continuous delivery every green build is proven releasable but a human decides when to release; in continuous deployment that decision is automated and every green build goes to production.
• Q: Why is trunk-based development recommended for CI? A: Long-lived branches delay integration, so conflicts accumulate and the "integration" in continuous integration never actually happens daily; short-lived branches with feature flags keep merges small and the mainline always releasable.
• Q: What does "build once, deploy many" mean and why does it matter? A: The same binary or image is promoted through all environments with only configuration changing; rebuilding per environment means you test an artefact that is not the one you ship.
• Q: How would you roll back a release that includes a database migration? A: Use backward-compatible expand-contract migrations so the old code still works against the new schema, then roll back only the application; destructive changes (dropping a column) are deferred to a later release.
• Q: Blue-green or canary — which would you choose for a payments API? A: Canary, because it limits blast radius to a few percent of real traffic and surfaces defects under production load; blue-green is better when you need an instant all-or-nothing switch and have capacity to double.
• Q: A build passes locally but fails in CI. How do you debug it? A: Assume environment difference — compare toolchain versions, unpinned dependencies, missing environment variables or secrets, test ordering and leftover local state; run the job in the same container image the agent uses.
• Q: What is a flaky test and how do you handle it? A: A test that passes and fails on the same code, usually from timing, shared state or external dependencies; quarantine it, fix the root cause, and never make the pipeline pass by retrying blindly, which hides real defects.
• Q: What is Infrastructure as Code, and what is idempotency in that context? A: Infrastructure defined in version-controlled files and created by tooling; idempotency means applying the same definition repeatedly converges on the same end state rather than stacking changes.
• Q: How do you keep secrets out of a pipeline? A: Store them in a secret manager or Vault, inject at runtime as masked variables, prefer short-lived OIDC-federated cloud credentials over static keys, scan the repo with gitleaks, and rotate anything ever committed.
• Q: Which four metrics would you report to measure DevOps performance? A: The DORA metrics — deployment frequency and lead time for changes (throughput), change failure rate and MTTR (stability) — because improving throughput alone at the cost of stability is not progress.
• Q: What is GitOps and how does it differ from a push-based pipeline? A: Git holds the desired cluster state and an in-cluster agent such as Argo CD continuously reconciles to it; the cluster pulls, so the pipeline never needs production credentials and drift is corrected automatically.
• Q: Does DevOps remove the need for change management in a regulated Indian bank? A: No — it automates the evidence; standard low-risk changes flow through the pipeline with logged approvals and segregation of duties, while high-risk changes still go through formal review under RBI/SEBI and audit expectations.
• Q: Your commit stage takes 45 minutes. What do you do? A: Measure stage times, parallelise independent stages, shard tests across agents, cache dependencies and build layers, move slow end-to-end tests to a later pipeline stage, and target under ten minutes for the commit stage.

Common mistakes

• Defining DevOps as a set of tools or a job title, instead of culture plus automation plus measurement — the most commonly lost exam mark.
• Confusing continuous delivery with continuous deployment; the distinguishing point is only the manual release gate.
• Calling a nightly build "CI". CI is triggered per commit; a nightly build gives feedback a day late.
• Rebuilding the artefact for each environment, or changing code between staging and production, so what was tested is not what ships.
• Putting secrets, API keys or .env files in Git, or printing them in build logs.
• Treating a red build as normal and continuing to commit on top of it, instead of stopping the line.
• Writing imperative shell scripts and calling them IaC, or editing cloud resources by hand so the Terraform state and reality diverge.
• Automating deployment without monitoring, health checks or an automated rollback path — fast deploys then mean fast outages.
• Copying production personal data into test environments, which breaches DPDP Act obligations and client contracts.

Related topics

Containers: Docker and Kubernetes · Cloud computing basics · Monitoring and site reliability engineering · IT service management and ITIL · Software engineering and agile methodologies · Linux command line essentials