Deploy backend lên production không chỉ là copy code lên server rồi restart service. Một lần deploy tốt phải có build rõ ràng, config an toàn, migration có kiểm soát, health check, logging, monitoring và rollback path. Nếu thiếu những lớp này, một thay đổi nhỏ trong backend có thể biến thành downtime, mất dữ liệu hoặc lỗi khó debug.
Bài viết này là checklist thực tế cho backend developer khi đưa API/service lên production, đặc biệt phù hợp với team nhỏ đến vừa đang dùng VPS, Docker, Nginx, CI/CD hoặc cloud cơ bản.
Deploy production là gì?
Deploy production là quá trình đưa một phiên bản backend mới vào môi trường thật, nơi có user thật, dữ liệu thật và rủi ro thật. Một deploy production tốt cần đảm bảo:
- code đã được test/build ổn định;
- config và secret đúng môi trường;
- database migration không phá dữ liệu;
- service có health check;
- có log/metrics để theo dõi sau release;
- có rollback path nếu release lỗi;
- team biết ai chịu trách nhiệm khi incident xảy ra.
Nếu bạn chưa chắc hệ thống backend đã đủ production-ready, nên đọc thêm Backend Engineering là gì và System Design cho Backend Developer.
1. Pre-deploy checklist
Trước khi deploy, hãy đảm bảo release không còn là “hy vọng sẽ chạy”. Tối thiểu cần kiểm:
- Test quan trọng đã chạy: unit/integration/API smoke test.
- Build artifact tạo thành công.
- Không commit secret/token/password vào repository.
- Migration đã được review.
- Backward compatibility với client cũ đã được nghĩ tới.
- Feature flag đã sẵn sàng nếu release có rủi ro.
- Release note ngắn gọn: thay đổi gì, rủi ro gì, rollback thế nào.
Với API public hoặc mobile app, backward compatibility đặc biệt quan trọng. Không nên đổi response field, error format hoặc status code mà không có versioning/deprecation rõ. Bạn có thể tham khảo thêm bài REST API Design Checklist.
2. Config, secret và environment
Nhiều lỗi production không đến từ code mà đến từ config sai: nhầm database URL, thiếu API key, bật debug mode, sai CORS, sai domain callback, hoặc dùng config staging cho production.
Nguyên tắc cơ bản:
- Secret nằm ngoài codebase: environment variables, secret manager hoặc file bảo vệ quyền truy cập.
- Mỗi môi trường có config riêng: development, staging, production.
- Không log secret/token/password.
- Có checklist biến môi trường bắt buộc trước khi start service.
- Config quan trọng nên fail-fast: thiếu biến thì service không khởi động.
Ví dụ các biến thường cần:
DATABASE_URL=...
REDIS_URL=...
SECRET_KEY_BASE=...
JWT_SECRET=...
SENTRY_DSN=...
RAILS_ENV=production
NODE_ENV=production3. Database migration an toàn
Database migration là phần dễ gây incident nhất khi deploy backend. Một migration sai có thể lock bảng lớn, mất dữ liệu hoặc làm code mới/cũ không tương thích.
Checklist migration:
- Backup dữ liệu quan trọng trước migration có rủi ro.
- Không chạy migration lock bảng lớn vào giờ peak.
- Thêm column nullable trước, backfill sau, rồi mới enforce constraint.
- Không rename/drop column đang được code cũ dùng trong cùng một release.
- Index bảng lớn nên tạo theo cách non-blocking nếu database hỗ trợ.
- Migration phải idempotent hoặc có recovery path rõ.
Một pattern an toàn là expand → migrate → contract:
- Expand: thêm schema mới nhưng vẫn giữ schema cũ.
- Migrate: code đọc/ghi tương thích cả cũ và mới, backfill dữ liệu.
- Contract: sau khi ổn định mới xóa field/schema cũ.
4. CI/CD, build artifact và release version
CI/CD giúp deploy lặp lại được, giảm thao tác tay và dễ audit. Nhưng CI/CD không chỉ là “push lên main là xong”; production nên có gate rõ.
Một pipeline tối thiểu nên có:
- Checkout code.
- Install dependencies.
- Run lint/test.
- Build artifact hoặc Docker image.
- Push image/artifact vào registry.
- Deploy vào staging hoặc production.
- Run smoke test sau deploy.
- Notify kết quả deploy.
Dù dùng GitHub Actions, GitLab CI, Jenkins hay công cụ khác, điều quan trọng là mỗi release phải trace được: commit nào, build nào, deploy lúc nào, ai approve, kết quả health check ra sao.
5. Health check và smoke test
Health check giúp load balancer/process manager biết service còn sống không. Smoke test giúp team biết release mới có chạy được những luồng tối thiểu không.
Health endpoint tối thiểu:
GET /health
{
"status": "ok",
"version": "2026.05.21.1",
"database": "ok",
"redis": "ok"
}Smoke test sau deploy có thể gồm:
- Gọi homepage/API root trả 200.
- Login hoặc auth token flow cơ bản.
- Gọi một endpoint đọc dữ liệu quan trọng.
- Tạo/update một record test nếu hệ thống cho phép.
- Kiểm tra background job queue không bị stuck.
6. Logging, monitoring và alerting
Deploy xong không có nghĩa là xong. Bạn cần quan sát hệ thống sau release, nhất là 15–60 phút đầu.
Các tín hiệu nên theo dõi:
- Error rate theo endpoint.
- Latency p50/p95/p99.
- Throughput/QPS.
- CPU, RAM, disk, network.
- Database connection, slow query, lock.
- Queue lag, job failure.
- External API failure.
Log nên có request ID, user/service context, endpoint, status code, duration và error stack. Nếu có distributed tracing thì càng tốt, nhưng structured logging đã là bước rất quan trọng.
7. Rollback strategy
Rollback không nên là chuyện nghĩ sau khi incident xảy ra. Trước khi deploy, team cần biết quay lại bằng cách nào.
Các kiểu rollback phổ biến:
- Rollback code: deploy lại image/release cũ.
- Feature flag off: tắt tính năng mới mà không rollback toàn bộ service.
- Database rollback: rất khó và rủi ro, nên thiết kế migration để không cần rollback dữ liệu nếu có thể.
- Traffic rollback: chuyển traffic về version cũ nếu dùng blue-green/canary.
Điểm quan trọng: nếu migration đã phá backward compatibility, rollback code có thể không cứu được hệ thống. Vì vậy migration và deploy cần được thiết kế cùng nhau.
Deployment flow khuyến nghị
Với team nhỏ/vừa, một flow thực tế có thể là:
- Merge PR sau khi test pass và review xong.
- CI build Docker image hoặc artifact có version rõ.
- Deploy lên staging, chạy migration staging.
- Run smoke test staging.
- Approve production deployment.
- Backup hoặc snapshot nếu có migration rủi ro.
- Deploy production theo release version.
- Run migration production theo kế hoạch.
- Run health check và smoke test.
- Monitor metrics/logs 15–60 phút đầu.
- Nếu lỗi vượt ngưỡng, rollback hoặc tắt feature flag.
Checklist deploy backend lên production
- Code đã pass test/build/lint tối thiểu.
- Release note có thay đổi, rủi ro và rollback plan.
- Secret/config production đã kiểm tra.
- Không bật debug mode ở production.
- Migration đã review và có kế hoạch chạy an toàn.
- Backup/snapshot đã có nếu migration rủi ro.
- Build artifact hoặc Docker image có version/tag rõ.
- Health check endpoint hoạt động.
- Smoke test sau deploy đã chuẩn bị.
- Logging có request ID và error context.
- Dashboard/alert cho error rate, latency, resource, queue.
- Rollback path đã test hoặc ít nhất đã viết rõ.
- Người phụ trách release/incident đã xác định.
FAQ
Deploy backend có bắt buộc dùng Docker không?
Không bắt buộc. Docker giúp đóng gói môi trường nhất quán, nhưng bạn vẫn có thể deploy bằng systemd, Capistrano, PM2, Passenger, hoặc script riêng. Quan trọng là release phải lặp lại được và có rollback path.
Có nên chạy migration tự động trong CI/CD không?
Tùy mức rủi ro. Migration nhỏ có thể tự động, nhưng migration lớn hoặc lock bảng nên chạy có kiểm soát, chọn thời điểm thấp tải và có backup/monitoring.
Health check có nên kiểm database không?
Có thể có nhiều cấp: liveness chỉ kiểm process sống, readiness kiểm dependency như database/cache. Không nên để health check quá nặng gây thêm tải.
Rollback database thế nào?
Rollback database thường khó hơn rollback code. Cách tốt nhất là thiết kế migration backward-compatible: thêm trước, chuyển dần, xóa sau. Với dữ liệu quan trọng, cần backup/restore plan.
Kết luận
Deploy backend lên production là một phần quan trọng của năng lực backend hiện đại. Một backend engineer tốt không chỉ viết API đúng, mà còn biết đưa API đó vào production an toàn, quan sát được và khôi phục được khi lỗi xảy ra.
Nên đọc tiếp trong cụm Backend/DevOps:
