CI/CD – Continuous Integration, Continuous Delivery & Continuous Deployment
1. What is CI/CD?
CI/CD stands for Continuous Integration and Continuous Delivery/Continuous Deployment.
It is a DevOps practice used to automatically build, test, and deliver software applications whenever developers make code changes.
The main purpose of CI/CD is to reduce manual work, identify issues early, improve software quality, and deliver applications faster and more reliably.
Simple example
Suppose your team develops an ASP.NET Core Web API + Angular + SQL Server application.
Without CI/CD, developers may need to manually build, test, publish, and deploy the application.
With CI/CD, these activities can be automated using Azure Pipelines.
Developer
Writes code and pushes to Git
Continuous Integration (CI)
Restore → Build → Test → Package
Continuous Delivery / Deployment (CD)
Release → Deploy → Verify
Production Environment
Application available to users
2. What is Continuous Integration (CI)?
Continuous Integration is a development practice in which developers frequently integrate their code changes into a shared Git repository.
Whenever changes are pushed or a Pull Request is created, a CI pipeline can automatically build the application and execute automated tests.
Why do we need CI?
Consider three developers working on the same application:
-
Developer A develops the Login API.
-
Developer B develops the Customer API.
-
Developer C develops the Fund Transfer API.
When their code is integrated, compilation errors, dependency conflicts, or test failures may occur.
CI helps identify these problems early instead of discovering them during deployment.
How does CI work?
Developer Writes Code
↓
Git Commit & Push
↓
Azure Repos / GitHub
↓
CI Pipeline Triggered
↓
Restore Dependencies
↓
Build Application
↓
Run Automated Tests
↓
Build Successful?
/ \
Yes No
↓ ↓
Publish Notify
Artifact Developer
Example commands for ASP.NET Core
dotnet restore
dotnet build --configuration Release
dotnet test --configuration Release
dotnet publish -c Release -o ./publish
These commands can be executed automatically by Azure Pipelines.
Advantages of CI
-
Detects integration errors early.
-
Reduces manual build activities.
-
Ensures code changes are regularly validated.
-
Improves code quality through automated tests.
-
Produces consistent build outputs.
Important: CI does not necessarily deploy an application. Its primary responsibility is integrating, building, and validating code changes.
3. What is Continuous Delivery?
Continuous Delivery is a DevOps practice in which code changes are automatically built, tested, and prepared for release so the application is always in a deployable state.
The key point is that Production deployment can require manual approval.
Why do we need Continuous Delivery?
In enterprise applications, particularly banking and financial systems, Production deployment may require:
-
QA sign-off.
-
UAT approval.
-
Change management approval.
-
Business approval.
-
A scheduled release window.
Continuous Delivery automates the technical preparation while allowing authorized people to control the final release.
How does Continuous Delivery work?
Developer Pushes Code
↓
CI Pipeline
↓
Build & Automated Tests
↓
Publish Build Artifact
↓
Deploy to SIT
↓
Deploy to UAT
↓
QA / Business Validation
↓
Manual Production Approval
↓
Deploy to Production
Real-world example
Suppose your banking application has a new Fund Transfer feature.
-
Developer pushes the changes to Git.
-
CI pipeline builds and tests the application.
-
CD pipeline deploys the application to SIT.
-
QA team completes testing.
-
Application is promoted to UAT.
-
Business team approves the release.
-
Release Manager approves Production deployment.
-
Pipeline deploys the application to Production.
Important: Continuous Delivery does not require every environment to be deployed automatically. The defining principle is that validated software remains ready for release, with Production release controlled as needed.
Advantages
-
Application remains ready for release.
-
Reduces manual release preparation.
-
Supports approval and compliance requirements.
-
Provides repeatable deployment procedures.
-
Reduces deployment risk.
4. What is Continuous Deployment?
Continuous Deployment takes automation one step further.
Every code change that successfully passes the required automated validation checks is automatically deployed to Production without manual approval.
Why do we need Continuous Deployment?
It is useful for applications that require frequent updates and have strong automated testing, monitoring, and rollback capabilities.
For example:
-
SaaS applications.
-
E-commerce platforms.
-
Web applications with frequent feature releases.
-
Cloud-native applications.
How does Continuous Deployment work?
Developer Pushes Code
↓
CI Pipeline
↓
Build Application
↓
Automated Tests
↓
Security / Quality Checks
↓
Deploy to Test Environment
↓
Automated Validation
↓
Deploy to Production
↓
Monitor Application
There is no mandatory human approval between successful automated validation and Production deployment.
Real-world example
Suppose an e-commerce application requires a minor change to its product search feature.
-
Developer commits and pushes the code.
-
CI pipeline builds the application.
-
Automated tests execute.
-
Quality and security checks pass.
-
Deployment pipeline automatically releases the change to Production.
-
Monitoring checks application health.
If validation fails, the pipeline stops. Production monitoring may also trigger an automated rollback if configured.
Advantages
-
Faster release cycles.
-
Minimal manual intervention.
-
Frequent delivery of improvements.
-
Smaller changes make issues easier to isolate.
-
Rapid feedback from Production.
Disadvantages
-
Requires comprehensive automated testing.
-
Incorrect changes can reach Production if checks are insufficient.
-
Requires effective monitoring and rollback mechanisms.
-
May not suit environments requiring formal release approval.
5. Difference Between CI, Continuous Delivery & Continuous Deployment
|
Feature |
Continuous Integration |
Continuous Delivery |
Continuous Deployment |
|---|---|---|---|
|
Main purpose |
Integrate and validate code |
Keep application release-ready |
Automatically release to Production |
|
Build automation |
Yes |
Yes |
Yes |
|
Automated testing |
Yes |
Yes |
Yes |
|
Deployment automation |
Not required |
Supported |
Required |
|
Production approval |
Not applicable to CI itself |
Can be required |
No manual approval |
|
Production release |
Not part of CI |
On demand |
Automatic after checks |
|
Main benefit |
Detect errors early |
Reliable controlled releases |
Fast automated releases |
Visual comparison
Where the automation stops
CI
Build & test
Delivery
Release-ready; approval possible
Deployment
Automatic Production release
CI validates changes. Continuous Delivery prepares them for controlled release. Continuous Deployment releases them automatically after required checks.
6. How CI/CD works in Azure DevOps
Azure DevOps uses Azure Pipelines to implement CI/CD.
An Azure Pipeline commonly contains:
-
Trigger: Starts the pipeline when code changes occur.
-
Stage: Logical phase such as Build, Test, or Deploy.
-
Job: Group of operations executed on an agent.
-
Step: Individual script or task.
-
Agent: Machine executing pipeline operations.
-
Artifact: Build output used during deployment.
-
Environment: Logical target such as SIT, UAT, or Production.
-
Approval: Authorization required before certain deployment stages, when configured.
Example YAML – Basic CI Pipeline
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
steps:
- task: UseDotNet@2
inputs:
packageType: 'sdk'
version: '8.0.x'
- script: dotnet restore
displayName: 'Restore Dependencies'
- script: dotnet build -c Release --no-restore
displayName: 'Build Application'
- script: dotnet test -c Release --no-build
displayName: 'Run Unit Tests'
Explanation:
When a developer pushes changes to main, Azure Pipelines starts the CI process, restores dependencies, builds the application, and executes tests.
A complete CD pipeline would add artifact publishing and deployment stages, with environment approvals if required.
7. Practical Scenario – Banking Application
Suppose you are the Technical Lead for a banking application with four environments.
|
Environment |
Purpose |
Typical deployment control |
|---|---|---|
|
Development |
Developer integration and testing |
Automatic |
|
SIT |
System Integration Testing |
Automatic or controlled |
|
UAT |
Business acceptance testing |
Controlled |
|
Production |
Live application |
Manual approval or automatic, based on policy |
For a banking application with strict release controls, Continuous Delivery with Production approval is often more appropriate than fully automatic Continuous Deployment.
The CI pipeline ensures the code builds and tests pass. The CD pipeline deploys the validated application to the required environments using the organization's release policies.
8. Important Interview Questions and Answers
Q1. What is CI/CD?
CI/CD is a DevOps practice that automates code integration, building, testing, and software delivery or deployment.
Q2. What is the difference between Continuous Integration and Continuous Delivery?
Continuous Integration focuses on integrating, building, and testing code changes. Continuous Delivery extends the process by keeping the application ready for release and automating release preparation.
Q3. What is the main difference between Continuous Delivery and Continuous Deployment?
Continuous Delivery allows Production release to be controlled through manual approval. Continuous Deployment automatically releases every change that passes the required checks without manual approval.
Q4. Does CI automatically deploy code to Production?
No. CI primarily builds and validates code. Production deployment is handled by a release or deployment process.
Q5. Can CI/CD be implemented without Azure DevOps?
Yes. Other tools include GitHub Actions, Jenkins, GitLab CI/CD, and TeamCity.
Q6. What happens if a CI build fails?
The pipeline reports failure, and configured notifications or branch policies can prevent the change from being merged or deployed until the problem is resolved.
Q7. Which is better for a banking application: Continuous Delivery or Continuous Deployment?
Continuous Delivery is often preferred when Production releases require formal business, security, or change management approval.
Q8. What is the difference between a CI pipeline and a CD pipeline?
A CI pipeline builds and validates the application and may publish build artifacts. A CD pipeline deploys validated application artifacts to target environments.
9. Key Points to Remember
-
CI = Automatically Build + Test code changes.
-
Continuous Delivery = Keep software ready for release, with approval when required.
-
Continuous Deployment = Automatically deploy validated changes to Production.
-
Azure Pipelines supports all three practices.
-
CI/CD reduces manual errors and improves delivery consistency.
-
Automated testing is essential for reliable CI/CD.
-
Approval gates, security checks, monitoring, and rollback strategies are important for enterprise deployments.
Interview-ready answer
CI/CD is a DevOps practice used to automate software integration, testing, and delivery. Continuous Integration automatically builds and tests code changes whenever developers integrate their work. Continuous Delivery ensures the application is always ready for release, typically allowing controlled Production approval. Continuous Deployment goes further by automatically deploying every validated change to Production without manual intervention.
In Azure DevOps, we implement CI/CD using Azure Pipelines with YAML pipelines, build agents, automated tests, deployment stages, and environment approvals.