Dev / Staging / Production là gì?
Anh em BA chắc nghe nhiều về mấy khái niệm này, nay mình share cho anh em non tech.
Thông thường, hệ thống sẽ đi qua nhiều environment (môi trường) khác nhau. Mỗi môi trường có mục đích riêng.
Ba môi trường phổ biến khi dev đến chạy thật.
Dev → Staging → Production
Có thể hình dung đơn giản như nấu ăn:
- Dev: Bếp thử: Nơi thử nghiệm và chỉnh sửa.
- Staging: Bếp tổng duyệt mô phỏng môi trường thật để kiểm thử.
- Production: Nhà hàng thật nơi khách hàng thực sự sử dụng.
1. Dev – Development
Đây là môi trường dành chủ yếu cho Developer viết code và thử nghiệm.
Đặc điểm:
- Code thay đổi thường xuyên.
- Có thể phát sinh nhiều lỗi.
- Dữ liệu thường là dữ liệu test/mock.
- Có thể sử dụng sandbox hoặc môi trường giả lập của bên thứ ba.
- Độ ổn định chưa cao.
BA có thể cần kiểm tra trên Dev trong một số trường hợp, nhưng không nên mặc định Dev là môi trường nghiệm thu cuối cùng.
2. Staging
Staging là môi trường được sử dụng để kiểm thử trước khi đưa hệ thống lên Production.
Mục tiêu quan trọng là tạo ra một môi trường gần giống Production nhất có thể.
Thông thường:
- QC kiểm thử.
- BA/PO kiểm tra và xác nhận yêu cầu.
- Có thể thực hiện UAT nếu Staging được dùng cho mục đích UAT.
- Dữ liệu thường là dữ liệu test hoặc dữ liệu đã được ẩn danh.
- Cấu hình và tích hợp được thiết lập gần với Production.
- Các bản release được kiểm tra trước khi go-live.
Một điểm cần nhớ:
Staging không đồng nghĩa với UAT.
Tùy kiến trúc và quy trình của từng công ty, có thể có môi trường QA/Test, Staging và UAT riêng biệt.
3. Production: Live
Production là môi trường thật, nơi người dùng thật sử dụng hệ thống.
Đây là môi trường có mức độ kiểm soát cao nhất.
Thông thường:
- Người dùng thật truy cập.
- Dữ liệu nghiệp vụ thật được xử lý.
- Các hệ thống bên thứ ba có thể sử dụng kết nối thật.
- Việc deploy/release được kiểm soát.
- Thay đổi trên Production cần được thực hiện theo quy trình được phê duyệt.
Một lỗi trên Production có thể ảnh hưởng trực tiếp đến khách hàng, doanh thu, dữ liệu và uy tín của doanh nghiệp.
Vì vậy:
Đừng tự ý test nghiệp vụ bằng dữ liệu thật trên Production.
BA cần hiểu điều này để làm gì?
1. Biết mình đang test ở đâu
Khi test hoặc kiểm tra một issue, BA cần biết rõ:
Bug xảy ra trên Dev, QA, Staging, UAT hay Production?
Đây là thông tin rất quan trọng khi báo lỗi.
2. Hiểu câu “Staging đúng nhưng Production lỗi”
Trường hợp này hoàn toàn có thể xảy ra.
Một số nguyên nhân có thể đến từ:
- Khác configuration.
- Khác dữ liệu.
- Khác version.
- Khác integration.
- Khác infrastructure.
- Khác permission hoặc security setting.
Vì vậy, khi report bug, đừng chỉ viết:
“Chức năng bị lỗi.”
Hãy cung cấp thêm:
Environment + Account + Test data + Steps + Expected result + Actual result
3. Hiểu “Done trên Staging” chưa có nghĩa là “đã lên Production”
Một tính năng có thể đã:
Development → Testing → UAT → Approved
nhưng vẫn chưa được người dùng thật sử dụng.
Còn một bước quan trọng:
Deploy / Release lên Production
Một số lưu ý thực tế
Tên môi trường có thể khác nhau giữa các công ty.
Ví dụ:
DEV → QA → UAT → PROD
hoặc:
DEV → SIT → UAT → PROD
hoặc:
DEV → STAGING → PROD
Không nên quá quan trọng tên gọi.
Điều BA cần hiểu là:
Mỗi environment có mục đích, dữ liệu, cấu hình và mức độ kiểm soát khác nhau.
Mỗi môi trường cũng thường có URL, tài khoản và dữ liệu test riêng.
BA chỉ cần nhớ
DEV → Xây dựng & thử nghiệm
STAGING / UAT → Kiểm thử & nghiệm thu trước go-live
PRODUCTION → Người dùng thật sử dụng
Hi vọng anh em non tech sẽ hiểu thêm