What is CI/CD, and how does Jenkins implement continuous integration and continuous delivery?

Think of a car assembly line. Continuous Integration is like each worker checking their part fits correctly as they install it, rather than assembling the entire car and checking at the end. Continuous Delivery means the car is always in a state where it could drive off the line — it just needs a manager to wave the green flag. Continuous Deployment means the car drives off automatically the moment it passes all checks.

CI promotes small, frequent code changes that are automatically built and tested. When a developer pushes code, Jenkins detects the change (via webhook or polling), checks out the code, runs the build (compile, lint), executes unit and integration tests, and reports the result. If any step fails, the team is notified immediately. This catches bugs early when they are cheap to fix rather than late when they are expensive.

CD extends CI by automating the deployment pipeline. After successful CI, the artifact (Docker image, JAR, binary) is deployed to a staging environment, smoke tests run, and the change waits for manual approval before production deployment. When this final manual gate is also automated (deploy to production automatically if all checks pass), the process becomes Continuous Deployment.

Jenkins implements this through Jenkinsfiles — pipeline-as-code definitions that describe the stages (Build, Test, Deploy-Staging, Approval, Deploy-Prod), the agents (where to run each stage), and the logic (conditions, parallel steps, error handling). Jenkins supports both Declarative pipelines (structured YAML-like syntax) and Scripted pipelines (full Groovy flexibility). Shared Libraries allow organizations to define reusable pipeline logic that 50+ repositories can consume.

The non-obvious gotcha is that CI/CD is a practice, not just a tool. Installing Jenkins does not mean you have CI/CD — you need automated tests with good coverage, fast feedback loops (builds under 10 minutes), trunk-based development (short-lived branches), and a culture where broken builds are fixed immediately. Many teams have Jenkins but still deploy manually or have builds that take 2 hours — they have the tool but not the practice.