Module 11 Project B: CI/CD with Git

In modern software engineering, you don't manually drag files to a server. Instead, you use a CI/CD Pipeline (Continuous Integration / Continuous Deployment).

Git is the trigger for this entire process. In this lesson, we learn how your local commits become high-speed production deployments.

---

1. What is CI/CD?

Continuous Integration (CI)

Every time you push a branch, a server in the cloud (like GitHub Actions, GitLab CI, or CircleCI) clones your code and runs your tests. If the tests fail, the "Build" fails, and you are notified immediately.

Continuous Deployment (CD)

Once the code is merged into main and passes all tests, the same server automatically sends the updated code to your production environment (AWS, Vercel, Heroku, etc.).

---

2. The Project Workflow

In this project, we trace the lifecycle of a code change through an automated pipeline:

Step 1: The Local Fix

You write code and run your local Git hooks (from Module 10).

git commit -m "Fix: Optimized database query"
git push origin feature/optimization

Step 2: The CI Trigger

The remote server (GitHub) sees your push. It looks for a configuration file in your repo (like .github/workflows/main.yml). It starts a "Runner" (a virtual machine) that:

1. Clones your repo.
2. Installs dependencies.
3. Runs npm test.

Step 3: The Deployment

The PR is merged. The pipeline runs one final time on the main branch. This time, after the tests pass, it runs a deployment script:

npm run build
aws s3 sync ./dist s3://my-app-bucket

graph TD
    Push["git push"] --> GitHub["GitHub Actions"]
    GitHub --> Test["Run Tests"]
    Test -- "Pass" --> Merge["Allow Merge to main"]
    Merge --> CD["Deploy to Production"]
    Test -- "Fail" --> Reject["Block PR / Notify Dev"]

---

3. The Power of "Tags" for Releases

Many professional pipelines use Git Tags (from Module 6) to trigger official production releases.

• Push to main -> Deploys to "Staging" (for testing).
• Create a tag v1.2.0 -> Deploys to "Production" (for users).

---

Project Exercise (Conceptual)

Goal: Design a Pipeline.

1. Imagine you are building a React application.
2. List 3 things you want Git to do automatically every time you push a branch. (e.g., Linting, Unit Tests, Type Checking).
3. If a test fails, should the developer be allowed to merge the PR? (No!).
4. How would you use a "Staging" branch to test your code before it goes to real users?

Observation: You'll realize that Git isn't just a place to store code; it’s the control center for your entire technical operations.

---

Summary

In this project, we established:

• Git events (push, merge, tag) act as triggers for automated automation.
• CI/CD reduces human error and ensures only high-quality code reaches users.
• Managing your Git history is essential for keeping your automation pipeline predictable and fast.

Next Project: What happens when things go wrong? Welcome to Project C: Troubleshooting a 'Broken' Repository.