Quy trình triển khai tính năng mới (Feature Release) cho đội phát triển nhỏ: Không để bug lên production

Tại sao đội nhỏ càng cần quy trình chặt hơn?

Nghe có vẻ ngược: đội lớn mới cần quy trình nhiều, đội nhỏ thì linh hoạt hơn. Thực tế hoàn toàn ngược lại.

Đội tech lớn có chuyên biệt hóa — người viết code, người test, người deploy là ba người khác nhau, mỗi người có checklist riêng. Đội nhỏ thường có một developer vừa viết code vừa tự test vừa tự deploy — không ai review lại họ. Đây là môi trường mà một sơ suất nhỏ dễ leo thẳng lên production nhất.

Thêm vào đó, khi đội nhỏ chịu áp lực deadline từ product hoặc khách hàng, "deploy nhanh rồi xem" trở thành cám dỗ rất lớn. Và cái giá của một production incident không chỉ là vài tiếng fix bug — mà là mất tin tưởng từ khách hàng, stress nội bộ, và thời gian mà đáng lẽ dùng để xây tính năng mới.

Quy trình 7 bước Feature Release cho đội nhỏ

Bước 1 — Viết Spec trước khi code

Trước khi bất kỳ ai mở IDE, cần có một tài liệu ngắn mô tả rõ: tính năng này làm gì, ai sẽ dùng nó và trong tình huống nào, edge case nào cần xử lý, định nghĩa "done" là gì. Tài liệu này không cần dài — một trang A4 là đủ. Mục tiêu là đảm bảo developer, tester và product owner đồng thuận về thứ sắp được xây trước khi bắt đầu.

Không có Spec = developer và product owner có hai hiểu biết khác nhau về cùng một tính năng = làm xong phải làm lại.

Bước 2 — Branch riêng cho mỗi tính năng

Không bao giờ phát triển tính năng mới trực tiếp trên branch main hoặc production. Mỗi tính năng (hoặc bug fix lớn) cần một branch riêng với tên mô tả rõ ràng (ví dụ: feature/email-to-task hoặc fix/notification-delay). Quy tắc này tưởng đơn giản nhưng ngăn chặn hàng chục sự cố production mỗi năm.

Bước 3 — Code Review trước khi merge

Dù đội chỉ có 2-3 developer, vẫn cần ít nhất một người khác đọc code trước khi merge. Code review không phải để tìm lỗi logic phức tạp — người review đó cũng có thể không giỏi hơn người viết. Mục tiêu là cặp mắt thứ hai phát hiện những thứ hiển nhiên mà người viết đã không nhìn thấy vì quá quen với code của mình.

Thiết lập rule: không ai tự approve Pull Request của mình. Dù chỉ 10 phút, ai đó phải đọc qua.

Bước 4 — Test trên môi trường Staging

Staging là bản sao của production, nhưng không ảnh hưởng đến người dùng thực. Deploy lên staging trước, rồi test theo các trường hợp đã định nghĩa trong Spec: happy path (luồng bình thường), edge case (trường hợp biên), và các tình huống lỗi phổ biến (input rỗng, network chậm, quyền không đủ...).

Nếu đội không có người test chuyên biệt, developer và product owner cùng test trên staging. Hai người với hai cách dùng khác nhau sẽ tìm ra nhiều vấn đề hơn một người.

Bước 5 — Checklist trước khi deploy production

Tạo một checklist cố định và dùng lại mỗi lần release. Checklist tối thiểu gồm:

• Đã test đủ các case trên staging?
• Database migration (nếu có) đã được test và có script rollback?
• Các tính năng cũ không bị ảnh hưởng (regression)?
• Monitoring và alerting đã sẵn sàng để phát hiện lỗi sớm?
• Thời điểm deploy có phải giờ peak traffic không? (nếu có, chọn giờ thấp điểm)
• Ai là người on-call trong 2 giờ đầu sau deploy?

Bước 6 — Deploy từng bước, không deploy tất cả cùng lúc

Nếu tính năng mới có thể ảnh hưởng lớn đến trải nghiệm người dùng, cân nhắc triển khai theo kiểu Feature Flag — tính năng đã được deploy lên production nhưng chỉ bật cho một nhóm nhỏ người dùng thử trước (internal team hoặc beta users). Nếu không có vấn đề sau 24-48 giờ, mở rộng cho toàn bộ người dùng.

Với đội nhỏ không có hạ tầng Feature Flag phức tạp, cách đơn giản nhất là deploy vào cuối tuần hoặc cuối ngày — khi traffic thấp nhất — và quan sát chặt trong 1-2 giờ đầu.

Bước 7 — Monitor sau deploy và đóng vòng lặp

Deploy xong không phải là hết. Theo dõi error logs, response time, và các metric quan trọng trong ít nhất 24 giờ sau deploy. Thiết lập alert để được thông báo ngay nếu có bất thường — đừng để khách hàng là người đầu tiên báo lỗi.

Sau khi tính năng đã ổn định, dành 30 phút họp retrospective ngắn: Deploy lần này có vấn đề gì không? Có bước nào trong quy trình cần cải thiện không? Ghi lại và cập nhật checklist lần sau.

Áp dụng vào Workira

Trong Workira, mỗi tính năng mới là một thẻ công việc đi qua các cột: Spec → In Development → Code Review → Staging Test → Ready to Deploy → Deployed → Monitoring. Mọi người trong đội nhìn vào bảng là biết tính năng nào đang ở bước nào, ai đang blocking ai, và release tiếp theo sẽ bao gồm những gì. Không cần họp "status update" hàng ngày — bảng đã nói thay.

Một nguyên tắc xuyên suốt

Quy trình này không phải để làm chậm đội lại. Mục tiêu là làm cho mỗi lần deploy trở thành một sự kiện bình thường và có thể dự đoán được — thay vì một sự kiện căng thẳng mà không ai muốn nhận trách nhiệm nếu có lỗi. Đội release được nhiều hơn, tự tin hơn, và ít stress hơn khi có quy trình rõ ràng phía sau.