# Day 12 - Introduction to CI/CD

## 🎯 **What is CI/CD?**

**CI/CD** stands for **Continuous Integration** and **Continuous Delivery/Deployment**.

It is a **set of practices and automated processes** that help teams **build, test, and deliver software** efficiently and reliably.

---

## 🧩 **Why CI/CD is Needed**

Before CI/CD, teams deployed applications **manually** — testing, scanning, and deploying took **weeks or months**.

With modern applications, users expect updates **every few days or even hours**, so companies must:

* Deliver software **quickly and safely**
    
* Ensure **code quality and security**
    
* Reduce **human effort and error**
    

👉 CI/CD **automates** these steps.

---

## ⚙️ **CI (Continuous Integration)**

Continuous Integration is the process of **automatically building and testing code** whenever developers make changes.

### Steps involved:

1. **Code Commit:** Developers push code to a **Version Control System (VCS)** such as GitHub, GitLab, or Bitbucket.
    
2. **Build Process:** The code is automatically compiled or built (e.g., using Maven for Java).
    
3. **Unit Tests:** Automated unit tests verify small pieces of functionality.
    
4. **Static Code Analysis:** Tools check for syntax errors, unused variables, and poor code practices (e.g., using **SonarQube**).
    
5. **Code Quality & Security Scan:** Tools detect vulnerabilities and ensure secure code.
    

✅ CI ensures that new code **integrates smoothly** with the existing codebase and remains **stable**.

---

## 🚀 **CD (Continuous Delivery / Deployment)**

After successful integration, the **Continuous Delivery** phase automates:

1. **Functional / Integration Testing:** Ensures new code doesn’t break other features.
    
2. **Report Generation:** Summarizes test results, code quality, and coverage.
    
3. **Deployment:** Pushes code to environments like **Dev**, **Staging**, or **Production**.
    

**Continuous Deployment** goes one step further — automatically deploying to production without manual approval.

---

## 🧠 **How CI/CD Works (Step-by-Step Example)**

1. A **developer** writes code locally (e.g., an addition feature in a calculator app).
    
2. After testing locally, they **push the code** to a Git repository.
    
3. A **CI/CD tool** (e.g., Jenkins, GitHub Actions, GitLab CI) detects the change.
    
4. The tool triggers a **pipeline** — a series of automated steps:
    
    * Build the code
        
    * Run tests (unit, functional)
        
    * Perform code analysis
        
    * Generate reports
        
    * Deploy to servers (Dev → Staging → Production)
        

---

## 🧰 **Common CI/CD Tools**

| Category | Examples |
| --- | --- |
| Source Control | GitHub, GitLab, Bitbucket |
| CI/CD Orchestration | Jenkins, GitHub Actions, GitLab CI, CircleCI, Travis CI |
| Build Tools | Maven, Gradle |
| Testing Tools | JUnit, Selenium |
| Code Analysis | SonarQube |
| Deployment | Docker, Kubernetes, AWS, Azure, GCP |

---

## 🏗️ **Example: Jenkins (Legacy CI/CD Tool)**

### Jenkins Workflow:

1. Developer commits code → GitHub repository.
    
2. Jenkins detects the change (via webhook).
    
3. Jenkins runs a **Pipeline** consisting of:
    
    * Build (Maven)
        
    * Unit Tests (JUnit)
        
    * Code Quality (SonarQube)
        
    * Reporting (Allure)
        
    * Deployment (to Kubernetes, EC2, etc.)
        

### Jenkins as an **Orchestrator**

* Jenkins integrates all tools together.
    
* Pipelines can be written in Groovy (Declarative or Scripted Pipeline syntax).
    
* Used widely for years, but **has scaling limitations**.
    

---

## 🧭 **Environments in CI/CD**

| Environment | Purpose |
| --- | --- |
| **Dev** | For developers to test early builds |
| **Staging** | Replica of production; QA testing |
| **Production** | Final live environment for customers |

Pipelines promote code automatically:

```plaintext
Dev → Staging → Production
```

Using **manual approvals** or **automated policies**.

---

## ⚠️ **Limitations of Jenkins (Legacy Approach)**

* Requires **manual setup** of master and multiple worker nodes.
    
* Scaling to handle **hundreds of microservices** becomes complex and expensive.
    
* Continuous usage of **compute resources (RAM/CPU)**, even when idle.
    
* Difficult to achieve **zero-resource usage** when pipelines are inactive.
    

---

## 🌐 **Modern CI/CD Solutions**

Modern applications (like **Kubernetes**, **Amazon**, **Flipkart**) handle **hundreds or thousands of microservices** — they need **scalable, on-demand CI/CD systems**.

### Example: **Kubernetes Project on GitHub**

* Uses **GitHub Actions** for automation.
    
* When a developer makes a **pull request**, a workflow runs automatically.
    
* **Containers (pods)** are created temporarily to execute build/test steps.
    
* After completion, the containers **auto-delete** → **no wasted resources**.
    

✅ **Benefits:**

* Zero compute waste when idle
    
* Shared runners for multiple projects
    
* Fast scaling (pods start instantly)
    
* Event-driven automation (no manual trigger)
    

---

## ⚡ **Modern CI/CD Tools**

| Tool | Platform | Key Features |
| --- | --- | --- |
| **GitHub Actions** | GitHub | Event-driven, scalable, integrated with repositories |
| **GitLab CI** | GitLab | Built-in pipelines, YAML-based |
| **CircleCI** | Cloud | Simple config, fast builds |
| **Travis CI** | Cloud | Great for open-source projects |
| **Argo CD / Tekton** | Kubernetes-native | Cloud-native CI/CD pipelines |

---

## 🔁 **Jenkins vs GitHub Actions — Quick Comparison**

| Feature | Jenkins | GitHub Actions |
| --- | --- | --- |
| Type | Standalone Orchestrator | Cloud/Repo-integrated |
| Setup | Manual installation & configuration | Built into GitHub |
| Scalability | Manual node scaling | Auto containerized runners |
| Cost | Compute always running | Pay-per-use (zero idle cost) |
| Triggers | Webhooks | Event-driven natively |
| Ideal For | On-prem & traditional projects | Cloud-native, modern apps |

---

## 🧩 **Summary**

| Concept | Description |
| --- | --- |
| **CI/CD** | Automates integration, testing, and deployment |
| **Continuous Integration** | Merges code frequently, runs builds/tests automatically |
| **Continuous Delivery** | Deploys to environments automatically after testing |
| **Tools** | Jenkins, GitHub Actions, GitLab CI, CircleCI |
| **Modern Trend** | Cloud-native, event-driven, container-based pipelines |
| **Goal** | Faster releases, fewer errors, and efficient resource use |

---

✅ **In short:**

> CI/CD automates how your code goes from a developer’s laptop → through build, test, and security checks → to production servers — ensuring every release is fast, reliable, and safe.