T
Quay lại Kho kiến thức
Dev & Coding
2026-09-114 phút

Kỷ luật Quản lý Database Migration trong môi trường Production

Tại sao không bao giờ được phép sửa schema trực tiếp trên database production, quy trình tạo file migration chuẩn hóa và cách kiểm soát phiên bản an toàn.

DatabasePrisma MigrationDevOpsBest PracticesPostgreSQL

1. Thói quen nguy hiểm: Sửa trực tiếp DB Production (Hot-patching)

Khi phát triển nhanh hoặc cần sửa gấp một lỗi trên môi trường thực tế, nhiều lập trình viên thường chọn cách mở công cụ quản trị (như DBeaver, pgAdmin hoặc SSH gõ lệnh ALTER TABLE) để sửa trực tiếp cấu trúc bảng:

  • Thêm nhanh một cột mới.
  • Đổi kiểu dữ liệu từ INTEGER sang BIGINT.
  • Đổi tên trường hoặc xóa bảng cũ.

Hậu quả của thói quen này:

  1. Lệch pha Schema (Schema Drift): Mã nguồn trong kho Git (ORM Schema như Prisma / TypeORM) không còn khớp với cấu trúc thực tế trên máy chủ.
  2. Sập hệ thống khi Deploy mới: Lần tiếp theo khi CI/CD chạy lệnh build hoặc deploy, ORM sẽ phát hiện cấu trúc không đồng nhất, gây xung đột và làm sập toàn bộ dịch vụ.
  3. Mất khả năng sao chép môi trường: Không thể dựng lại một môi trường Staging hay Local giống hệt như Production vì không có lịch sử các câu lệnh SQL đã từng sửa thủ công.

2. Quy tắc kỷ luật bắt buộc: Migration-First Discipline

Mọi thay đổi liên quan đến cấu trúc cơ sở dữ liệu BẮT BUỘC PHẢI THỎA MÃN 3 ĐIỀU KIỆN:

  1. Phải được thể hiện bằng một file Migration có đánh số thứ tự hoặc timestamp trong thư mục prisma/migrations/ hoặc migrations/.
  2. File Migration đó phải được commit và push lên kho lưu trữ Git trước khi áp dụng lên Production.
  3. Việc chạy cập nhật trên Production phải thực hiện qua câu lệnh tự động trong quy trình Deploy: 
    npx prisma migrate deploy

3. Quy trình thực hiện chuẩn hóa với Prisma ORM

Bước 1: Sửa file schema.prisma tại máy Local

Thêm hoặc chỉnh sửa các trường cần thiết:

model User {
  id        String   @id @default(cuid())
  email     String   @unique
  // Thêm trường mới có giá trị mặc định an toàn:
  tier      String   @default("FREE") 
}

Bước 2: Tạo file Migration tại Local

Chạy lệnh sinh file SQL migration:

npx prisma migrate dev --name add_user_tier

Prisma sẽ tự động phân tích sự khác biệt và tạo ra file SQL rõ ràng: prisma/migrations/20260911_add_user_tier/migration.sql:

ALTER TABLE "User" ADD COLUMN "tier" TEXT NOT NULL DEFAULT 'FREE';

Bước 3: Commit vào Git và Deploy lên Production

Khi deploy lên máy chủ VPS (hoặc qua Docker compose), container sẽ chỉ chạy lệnh áp dụng:

# Lệnh này CHỈ chạy các file migration mới chưa được áp dụng, tuyệt đối không tạo file mới hay làm mất dữ liệu
npx prisma migrate deploy

4. Các quy tắc an toàn khi sửa Schema trên Production

  • Không bao giờ thêm cột NOT NULL mà không có DEFAULT: Nếu bảng đã có hàng triệu bản ghi, việc thêm cột bắt buộc mà không có giá trị mặc định sẽ làm câu lệnh bị treo hoặc từ chối thực thi.
  • Tránh xóa cột (DROP COLUMN) ngay lập tức: Khi cần bỏ một trường, hãy thực hiện theo 2 giai đoạn:
    • Giai đoạn 1: Ngừng đọc/ghi vào trường đó trong code.
    • Giai đoạn 2: Sau một vài tuần khi code mới đã ổn định, mới tạo migration để xóa cột vật lý khỏi database.
Về Kho kiến thức