Login

Môi trường dev, staging, production: vì sao phải tách bạch?

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Sửa nhanh một đoạn code rồi đẩy thẳng lên website đang chạy, và vài phút sau cả hệ thống báo lỗi. Đây là lý do mọi đội nghiêm túc đều tách môi trường. Mỗi môi trường có mục đích riêng và quan trọng nhất, sai sót ở môi trường này không làm hại môi trường khác.

Ba môi trường cơ bản

  • Development (dev): máy của lập trình viên hoặc môi trường chung để thử nghiệm. Nơi được phép hỏng, được phép thử bậy.
  • Staging: bản sao càng giống production càng tốt, nơi kiểm thử cuối cùng, nghiệm thu với khách hàng, thử quy trình triển khai.
  • Production: môi trường người dùng thật đang dùng. Ưu tiên cao nhất là ổn định và an toàn.

Nhiều đội thêm môi trường test/QA riêng cho kiểm thử tự động và thủ công, hoặc môi trường xem trước tạm thời cho mỗi pull request.

Vì sao phải tách?

  1. An toàn: lỗi chỉ xuất hiện ở dev hoặc staging, không đến tay người dùng.
  2. Dữ liệu: không cho lập trình viên chạm vào dữ liệu thật khi không cần thiết.
  3. Kiểm thử đáng tin: thử trên môi trường giống production sẽ lộ ra các lỗi mà máy cá nhân không thấy.
  4. Tập dượt triển khai: chạy thử toàn bộ quy trình phát hành ở staging trước khi làm thật.

Cấu hình khác nhau, mã giống nhau

Nguyên tắc quan trọng (nằm trong bộ nguyên tắc The Twelve-Factor App): mã nguồn giống nhau ở mọi môi trường, chỉ cấu hình thay đổi. Cấu hình như địa chỉ database, khóa API, chế độ gỡ lỗi nên được cung cấp qua biến môi trường chứ không ghi cứng trong code.

// Doc cau hinh tu bien moi truong
const config = {
  port: process.env.PORT || 3000,
  dbUrl: process.env.DATABASE_URL,
  debug: process.env.APP_ENV !== 'production',
};

if (!config.dbUrl) {
  throw new Error('Thieu DATABASE_URL');
}

Đoạn mã kiểm tra cấu hình bắt buộc ngay khi khởi động, để lỗi hiện ra sớm thay vì khi người dùng đang dùng.

Làm sao staging giống production?

  • Cùng hệ điều hành, phiên bản ngôn ngữ và dịch vụ phụ thuộc (có thể dùng Docker để đảm bảo).
  • Cùng cấu trúc hạ tầng nhưng quy mô nhỏ hơn để tiết kiệm.
  • Cùng quy trình triển khai, cùng script.
  • Dữ liệu giống thật về hình dạng nhưng đã được ẩn danh hóa. Không sao chép dữ liệu cá nhân thật sang staging nếu chưa che hoặc thay thế thông tin nhạy cảm.

Luồng đi của một thay đổi

  1. Lập trình viên viết và thử ở máy cá nhân.
  2. Đẩy lên nhánh, CI chạy kiểm thử tự động.
  3. Sau khi gộp, tự động triển khai lên staging.
  4. Kiểm tra thủ công, kiểm thử chấp nhận.
  5. Triển khai lên production, tự động hoặc bấm nút xác nhận.
  6. Theo dõi chỉ số sau phát hành; sẵn sàng quay lui khi cần.

Những lỗi hay gặp

  • Staging lệch production quá nhiều nên 'staging chạy tốt mà production lỗi'.
  • Dùng chung database hoặc khóa API giữa staging và production, dẫn tới thao tác nhầm vào dữ liệu thật.
  • Gửi email thật hoặc thu tiền thật từ môi trường thử nghiệm. Hãy dùng chế độ sandbox của dịch vụ bên thứ ba.
  • Staging không được cập nhật nên không ai tin nó nữa.
  • Công khai staging ra internet mà không có bảo vệ.

Kết luận

Tách môi trường là thói quen rẻ nhưng cứu rất nhiều sự cố. Hãy giữ mã giống nhau, đổi cấu hình qua biến môi trường, cho staging giống production nhất có thể và đừng bao giờ dùng chung dữ liệu hoặc khóa giữa các môi trường.

Muốn thực hành thiết lập quy trình dev, staging, production cho một dự án hoàn chỉnh, bạn có thể xem thêm các khóa học tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment