Series Chinh phục Heroku | Bài 5: Heroku Pipelines & Review Apps - Đưa CI/CD lên tầm nghệ thuật

1. Triết lý "Slug Promotion" của Heroku Pipelines

Heroku Pipelines chia vòng đời ứng dụng của bạn thành 3 cột rõ rệt trên giao diện:

1. Review Apps: Các môi trường tạm thời sinh ra theo từng Pull Request.
2. Staging: Môi trường kiểm thử chính (giống hệt Production).
3. Production: Môi trường thật đang chạy hệ thống AFC.

Điều kỳ diệu của "Promote": Khi bạn kiểm thử xong trên Staging và muốn đưa lên Production, bạn không cần chạy lại lệnh git push hay build lại code. Heroku có một nút bấm tên là Promote. Nó sẽ bê nguyên "cục code đã biên dịch thành công" (gọi là Slug) từ Staging ném thẳng sang Production. Điều này đảm bảo 100% không bao giờ có chuyện "Môi trường test chạy ngon nhưng build trên Production lại tạch do lỗi thư viện".

2. Trái tim của Review Apps: File app.json

Để Heroku biết cách tự động tạo ra một môi trường hoàn chỉnh (kèm Database, Redis) khi có Pull Request mới, dự án của bạn cần một "bản vẽ kiến trúc". Đó là file app.json.

Hãy tạo file app.json tại thư mục gốc của dự án:

{
  "name": "Hệ thống AFC Backend",
  "description": "API xử lý giao dịch vé tàu điện",
  "scripts": {
    "postdeploy": "npx sequelize-cli db:migrate" 
  },
  "env": {
    "NODE_ENV": {
      "value": "development"
    },
    "JWT_SECRET": {
      "required": true
    }
  },
  "addons": [
    "heroku-postgresql:mini",
    "heroku-redis:mini"
  ]
}

Giải thích: Khi một Pull Request mở ra, Heroku đọc file này, tự động gắn Database Postgres, gắn Redis, yêu cầu điền JWT_SECRET, và chạy lệnh db:migrate để tạo các bảng (tables) tự động.

3. Quy trình thiết lập trên Dashboard

(Lưu ý: Tính năng Review Apps chính chủ của Heroku tích hợp sâu và mượt mà nhất với GitHub. Nếu bạn đang dùng Bitbucket, luồng Pipelines ở Bài 3 của series Bitbucket sẽ là lựa chọn tối ưu hơn, nhưng bản chất kiến trúc Promote của Heroku vẫn giữ nguyên giá trị).

1. Khởi tạo Pipeline

Đăng nhập vào Heroku Dashboard, chọn New -> Create new pipeline. Đặt tên cho Pipeline (ví dụ: afc-system-pipeline).

2. Kết nối với Repository

Trong giao diện tạo Pipeline, chọn nền tảng chứa code của bạn (ví dụ: GitHub) và tìm kiếm tên repository chứa dự án Node.js. Nhấn Connect.

3. Kích hoạt Review Apps

Tại cột Review Apps ngoài cùng bên trái, nhấn Enable Review Apps.

• Đánh dấu vào ô: Create new review apps for new pull requests automatically (Tự động tạo app khi có PR).
• Đánh dấu vào ô: Destroy stale review apps automatically (Tự động xóa app nếu PR đóng hoặc quá 5 ngày không thao tác).

4. Phân bổ App vào Staging và Production

• Bấm Add app ở cột Staging, tạo một app mới ví dụ: afc-api-staging.
• Bấm Add app ở cột Production, tạo một app tên là afc-api-production.
• Cấu hình nhánh develop tự động deploy vào Staging, nhánh main tự động deploy vào Production.

4. Tận hưởng Workflow thực chiến

Từ giờ trở đi, công việc của đội kỹ sư Backend sẽ thanh thoát hơn bao giờ hết:

1. Code tính năng mới: Bạn tạo nhánh feature/fix-orphan-transactions và đẩy code lên.
2. Tạo Pull Request: Ngay lập tức, Heroku sinh ra một đường link tạm thời: [https://afc-system-pr-12.herokuapp.com](https://afc-system-pr-12.herokuapp.com). Đội QA bấm vào link này, test trực tiếp với Database tạm thời mà không ảnh hưởng đến bất kỳ ai.
3. Merge PR: Bạn bấm Merge. Đường link tạm thời bị Heroku xóa sổ. Code tự động được đẩy vào ứng dụng afc-api-staging.
4. Lên sóng (Go Live): Leader vào Heroku, nhấn nút Promote to Production. Toàn bộ hệ thống được cập nhật trong vỏn vẹn 3 giây, Zero Downtime.

Tổng kết Series Heroku

Từ Bài 1 đến Bài 5, chúng ta đã đi từ một "lính mới" chỉ biết deploy code thô, tiến đến làm chủ Config Vars, Database, kiến trúc Worker/Redis chạy ngầm, và cuối cùng là xây dựng một chu trình CI/CD hoàn hảo với Pipelines.

Với bộ kỹ năng từ XAMPP (Local) -> Bitbucket (CI/CD) -> Vault (Bảo mật) -> Heroku (Cloud PaaS), bạn đã sở hữu một hệ tư duy thiết kế phần mềm toàn diện của một System Architect thực thụ.