CI/CD stands for Continuous Integration and Continuous Delivery or Continuous Deployment.
It is a DevOps practice that automates how code is built, tested, packaged, delivered, and deployed. CI/CD helps teams release software faster while reducing manual work, integration problems, and deployment risk.
A simple CI/CD workflow is:
Code → Build → Test → Security Check → Package → Deploy → Monitor
What Is Continuous Integration?
Continuous Integration, or CI, is the practice of frequently merging small code changes into a shared source-code repository such as GitHub, GitLab, or Bitbucket.
Each code commit automatically triggers a pipeline that:
- Downloads the latest code
- Compiles or builds the application
- Runs automated tests
- Checks code quality
- Creates a deployable artifact
CI helps developers detect errors soon after code is committed instead of waiting for a large nightly or weekly build.
Simple CI Example
A developer pushes Java code to GitHub.
A webhook triggers Jenkins. Jenkins downloads the code, runs Maven to build it, executes automated tests, and reports whether the build passed or failed.
If the build fails, the team fixes the problem before continuing.
Continuous Delivery vs. Continuous Deployment
The term CD can mean either Continuous Delivery or Continuous Deployment.
| Practice | Meaning | Production Approval |
|---|---|---|
| Continuous Integration | Automatically builds and tests code changes | Not applicable |
| Continuous Delivery | Keeps every successful change ready for production | Usually manual |
| Continuous Deployment | Automatically releases every successful change to production | No manual approval |
The easiest way to remember the difference is:
Continuous Delivery keeps the release ready. Continuous Deployment releases it automatically.
Continuous deployment requires reliable automated testing, monitoring, security checks, and rollback processes because production deployment happens without a manual approval gate.
CI/CD Pipeline Stages
A practical CI/CD pipeline normally contains the following stages.
1. Source
Developers write code and commit it to a source-code repository such as GitHub.
The commit or pull request triggers the pipeline through a webhook or repository event.
2. Build
The pipeline compiles the source code and packages it into a deployable format.
Examples include:
- Java JAR or WAR file
- Docker image
- ZIP package
- Application binary
Tools such as Maven, Gradle, npm, and Docker are commonly used during this stage.
3. Automated Testing
The pipeline runs tests to confirm that the application works correctly.
Important tests may include:
- Unit tests
- Integration tests
- API tests
- Acceptance tests
- Regression tests
A failed test should stop the pipeline.
4. Code Quality and Security Checks
The pipeline examines the code, dependencies, container images, and configuration for quality or security problems.
Common checks include:
- Static code analysis
- Dependency scanning
- Secrets detection
- Container-image scanning
- Policy and compliance validation
These checks convert a normal CI/CD pipeline into a DevSecOps pipeline.
5. Artifact Creation
After the build and tests pass, the pipeline stores the deployable package in an artifact repository.
Examples include:
- JFrog Artifactory
- Nexus Repository
- Docker Hub
- Amazon ECR
- GitHub Container Registry
A strong practice is to build the artifact once and promote the same tested artifact through development, staging, and production.
Rebuilding the application separately for every environment can create inconsistencies.
6. Staging Deployment
The application is deployed to a staging environment that closely matches production.
Teams may run additional integration, performance, security, and user-acceptance tests here.
7. Production Deployment
With Continuous Delivery, an authorized person approves the production release.
With Continuous Deployment, the pipeline automatically deploys the application after all checks pass.
Common deployment strategies include:
- Rolling deployment
- Blue-green deployment
- Canary deployment
These strategies reduce downtime and deployment risk.
8. Monitoring and Rollback
CI/CD does not end after deployment.
Teams monitor:
- Application health
- Error rates
- Response time
- Infrastructure usage
- Logs and alerts
- Business transactions
When a serious problem occurs, the team should be able to roll back quickly to the last stable version.
CI/CD and Jenkins
CI/CD is a software delivery practice. Jenkins is an automation server that can implement CI/CD pipelines.
Jenkins can integrate with tools such as:
- GitHub for source code
- Maven or Gradle for builds
- Selenium for testing
- SonarQube for code quality
- JFrog or Nexus for artifacts
- Docker for containers
- Ansible for configuration and deployment
- Kubernetes for container orchestration
A Jenkins pipeline is normally defined in a Jenkinsfile and stored with the application code in source control.
Modern Jenkins terminology uses:
- Controller: Manages Jenkins configuration and schedules work
- Agent: Executes pipeline jobs and stages
- Node: A machine capable of running Jenkins work
- Workspace: Directory where Jenkins stores files for a job
- Plugin: Adds integrations or capabilities
- Pipeline: Automated sequence of stages and steps
Jenkins agents perform work requested by the controller, allowing builds to run across different operating systems and environments.
Common CI/CD Tools
| Purpose | Common Tools |
|---|---|
| Source control | Git, GitHub, GitLab, Bitbucket |
| Pipeline automation | Jenkins, GitHub Actions, GitLab CI/CD, Azure Pipelines |
| AWS CI/CD | CodePipeline, CodeBuild, CodeDeploy |
| Build tools | Maven, Gradle, npm |
| Testing | JUnit, Selenium, pytest |
| Code quality | SonarQube |
| Artifact management | JFrog, Nexus, Amazon ECR |
| Containers | Docker and Kubernetes |
| GitOps deployment | Argo CD and Flux |
| Monitoring | CloudWatch, Prometheus, Grafana and Datadog |
Benefits of CI/CD
CI/CD helps organizations:
- Detect bugs earlier
- Release smaller changes
- Reduce manual deployment errors
- Receive faster developer feedback
- Maintain consistent deployments
- Improve software quality
- Recover from failed releases faster
- Deliver features to users more frequently
CI/CD does not eliminate risk by itself. Poor tests, insecure credentials, unstable environments, and missing monitoring can still cause production failures.
CI/CD Best Practices
- Commit small code changes frequently.
- Run the pipeline for every important code change.
- Stop the pipeline when a critical test fails.
- Store pipeline definitions in source control.
- Keep credentials in a secrets-management system.
- Build once and promote the same artifact.
- Use separate development, testing, staging, and production environments.
- Add security and quality gates.
- Keep pipelines fast and remove unnecessary stages.
- Monitor deployments and maintain a tested rollback process.
Practical DevOps Engineer Responsibilities
A DevOps engineer working with CI/CD may:
- Create and maintain pipelines
- Configure repository webhooks
- Write Jenkinsfiles or workflow files
- Manage build agents
- Configure tools and credentials
- Troubleshoot failed builds
- Manage artifacts
- Add security and quality gates
- Automate application deployment
- Configure notifications
- Monitor pipeline performance
- Maintain backups and documentation
Your original Jenkins material covered many of these operational responsibilities, including integrations, Jenkinsfiles, access control, scheduling, troubleshooting, and pipeline maintenance.
Simple CI/CD Analogy
Think about an online food order:
- Continuous Integration: The kitchen checks each ingredient and cooking step.
- Continuous Delivery: The completed order is packed and ready for pickup.
- Continuous Deployment: The order is automatically sent to the customer without waiting for manual approval.
CI/CD Interview Questions
What is CI/CD?
CI/CD is a DevOps practice that automates code integration, building, testing, delivery, and deployment. It helps teams release software quickly, consistently, and reliably.
What is the difference between Continuous Delivery and Continuous Deployment?
Continuous Delivery keeps the application ready for production but normally requires approval. Continuous Deployment automatically releases every successful change to production.
Is Jenkins the same as CI/CD?
No. CI/CD is a software delivery practice. Jenkins is one of the tools used to automate CI/CD pipelines.
What happens when a pipeline fails?
The pipeline stops at the failed stage. The DevOps engineer reviews logs, identifies whether the problem comes from code, tests, dependencies, credentials, infrastructure, or configuration, and works with the correct team to resolve it.
What is an artifact?
An artifact is the deployable output created by the build process, such as a JAR file, WAR file, ZIP package, binary, or Docker image.
CI/CD Interview Answer to Memorize
“CI/CD is an automated software delivery practice. Continuous Integration frequently merges code changes and validates them through automated builds and tests. Continuous Delivery keeps every successful change ready for production with a possible approval step. Continuous Deployment automatically releases every successful change to production. Tools such as Jenkins, GitHub Actions, Docker, SonarQube, and artifact repositories help implement the pipeline.”
Final Summary
CI/CD creates a reliable path from source code to production.
- CI integrates, builds, and tests code.
- Continuous Delivery keeps the application ready to release.
- Continuous Deployment automatically releases successful changes.
- Jenkins is one tool used to automate this process.
For interviews, remember the workflow:
Commit → Build → Test → Scan → Package → Deploy → Monitor