Posted inDevelopment

Hướng dẫn CI/CD với GitHub Actions từ đầu: Tự động hóa cho Dev sướng hơn

Development tutorial - IT technology blog
Development tutorial - IT technology blog

Nỗi đau “deploy tay” và câu nói “Ơ, trên máy em chạy mà?”

Anh em dev chắc không lạ gì cảnh này: code xong một feature tâm đắc, test kỹ càng trên máy mình rồi gõ lệnh git push đầy tự tin. Vài phút sau, “ting ting” một loạt tin nhắn từ team test hoặc từ sếp: “Em ơi app sập rồi”, “Tính năng ABC không chạy”,… Cảm giác lúc đó thật sự khó tả.

Mình còn nhớ như in dự án web app đầu tiên mình tham gia. Team có 5 dev, code merge liên tục vào nhánh develop. Mỗi lần release cuối tuần là một lần “nín thở”. Người được giao nhiệm vụ deploy phải lên server, git pull, chạy một loạt lệnh build, restart service. Chỉ cần sai một biến môi trường là cả hệ thống có thể “toang”. Thời gian deploy mất 30-45 phút căng thẳng, và quan trọng là mình ngủ không ngon nổi.

Đó chính là cái giá phải trả cho việc thiếu tự động hóa: tốn thời gian, bào mòn tinh thần và đầy rẫy rủi ro từ những sai sót không đáng có của con người.

Tại sao lại khổ vậy? Phân tích gốc rễ vấn đề

Nhìn sâu hơn, những “nỗi đau” trên thường xuất phát từ ba nguyên nhân chính:

  • Quy trình rời rạc, không nhất quán: Mỗi dev có một thói quen khác nhau. Người thì chạy test trước khi push, người thì không. Người dùng npm, người chuộng yarn, dẫn đến file lock (package-lock.json vs yarn.lock) không đồng bộ. Khi không có chuẩn chung, xung đột và lỗi là điều khó tránh.
  • Thiếu kiểm thử tự động: Việc chạy test phụ thuộc vào ý thức của mỗi người. Khi dự án gấp rút, bước này thường bị bỏ qua. Kết quả là code lỗi vẫn được merge thẳng vào nhánh chính. Việc phát hiện và sửa lỗi ở giai đoạn sau sẽ tốn kém hơn rất nhiều.
  • Sự khác biệt môi trường (environment drift): Câu nói “Trên máy em chạy mà” là hệ quả trực tiếp của việc này. Môi trường local của dev (ví dụ: MacOS với Node v18) có thể khác xa với môi trường production (ví dụ: Ubuntu với Node v16). Sự khác biệt về phiên bản thư viện, biến môi trường, hay cấu hình hệ điều hành là nguồn gốc của vô số lỗi “trời ơi đất hỡi”.

Các “chiêu” thường dùng (và tại sao chúng chưa đủ tốt)

Để đối phó với tình trạng trên, các team thường áp dụng một vài cách:

Cách 1: Cử ra một “chiến binh” deploy
Một người (thường là leader hoặc devops) sẽ chịu trách nhiệm cho mọi lần deploy. Cách này đảm bảo tính nhất quán hơn một chút, nhưng lại biến người đó thành “bus factor” số một. Mọi thứ ùn ứ nếu họ bận hoặc nghỉ phép. Rủi ro sai sót con người vẫn còn nguyên.

Cách 2: Tự viết script deploy (ví dụ `deploy.sh`)
Đây là một bước tiến bộ hơn. Chúng ta tạo một file script chứa các lệnh cần thiết để deploy. Khi cần, chỉ việc chạy file đó là xong.

#!/bin/bash

echo "🚀 Starting deployment..."

# Pull a new version
git pull origin main

# Install dependencies
npm install

# Build project
npm run build

# Restart server with pm2
pm2 restart my-app

echo "✅ Deployment finished!"

Tiến bộ hơn, nhưng vẫn còn điểm yếu. Ai sẽ là người chạy script này và chạy khi nào? Làm sao quản lý an toàn các API key, password? Và làm sao cả team cùng xem được lịch sử deploy?

Giải pháp tối thượng: CI/CD với GitHub Actions

Đây chính là lúc CI/CD tỏa sáng. Nó giải quyết triệt để các vấn đề trên bằng cách tự động hóa toàn bộ quy trình, tạo ra một luồng làm việc nhất quán và an toàn.

CI/CD là gì? “Giải ngố” nhanh

  • CI (Continuous Integration – Tích hợp liên tục): Tưởng tượng mỗi khi bạn push code, một con bot sẽ tự động lấy code về, build và chạy toàn bộ test. Mục tiêu là phát hiện lỗi ngay lập tức, đảm bảo code mới không phá hỏng những gì đang chạy tốt.
  • CD (Continuous Deployment/Delivery – Triển khai/Phân phối liên tục): Sau khi CI báo thành công (code đã pass hết test), con bot sẽ tự động triển khai code lên môi trường chỉ định. Đó có thể là môi trường Staging để team test xem lại, hoặc là Production cho người dùng cuối sử dụng.

Và GitHub Actions chính là công cụ CI/CD “cây nhà lá vườn” của GitHub, mạnh mẽ, miễn phí cho các dự án public và được tích hợp ngay trong giao diện quen thuộc của bạn.

Thực hành: Xây dựng workflow CI/CD đầu tiên cho dự án Node.js

Lý thuyết đủ rồi, bắt tay vào việc thôi. Mình sẽ hướng dẫn bạn tạo một workflow CI đơn giản: mỗi khi có code mới được push lên nhánh `main`, GitHub Actions sẽ tự động cài đặt môi trường, cài dependencies và chạy unit test.

Bước 1: Tạo thư mục và file workflow

Trong thư mục gốc của dự án, hãy tạo một cấu trúc thư mục như sau: .github/workflows/. Bên trong thư mục `workflows`, tạo một file tên là ci.yml.

Bước 2: Viết kịch bản tự động hóa bằng YAML

Mở file ci.yml và dán đoạn mã sau vào:

name: Node.js CI

# Bộ kích hoạt (trigger): Chạy khi có push hoặc pull request vào nhánh "main"
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build_and_test:
    # Chạy trên một máy ảo Ubuntu phiên bản mới nhất do GitHub cung cấp
    runs-on: ubuntu-latest

    strategy:
      matrix:
        # Vũ khí cực mạnh: Chạy test song song trên nhiều phiên bản Node.js
        node-version: [16.x, 18.x, 20.x]

    steps:
    # Step 1: Lấy code từ repository về máy ảo (runner)
    - name: Checkout repository
      uses: actions/checkout@v4

    # Step 2: Cài đặt phiên bản Node.js tương ứng từ matrix
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
        # Mẹo hay: Bật cache để lần chạy sau cài dependencies nhanh hơn
        cache: 'npm'

    # Step 3: Cài đặt các thư viện (dùng npm ci cho an toàn và tốc độ)
    - name: Install dependencies
      run: npm ci

    # Step 4: Chạy lệnh build (nếu có trong package.json)
    - name: Build project
      run: npm run build --if-present

    # Step 5: Chạy unit test
    - name: Run tests
      run: npm test

Bước 3: Phân tích kịch bản

  • name: Tên của workflow, sẽ hiển thị trên tab Actions của GitHub.
  • on: Bộ kích hoạt (trigger). Workflow sẽ chạy khi có lệnh push hoặc có pull_request được tạo/cập nhật vào nhánh main.
  • jobs: Nơi chứa các công việc cần thực hiện. Workflow có thể có một hoặc nhiều job.
  • build_and_test: Tên job của chúng ta.
  • runs-on: Chỉ định hệ điều hành cho máy ảo chạy job. ubuntu-latest là lựa chọn phổ biến nhất.
  • strategy.matrix: Vũ khí cực mạnh để test trên nhiều môi trường. Job này sẽ được nhân bản và chạy song song trên 3 phiên bản Node.js: 16.x, 18.x, và 20.x, đảm bảo code của bạn tương thích rộng.
  • steps: Các bước tuần tự mà job sẽ thực hiện.
  • uses: Tận dụng ‘action’ có sẵn từ cộng đồng để không phải ‘phát minh lại bánh xe’. actions/checkout@v4 và actions/setup-node@v4 là hai ‘action’ phổ biến nhất, được chính GitHub bảo trì.
  • run: Thực thi một lệnh command-line trên máy ảo.

Bây giờ, mỗi khi bạn push code, hãy vào tab “Actions” trong repository GitHub. Bạn sẽ thấy workflow của mình đang chạy. Nếu có lỗi ở bước nào (ví dụ test fail), workflow sẽ báo đỏ và bạn sẽ nhận được email thông báo ngay lập tức.

Mẹo và Best Practices từ kinh nghiệm “đau thương”

  1. Bảo mật tuyệt đối API keys, tokens: Đừng bao giờ hardcode các thông tin nhạy cảm. Đây là lỗi bảo mật nghiêm trọng. Hãy dùng GitHub Secrets. Vào Settings > Secrets and variables > Actions, tạo một secret mới (ví dụ: DATABASE_URL). Trong workflow, bạn sẽ gọi nó ra an toàn qua env: DATABASE_URL: ${{ secrets.DATABASE_URL }}`. Dữ liệu này được mã hóa và không bao giờ lộ ra trong logs.
  2. Dùng npm ci thay vì npm install: npm ci cài đặt chính xác các phiên bản trong file package-lock.json, đảm bảo môi trường CI giống hệt môi trường của dev. Nó cũng nhanh hơn và an toàn hơn cho quy trình tự động.
  3. Tận dụng cache để tăng tốc: Như trong ví dụ, dùng with: cache: 'npm' giúp lưu lại các thư viện đã tải về (thư mục node_modules). Lần chạy sau, nếu file package-lock.json không thay đổi, GitHub Actions sẽ phục hồi cache thay vì tải lại từ đầu. Với các dự án lớn, bước này có thể tiết kiệm từ 30 giây đến vài phút.
  4. Tách bạch CI và CD: Dùng các job riêng biệt cho từng giai đoạn (ví dụ: test, build, deploy). Dùng từ khóa needs: [test, build] để đảm bảo job deploy chỉ được kích hoạt khi test và build đã chạy thành công 100%.

Quay lại câu chuyện dự án với 5 developer, sau khi áp dụng CI/CD, thời gian deploy giảm từ 30 phút căng thẳng xuống còn khoảng 5 phút hoàn toàn tự động. Quan trọng hơn, cả team đã tự tin hơn rất nhiều, không còn sợ việc push code sẽ làm sập hệ thống. Chỉ với một file YAML đơn giản, bạn không chỉ tiết kiệm thời gian mà còn xây dựng được một nền tảng văn hóa DevOps vững chắc: tự động, an toàn và minh bạch.

Share:
Tags: