Beginner steps into CI/CD

Image by freepik

Most people me included, just use Github as kind of like an online store for code. But this application has more to it than meets the eye.

What is CI/CD

• Continuous Integration (CI): Is the of automation of the process of merging code changes. It's typically trigged on every push or pull request, running automated tests and builds to detect bugs early.
• Continuous Deployment/Delivery (CD): Automatically prepares or pushes tested code to a production environment once the CI checks pass

These series of events can help cut down on the time and effort spent on the manual tasks. They can be summarized in the image below.

How you can do it

Step 1: Create your workflows

In CI, there's four key concepts one should know i.e. trigger, workflow, job and step.

1. A trigger is what will cause the CI process to start
2. Workflow is the automation file(.yml)
3. Job is a group of steps on one machine
4. Step is a single command or action

To begin we first create a .github directory. Inside we create a workflows folder. Inside we create out ci.yml file. The structure should look like this:

Step 2: Define triggers

For this instance we want the process to start when someone performs a pr but you can set it to push as well

name: CI Pipeline

# TRIGGERS
on:
    push:
        branches: [main]
    pull_request:
        branches: [main]

Step 3: Define Jobs

Jobs work in Isolated Environments. Every job runs inside its own fresh virtual machine (called a runner), such as Ubuntu, Windows, or macOS.
If your workflow has multiple jobs, GitHub runs them at the same time to save time.
A job groups together a series of sequential tasks (steps) that handle the actual work.

# JOBS
jobs:
    test:
        runs-on: ubuntu-latest # The machine to use

        steps:
            ...

Step 4: Define Steps

Steps are the individual, sequential tasks that execute inside a single job. They run one after another, in the exact order they are listed in the YAML file.
All steps in a single job run on the same virtual machine instance. If Step 1 creates a file or installs a package, Step 2 can use it.
In case any step fails (returns an error code), the job stops immediately, and the remaining steps are skipped.

steps:
      # Step 1: Get the code
      - name: Checkout Github code
        uses: actions/checkout@v4

      # Step 2: Set up Node.js
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
        ...

That there was a simple CI pipeline now of to the CD.

Step 5: Deployment cycle

Similar to the CI structure, the CD is also made in the same structure but the steps differ.
They go from tests, if they pass then to the build. Upon successful build the project is then staged and finally pushed to production.

name: Deploy

on:
  push:
    branches: [main]

# Prevent multiple deployments at once
concurrency:
  group: deployment
  cancel-in-progress: false

jobs:
  # First: Run tests
  test:
    name: Run Tests
    ...

  # Second: Build the project
  build:
    name: Build
    runs-on: ubuntu-latest
    needs: test
    steps:
      ...

  # Third: Deploy to staging
  deploy-staging:
    name: Deploy to Staging
    runs-on: ubuntu-latest
    needs: build
    environment: staging        # Requires environment approval (optional)

    steps:
      ...

  # Fourth: Deploy to production (manual approval)
  deploy-production:
    name: Deploy to Production
    runs-on: ubuntu-latest
    needs: deploy-staging
    environment: production     # Can require manual approval in GitHub settings

    steps:
      ...

But this is just an example, to better understand see the video here or see this github repo. It will provide a wider view and context

Why do this

Short answer: Speed. Organizations that have mastered the CI/CD, build and deploy products faster than others. Since products are always being rated and feedback being provided. Developers commit smaller changes more often, hence keeping up with customer demands.
With ongoing feedback, developers are constantly making small changes.
Automated continuous testing ensures that the codebases remain stable and ready for deployment at all times. Since the manual tasks are taken care of with this automation, developers can focus on creation, innovation, and other important tasks

Conclusion

I'm also still learning about this concept and implementing it into my own workflow. It's a core skill that I believe every developer should enforce in their workflows especially junior developers. It's a major time saver and also ensures you always have working code ready for production.

Comments

[VICTOR KIMUTAI]

Great breakdown! GitHub Actions really transforms GitHub from a simple repository into a powerful engine. What was the hardest part for you to grasp when you first started setting up the YAML files?