CI/CD Pipeline — ส่ง Code ขึ้น Production แบบอัตโนมัติCI/CD Pipeline — Shipping Code to Production Automatically

# ตัวอย่าง GitHub Actions trigger
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run build

- run: npm test          # Unit tests
- run: npm run test:e2e  # E2E tests
- run: npm run lint      # Code style check
- run: npm audit         # Security check

name: CI/CD Pipeline

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

jobs:
  # ===== CI =====
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Build
        run: npm run build

      - name: Unit Tests
        run: npm test -- --coverage

      - name: Upload coverage
        uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: coverage/

  # ===== CD =====
  deploy:
    needs: build-and-test    # รอ CI ผ่านก่อน
    if: github.ref == 'refs/heads/main'  # deploy เฉพาะ main
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy to production
        run: |
          echo "Deploying to production..."
          # คำสั่ง deploy จริงๆ เช่น:
          # ssh user@server 'cd /app && git pull && npm ci && pm2 restart all'
          # หรือ docker push + kubectl apply

# ❌ อย่าทำ
- run: mysql -u root -p mypassword123

# ✅ ทำแบบนี้
- run: mysql -u $DB_USER -p $DB_PASSWORD
  env:
    DB_USER: ${{ secrets.DB_USER }}
    DB_PASSWORD: ${{ secrets.DB_PASSWORD }}

In the previous post we talked about Git Branching — how to cut a branch, how to merge it back, and what branching strategies are out there. But once the merge is done... what happens next?

If you have to build it yourself, test it yourself and deploy it yourself every time new code lands, the work is exhausting and easy to get wrong. The bigger the team and the more often you deploy, the messier it gets.

This is where the CI/CD Pipeline comes in — a system that handles everything automatically, from the moment code enters the repo to the moment it goes live on production.

---

What is CI/CD?

CI/CD is short for two ideas that reinforce each other — CI lets a team integrate code more often without stepping on each other's toes, while CD gets tested code into users' hands as fast as possible. Together they turn deployment from "a big scary event" into "an ordinary routine":

CI — Continuous Integration

"Merge often, test automatically every time"

The principle is that every developer should merge into the main branch at least once a day — the more often you integrate, the smaller each conflict is and the easier it is to fix. Let a branch drift for a week and then merge it all at once, and the conflict will be enormous. Every time you push, the system will:

1. Pull the code and build it automatically
2. Run the whole test suite
3. Report the result: ✅ passed or ❌ failed

Without CI → a developer pushes code → nobody finds out it is broken until the real deploy 💀

CD — Continuous Delivery / Continuous Deployment

Continuous Delivery: code that has passed its tests is ready to deploy immediately, but someone still has to press the deploy button. This suits teams that need a compliance review or want manual approval before a release.

Continuous Deployment: code that has passed its tests goes straight to production automatically — nobody presses anything, and every commit that clears the pipeline reaches users at once! Netflix, Facebook and Google work this way, but it takes very high test coverage before you can be that confident.

Both have their merits — Delivery is safer (there is a human gate) while Deployment is faster (a very short feedback loop). Choose according to the risk tolerance of your team and your business.

---

What is a Pipeline?

A pipeline is a sequence of steps that run automatically one after another, from the moment code enters the repo to the moment it is deployed to production. Picture a car factory: raw materials arrive → parts are assembled → quality is inspected → paint is applied → the car is delivered. If a part fails inspection, the line stops immediately — no defective goods reach the customer. A CI/CD pipeline does exactly the same:

If any step fails → the pipeline stops immediately → the developer is notified → no broken code slips through to production.

---

What Does Each Stage Do?

A typical pipeline has 5 stages — each with its own job, and each a "quality gate" that must be cleared before the next one begins. The more gates a pipeline has, the more confident you can be that the code reaching production is sound:

1. Source — Taking the Code In

The pipeline starts when a trigger event fires — usually a git push, but you can configure several kinds. The more that triggers automatically, the less a developer has to remember about "what to do before deploying":

• Pushing code to a branch
• Opening a Pull Request
• Merging into main
• A schedule (cron)

# GitHub Actions trigger example
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

2. Build — Assembling the Project

The Build stage is where you compile the code, install dependencies and produce artifacts (a Docker image, a JAR file, a JS bundle) that are ready to deploy. If the build fails, the code has a fundamental problem (a syntax error, a missing dependency) that must be fixed first. Here is what typically happens:

• npm install → install packages
• npm run build → compile TypeScript, bundle React, etc.
• Build the Docker image
• Produce the artifact (.jar, .whl, binary)

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run build

When a build fails, it is usually because of:

• A syntax error
• A missing dependency
• A version conflict

3. Test — Verification

The most important stage of all — without tests, deploying is no different from rolling the dice 🎲. Automated tests run on every push without leaning on any developer's "diligence". If a test fails → the pipeline stops → the code never reaches production.

The levels of testing:

Level	What it tests	Speed	Example
Unit Test	A single function	Very fast (seconds)	calculate(2,3) must return 5
Integration Test	Several parts working together	Moderate	API + Database
E2E Test	The whole system from the user's side	Slow (minutes)	Click Login → see the Dashboard

- run: npm test          # Unit tests
- run: npm run test:e2e  # E2E tests
- run: npm run lint      # Code style check
- run: npm audit         # Security check

Testing Pyramid:

4. Stage — A Preview Before the Real Deploy

Staging is an environment identical to production in every respect (same config, same data structure, same infrastructure) but not yet the real thing — a dress rehearsal before opening night. It catches the problems automated tests cannot, such as performance issues, UI bugs and integration problems:

What it gives you:

• Testing against realistic data
• A place for the QA team or the PM to review
• Catching problems that automated tests miss

5. Deploy — Going to Production

The final stage — the code reaches real users at last! There are several ways to deploy, each with its own trade-off between risk, speed and complexity. Which one fits depends on your business requirements:

The popular deployment strategies:

Rolling Update

Blue-Green Deployment

Canary Deployment

---

A Real Pipeline with GitHub Actions

Let us look at a real pipeline built on GitHub Actions — the CI/CD tool built into GitHub, free of charge. Create one YAML file in .github/workflows/ and you have an automated pipeline. The example below covers build, test and deploy:

name: CI/CD Pipeline

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

jobs:
  # ===== CI =====
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Build
        run: npm run build

      - name: Unit Tests
        run: npm test -- --coverage

      - name: Upload coverage
        uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: coverage/

  # ===== CD =====
  deploy:
    needs: build-and-test    # wait for CI to pass first
    if: github.ref == 'refs/heads/main'  # deploy main only
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy to production
        run: |
          echo "Deploying to production..."
          # the real deploy command, for example:
          # ssh user@server 'cd /app && git pull && npm ci && pm2 restart all'
          # or docker push + kubectl apply

---

Popular CI/CD Tools

There are many CI/CD tools, and each is strong in a different direction — GitHub Actions (simple, free for public repos), GitLab CI (everything in one place), Jenkins (the most flexible, but you maintain it yourself), CircleCI (fast, cloud-native). Choose to fit your team and your ecosystem:

Tool	Type	Strength	Best for
GitHub Actions	Cloud	Easy to use, free for public repos	Projects already on GitHub
GitLab CI/CD	Cloud/Self-hosted	Strong pipelines, built-in container registry	Organizations on GitLab
Jenkins	Self-hosted	Huge plugin ecosystem, highly customizable	Large organizations
CircleCI	Cloud	Fast, simple config	Startups / small teams
ArgoCD	Self-hosted	GitOps for Kubernetes	Teams running K8s

---

Best Practices

Having a good pipeline is not enough — you have to look after it, the way a car needs regular servicing. Let the pipeline get slow, let the tests go thin, let secrets be hardcoded, and eventually the pipeline becomes a burden instead of a help:

1. Keep Pipeline Fast ⚡

If the pipeline is too slow, developers will not want to wait → they start skipping CI → they gradually stop using it → and the whole benefit is lost. Make it fast with parallel jobs, cached dependencies, running only the relevant tests, and incremental builds.

Targets:

• Build + Unit Test: < 5 minutes
• The whole pipeline: < 15 minutes

2. Test Thoroughly 🧪

Low test coverage gives you a pipeline that offers false confidence — the code clears the pipeline and then breaks in production. Aim for 80%+ coverage and write your tests along the Testing Pyramid:

• Aim for code coverage > 80%
• Have unit tests for the business logic that matters
• Do not forget edge cases and error handling

3. Fail Fast, Fix Fast 🔴

Order the pipeline from fast to slow (lint → unit test → integration → E2E) so that failures surface as early as possible. A lint failure after 10 seconds beats waiting 15 minutes for an E2E test to fail. And once something fails, fix it immediately — never leave the pipeline sitting red:

• If the pipeline fails → fix it first, before anything else
• Never leave the pipeline red → the team gets used to "red is just how it looks"

4. Use Environment Variables for Secrets 🔐

Never hardcode passwords, API keys or tokens in your code or your pipeline YAML — use GitHub Secrets, Vault, or environment variables instead. A secret that reaches Git stays in the history forever:

# ❌ Don't
- run: mysql -u root -p mypassword123

# ✅ Do this
- run: mysql -u $DB_USER -p $DB_PASSWORD
  env:
    DB_USER: ${{ secrets.DB_USER }}
    DB_PASSWORD: ${{ secrets.DB_PASSWORD }}

5. Keep the Pipeline Identical Across Environments 🔄

Development → Staging → Production should all run the same pipeline, differing only in config (database URL, API keys, feature flags). If each environment uses a different pipeline, you will meet the classic "it passed in staging but production broke" — use Docker plus environment variables so that the environments differ only in configuration, not in infrastructure.

---

Compared: Before vs After CI/CD

The table below sets the two side by side — manual deployment against CI/CD — and shows how enormously CI/CD cuts risk, time and human error:

	Before CI/CD	After CI/CD
Build	By hand, and "oops, forgot to build"	Automatic on every push
Test	"I'll test it later"	Tested every time; a failure stops everything
Deploy	SSH into the server and drag files across by hand	One button, or fully automatic
When bugs turn up	When a user phones in to yell at you	When the pipeline fails (before the deploy)
Confidence	"I hope it doesn't break" 🤞	"The tests passed — I'm confident" ✅
Deploy frequency	Once a month (too afraid it will break)	Several times a day

---

Summary

• CI (Continuous Integration) = automatic build + test on every code push
• CD (Continuous Delivery/Deployment) = automatic (or semi-automatic) deployment to production
• Pipeline = the sequence of stages: Source → Build → Test → Stage → Deploy
• If any stage fails → the pipeline stops → no broken code slips through to production
• Choose the tool that fits your team and project: GitHub Actions is a good place to start
• A fast pipeline + thorough tests + fixing fast = good DevOps

In the next post we will talk about Docker — the tool that turned "it works on my machine" into a thing of the past! 🐳🐕