Simple CI/CD Pipeline Implementation

The idea for this article came to me while I was fixing a UI bug. During a deployment, I accidentally made a wrong commit without waiting for the prior changes to finish. I believed the CI/CD pipeline in Vercel would catch this error and prevent the deployment, but it passed the check and ended up breaking the site.

This experience motivated me to create my own CI/CD pipeline with the help of GitHub Actions.

My Objectives

I aim to implement a CI/CD pipeline for my personal website, which has its data stored in a GitHub branch and is linked to Vercel. The wrong commit that caused downtime earlier emphasized the need for a pipeline that catches errors before they reach production.

For this CI/CD implementation, I plan to primarily build my Astro project and check dependencies. Other types of tests, such as end-to-end testing and performance checks, are on my roadmap for future implementation.

Understanding CI/CD

Continuous Integration (CI) and Continuous Deployment (CD) are development practices that allow teams to deliver software changes more frequently and reliably. Implementing a CI/CD pipeline can drastically reduce the risk of introducing bugs into production, enabling a smoother workflow.

How to Implement a CI/CD Pipeline

To implement a CI/CD pipeline for your personal website using GitHub and Vercel, follow these steps to ensure code quality and reliability before changes are deployed.

Set Up a CI Tool (GitHub Actions)

1. Create a GitHub Actions Workflow:
   • In your repository, create a directory named .github/workflows.
   • Inside this directory, create a file called ci.yml (or any name you prefer).

.github/
└── workflows/
    └── ci.yml

2. Define Your CI Workflow YAML:

Here’s a sample configuration that runs tests and builds your project:

name: CI

on:
  push:
    branches:
      - '*' 
  pull_request:
    branches:
      - 'main'  

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Install dependencies
        run: npm install  

      - name: Run tests
        run: npm test  # Adjust the command according to your test setup

      - name: Build
        run: npm run build 

Setting Up Git Branch Protection Rules in GitHub

1. Protect Your Main Branch:
   • Go to your GitHub repository.
   • Navigate to Settings > Branches.
   • Under “Branch protection rules,” click Add rule.
   • Enter the branch name (e.g., main or master).
   • Check Require pull request reviews before merging to prevent erroneous commits.

Flow of a CI/CD Pipeline Example

The UML sequence diagram visually represents the interactions and flow of processes in a CI/CD pipeline.

Diagram Components

1. Actors/Participants:
   • Developer: The individual who writes and commits code changes.
   • Version Control (VC): The system (like GitHub) where code is stored and managed.
   • CI System (CI): The Continuous Integration tool (like GitHub Actions) responsible for automating build and test processes.
   • Staging: An intermediate environment where code is deployed for testing before reaching production.
   • Production: The live environment where the application is made available to end-users.

Step-by-Step Explanation

The CI/CD pipeline is a streamlined process designed to automate the integration and deployment of code changes. It begins when a developer commits code to a Version Control System (VCS), which then triggers the CI (Continuous Integration) system to build and test the application.

If the tests pass, the application is automatically deployed to the Production environment, ensuring that only verified code goes live.

In cases where tests fail, the developer is promptly notified, allowing for quick fixes and ensuring high-quality software delivery.

1. Commit Code: The Developer commits code changes to the Version Control system (e.g., GitHub).
2. Trigger CI Process: The Version Control system detects the new commit and initiates the CI process.
3. Run Tests: Automated tests defined in the configuration are executed to ensure code quality.
4. Build Application: If tests pass, the CI system builds the application.
5. Notify Success/Failure: After building, the CI system notifies the Version Control system of success or failure.
6. Deploy to Staging: If successful, the application is deployed to a staging environment for further testing.
7. Confirmation of Deployment: The staging environment confirms the deployment to the CI system.
8. Deploy to Production: After staging verification, the application is deployed to the production environment.
9. Notify Test Failure: If tests fail at any point, the CI system alerts the developer to address issues.

Conclusion

By implementing this CI/CD pipeline, you can significantly reduce the risk of breaking changes making it to production, as every change undergoes proper testing beforehand.

In the future, I plan to add end-to-end tests that will run during pull requests to the main branch, further enhancing the robustness of the deployment process. :D

Additional Resources

1. GitHub Actions Documentation
2. Vercel Documentation
3. GitHub Actions Marketplace for reusable actions.

If you have any specific questions or need assistance with configurations, feel free to ask!