What Is CI/CD? How the Pipeline Works, CI vs CD, and Your First Workflow in 2026

Your teammate merges a one-line fix on Friday evening. Nobody runs the test suite because it takes eleven minutes and the change is obviously safe. By Saturday morning the checkout endpoint is returning 500s for every customer whose address has an apostrophe in it, and three people are on a call trying to work out which of the nine commits since Tuesday broke it. That Saturday is the reason CI/CD exists, and understanding what CI/CD is really means understanding which part of that story each half prevents.

What Is CI/CD? The Definition That Actually Helps

CI/CD stands for continuous integration and continuous delivery, or continuous deployment depending on how far you take it. The useful definition is behavioural rather than lexical: CI/CD is the agreement that no code change reaches users without passing through the same automated gauntlet, every single time, with no exceptions for small changes or senior engineers.

Continuous integration is the first half. Every developer merges their work into the shared main branch frequently, often several times a day, and every merge triggers an automated build and test run. The point is not the automation. The point is that integration problems surface within minutes of being created, while the person who caused them still remembers what they were doing, instead of surfacing three weeks later during a release freeze.

Continuous delivery is the second half. Every change that passes CI produces a deployable artefact, usually a container image or a versioned package, that could go to production at any moment. Whether it actually goes is a business decision. Continuous deployment removes even that decision: pass the pipeline, go live.

The part most explanations skip

CI/CD is a branching policy wearing a tooling costume. If your team keeps six long-lived feature branches alive for a month each, no pipeline on earth will give you continuous integration, because nothing is being integrated. Trunk-based development, where short-lived branches merge into main within a day or two, is the practice; the pipeline is just the enforcement mechanism. Teams that buy the tool and keep the branching habits get slower builds and the same merge pain.

How a CI/CD Pipeline Works, Stage by Stage

A CI/CD pipeline is an ordered list of jobs where each job only runs if the previous one succeeded. Here is the shape almost every team converges on, whatever tool they use.

Two properties of that diagram matter more than the stage names. First, the artefact is built once, at stage 4, and the identical image is promoted through staging and production. If you rebuild per environment you are testing one binary and shipping a different one. Second, every stage has a defined failure behaviour. Stage 3 failing stops everything and pings the author. Stage 9 failing triggers a rollback. A pipeline where failure means "someone notices eventually" is not a pipeline.

Also read: Docker Tutorial for Beginners 2026: Containerise a Python API in 7 Steps, which builds the exact artefact stage 4 produces.

CI vs CD: What Is CI/CD Short For?

This is where the confusion lives, because CD means two different things and people use it interchangeably. The distinction is not academic. It determines whether you need an approval workflow, a change advisory process, and a human awake at deploy time.

Which one should you aim for? For most teams in India shipping a business application, continuous delivery is the right target and continuous deployment is not. That is an opinion, and here is the trade-off I am accepting: you give up some deploy frequency in exchange for not needing feature flags, canary infrastructure and a mature on-call rota before you get any value at all. Continuous deployment is genuinely better once you have those three things. Building them first, in order to deploy a CRUD app twelve times a day, is work you do not need yet.

The exception is teams where the approval step is theatre. If your release manager approves every build within ninety seconds without looking, you have the cost of a gate and none of the benefit. Either make the approval mean something or delete it.

CI/CD Tutorial for Beginners: A Workflow You Can Copy Today

Take a four-person team at a Pune logistics SaaS with a Python API. No pipeline today, tests that run locally when someone remembers. Here is the first file they should commit, at .github/workflows/ci.yml.

name: ci

on:
  push:
    branches: [main]
  pull_request:

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-python@v6
        with:
          python-version: "3.12"
          cache: pip
      - run: pip install -r requirements.txt
      - run: ruff check .
      - run: pytest -q --maxfail=1

Four lines in that file do the heavy lifting and beginners usually omit all four. concurrency with cancel-in-progress kills the previous run when you push again, which on a busy branch halves your minute consumption. timeout-minutes stops a hung test from burning a full six hours of your quota. cache: pip turns a ninety second dependency install into about ten seconds on a warm cache. --maxfail=1 stops the suite at the first failure, because you are going to fix that one anyway.

Pin action versions to a major tag and let Dependabot bump them. As of September 2026 actions/checkout is on the v6 major line and actions/setup-python shipped v6.3.0 on 15 September 2026 with a v7 line now out, so check the releases page rather than copying a version from a two-year-old tutorial. GitHub's changelog also confirms that JavaScript actions began running on Node.js 24 by default from 2 June 2026, which is why very old third-party actions started failing this year.

Adding the CD half

The deploy job builds the image once, tags it with the commit SHA, and pushes it. The environment key is what creates the approval gate at stage 7: configure a required reviewer on that environment in repository settings and the job pauses until someone approves.

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment:
      name: production
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v6
      - name: Build and push image
        run: |
          echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
          docker build -t ghcr.io/${{ github.repository }}:${{ github.sha }} .
          docker push ghcr.io/${{ github.repository }}:${{ github.sha }}

When it breaks, and it will, do not debug by pushing commits with messages like "fix ci 7". Reproduce the runner locally with the same container and the same command:

# run the exact test command inside the same image the pipeline builds
docker build -t api:local .
docker run --rm api:local pytest -q

# roll production back to the previous known-good tag
kubectl set image deploy/api api=ghcr.io/acme/api:9f2c1ab
kubectl rollout status deploy/api --timeout=120s

That 10x macOS multiplier is the one that catches people. A build matrix that tests on Linux, Windows and macOS consumes thirteen minutes of quota for every one minute of macOS wall-clock time, and a private repository on the Free plan can exhaust its monthly allowance in a single afternoon of debugging.

What Usually Goes Wrong in a CI/CD Pipeline

Here is the thing nobody tells you on day one: the pipeline will be ignored long before it is deleted. It happens the same way every time. One test is flaky, so people start re-running the job instead of investigating. Then two tests are flaky. Then a red build stops meaning anything, someone adds a bypass for urgent fixes, and within a quarter you are back to Friday evening merges with extra YAML.

Where You Will Meet CI/CD in Real Work

CI/CD stopped being a specialist DevOps topic a while ago. Three places you will run into it depending on the job you hold.

As a backend or platform engineer, you own the pipeline. That means writing the workflow files, managing environments and secrets, and being the person who explains why the deploy is blocked. This is the core of the AWS DevOps Engineer Professional syllabus: SDLC automation carries 22% of the DOP-C02 exam, the heaviest of its six domains, and the exam itself is 75 questions in 180 minutes with a 750 out of 1000 pass mark according to the AWS exam guide. It is covered end to end in 360DT's live AWS Solutions Architect and DevOps program, and the equivalent Microsoft path, AZ-400, is taught in the Azure architect and DevOps course. If you are choosing between the two stacks, our SAA-C03 vs DOP-C02 guide covers the ordering question.

As a data engineer, the same pipeline shape applies to transformations rather than services. You lint SQL, run dbt tests against a small sample, and promote a validated artefact from dev to production workspaces; Microsoft Fabric deployment pipelines are the managed version of exactly this, and they appear in the DP-700 objectives that the Microsoft Fabric data engineering course works through. The failure mode differs: a broken service returns errors, a broken transformation silently produces wrong numbers that a Power BI report renders beautifully. Analysts hitting that problem from the reporting side usually find it in the Power BI and PL-300 track.

As an AI or ML engineer, CI/CD grows a second axis. You are versioning prompts, datasets and model endpoints alongside code, and your "test" is an eval suite scored against a fixed set of cases rather than a pass or fail assertion. Running retrieval evals in CI before a prompt change reaches users is now standard practice on serious teams, which is why it sits inside both the AI engineer course covering RAG and agents and the MLOps engineer course built around AI-300. The reason DORA's four key metrics, deployment frequency, lead time for changes, change failure rate and failed deployment recovery time, keep showing up in job descriptions is that they are the only widely agreed way to say whether any of this is working.

Also read: What Is Kubernetes? Plain-English Definition, How It Works and Where You Will Use It in 2026, which explains the deployment target most CD stages are pointing at.

How to Learn CI/CD Properly in 8 Weeks

You cannot learn this from reading. The skill is debugging a pipeline that is failing for a reason the logs do not state plainly, and that only comes from having a pipeline of your own that breaks. Eight weeks, a few hours each weekend, one repository.

If you want the structured version with someone reviewing your pipeline, the AWS Solutions Architect and DevOps course is the closest fit, running live on Saturdays and Sundays from 8 to 11 PM IST. If you are not ready to commit to a paid program, sit in on a free webinar first, or compare the whole certifications overview to see where a DevOps credential sits next to the data and AI tracks.

Related guides

• DevOps Engineer Salary in India 2026 tells you what pipeline skills are actually worth once you have them.
• AZ-305 vs AZ-400: Which Azure Certification First is the Microsoft-side version of the certification ordering question.
• IT Support to Cloud Engineer in India 2026 is the realistic route in if pipelines are new territory for you.
• MLOps Engineer Salary in India 2026 covers where CI/CD skills go when you point them at models instead of services.
• Data Engineer Roadmap 2026 shows the same promote-an-artefact pattern applied to Fabric pipelines.
• Cloud Engineer Jobs in Chennai 2026 lists the GCC employers who ask about CI/CD in the first interview.

Frequently asked questions

What I would do in your position

If you are learning this in 2026 with a job in mind, do not start by comparing Jenkins, GitLab CI, CircleCI and Argo CD. Pick GitHub Actions, put one real project through the eight week plan above, and get to the point where you can roll back a bad deploy calmly while it is serving traffic. That single demonstrated skill separates candidates in DevOps interviews far more reliably than a list of tools on a CV, because everyone lists the tools and almost nobody can describe a rollback they personally performed.

Then, and only then, add a certification to make the skill legible to recruiters. DOP-C02 is the strongest signal on the AWS side and its heaviest domain is the work you have already done. If you would rather see how that is taught before paying for anything, take the AWS Solutions Architect and DevOps course page as your starting point, or book a free demo class and watch a pipeline get built live.

About this guide. 360 Digital Transformation is an Authorized Training Partner of Anthropic and Microsoft. Other certification bodies, vendors and employers named in this guide are not affiliated with us. Tools and versions change quickly; commands and figures cited were checked on 15 September 2026.