[Kinh nghiệm Thực chiến] Tại sao luôn phải "Cập nhật Database" trước khi "Deploy Code" lên Production?

Khi mới bước chân vào các dự án thực tế, nhiều lập trình viên thường có thói quen viết code, tạo file migration thêm cột/thêm bảng, gom tất cả vào một Pull Request (PR) và kỳ vọng hệ thống sẽ tự động cập nhật mọi thứ cùng một lúc khi deploy.

Tuy nhiên, nếu bạn để ý, các Senior, Leader hoặc System Administrator luôn có một nguyên tắc bất di bất dịch: "Thêm cột/bảng vào Database trước, sau đó mới Deploy Code sau."

Tại sao lại có sự "rườm rà" này? Dưới đây là 3 lý do cốt lõi làm nên sự khác biệt giữa một hệ thống hay "chết yểu" và một hệ thống vững như bàn thạch.

1. Tránh thảm họa "Lệch nhịp" (Timing Mismatch)

Trong thực tế, quá trình đưa source code mới lên server và quá trình chạy lệnh thay đổi cơ sở dữ liệu (migration) không bao giờ hoàn tất trong cùng một phần nghìn giây. Sẽ luôn có độ trễ.

Nếu chúng ta không kiểm soát thứ tự, thảm họa sẽ xảy ra:

Việc chuẩn bị sẵn "bãi đáp" (database) trước khi máy bay (code) hạ cánh là nguyên tắc tiên quyết để tránh lỗi vỡ hệ thống.

2. Tiền đề cho Zero-Downtime Deployment (Deploy không gián đoạn)

Các hệ thống lớn hiện đại không bao giờ tắt server đi bật lại để cập nhật code, vì như vậy sẽ làm gián đoạn trải nghiệm người dùng. Thay vào đó, họ sử dụng các kỹ thuật deploy như Blue-Green hoặc Rolling Update.

Điều này có nghĩa là: Trong khoảng thời gian từ 3-5 phút lúc deploy, phiên bản Code Cũ và phiên bản Code Mới sẽ chạy song song với nhau và phục vụ người dùng cùng lúc. Cả hai phiên bản này đều kết nối chung vào một Database.

• Nếu bạn cập nhật Database trước: Phiên bản code mới sẽ tận dụng được cột mới. Phiên bản code cũ thì cứ việc lờ cột đó đi và chạy như bình thường.
• Hai phiên bản sống hòa bình, người dùng không hề hay biết hệ thống vừa được nâng cấp.

3. Tự chừa "đường lui" an toàn (Safe Rollback)

Không có đoạn code nào là hoàn hảo 100%. Sẽ có lúc PR của bạn được merge lên Production và gây ra lỗi nghiêm trọng (bug logic, memory leak, quá tải CPU...). Lúc này, thao tác đầu tiên của Leader là Rollback (Lùi phiên bản code).

• Revert Code: Rất nhanh và an toàn. Bạn chỉ cần đưa code về commit trước đó, hệ thống lại ổn định.
• Revert Database (Xóa cột/bảng vừa thêm): Đây là một hành động cực kỳ nguy hiểm. Trong khoảng thời gian vài phút tính năng mới chạy, người dùng có thể đã ghi dữ liệu vào cột mới đó. Nếu bạn lùi database (drop column), bạn sẽ vĩnh viễn xóa mất dữ liệu của khách hàng (Data Loss) – điều tối kỵ trong ngành phần mềm.

Tư duy của người có kinh nghiệm: "Database chỉ nên tiến lên, hạn chế tối đa việc lùi lại". Do đó, tách biệt DB ra khỏi Code giúp chúng ta có thể lùi Code thoải mái mà không sợ ảnh hưởng đến cấu trúc Dữ liệu.

⚠️ Lưu ý "Sống Còn" khi làm theo phương pháp này

Việc đẩy Database lên trước chỉ an toàn tuyệt đối nếu bạn tuân thủ quy tắc Tương thích ngược (Backward Compatibility). Khi Leader thêm một cột mới vào bảng đang có sẵn, cột đó bắt buộc phải đáp ứng một trong hai điều kiện:

1. Phải cho phép giá trị rỗng (Nullable): Để khi code cũ insert dòng mới (không có trường này), Database sẽ tự động điền NULL và không báo lỗi.
2. Phải có giá trị mặc định (Default Value): Nếu cột đó bắt buộc phải có dữ liệu (NOT NULL), nó phải được gán một giá trị mặc định (ví dụ: 0, false, pending...).

Nếu bạn tạo một cột NOT NULL mà không có giá trị mặc định, ngay khi DB vừa cập nhật xong, toàn bộ code cũ đang chạy sẽ lập tức chết đứng vì không thể insert dữ liệu.

Kết luận

Phát triển tính năng không chỉ là code sao cho chạy được trên máy của mình (localhost), mà còn là việc tính toán lộ trình đưa nó lên môi trường thực tế sao cho êm ái nhất. Nắm vững kỹ năng này, bạn đã bước thêm một bước dài trên con đường trở thành một kỹ sư phần mềm thực thụ!