CI/CD và môi trường preview cho dự án phần mềm: từ nhánh phát triển đến production

Khi một thay đổi đi thẳng từ máy của lập trình viên lên hệ thống thật, lỗi chỉ lộ ra khi khách hàng đã dùng. CI/CD và môi trường preview là cách kiểm tra thay đổi trước đó, đồng thời cho phép quay về bản cũ khi có sự cố.

Bài giải thích CI/CD, preview deployment, bảo vệ nhánh chính, biến môi trường, thay đổi cơ sở dữ liệu, quay lui (rollback) và cách đo. Nguồn chính là tài liệu GitHub, Vercel, Supabase, DORA và bài của Martin Fowler, đối chiếu đến ngày 23/10/2026.

Click Star đã có bài riêng về làm phần mềm theo yêu cầu có kiểm soát chi phí và về sao lưu, khôi phục dữ liệu (RPO, RTO). GitHub và Vercel là ví dụ vì tài liệu mở được. Click Star làm phần mềm theo yêu cầu nên có lợi ích liên quan.

Điểm chính

• CI (tích hợp liên tục) là đưa thay đổi vào kho mã chung thường xuyên, mỗi lần đều build và kiểm thử tự động. CD (triển khai liên tục) là dùng tự động hóa để phát hành bản cập nhật, theo GitHub Docs.
• Trên Vercel, đẩy mã lên nhánh khác nhánh production hoặc mở pull request tạo preview deployment có URL riêng.
• Nhánh chính cần được bảo vệ. Job bị bỏ qua báo thành công, còn workflow bị lọc đường dẫn thì treo Pending và chặn hợp nhất, nên cần thử bằng pull request cố ý lỗi.
• Biến môi trường tách theo Production, Preview và Development; thay đổi chỉ áp cho lần triển khai sau.
• Quay lui mã không quay lui cơ sở dữ liệu. Với thay đổi lược đồ, mẫu expand, migrate, contract của Martin Fowler cho phép phát hành an toàn từng pha.
• Đo bằng 5 chỉ số của DORA, và không biến chỉ số thành mục tiêu.

CI/CD là gì và vì sao nên làm

Theo GitHub Docs (không ghi ngày, đọc 23/10/2026), tích hợp liên tục là thực hành thường xuyên đưa mã vào kho chung, mỗi lần đều build và chạy kiểm thử để phát hiện lỗi sớm, khi lượng mã cần gỡ còn nhỏ.

Triển khai liên tục là dùng tự động hóa để xuất bản bản cập nhật, thường sau khi đã build và kiểm thử. GitHub Actions chạy quy trình (workflow) viết trong tệp YAML của kho khi có sự kiện như mở pull request.

Trang về CI của DORA (không ghi ngày, đọc 23/10/2026) mô tả: hợp nhất vào nhánh chính thường xuyên, kiểm thử tự động chạy trước và sau khi hợp nhất, và kiểm thử hỏng thì sửa ngay.

DORA dẫn báo cáo State of DevOps 2015 rằng các nhóm làm tốt hơn khi hợp nhất ít nhất mỗi ngày. Kiểm thử nên cho phản hồi trong vài phút, giới hạn trên khoảng 10 phút.

Cơ chế nằm ở kích thước thay đổi: khi kiểm thử chạy thưa, một lỗi có thể đến từ rất nhiều thay đổi nên khó gỡ. DORA nêu giới hạn: làm theo bước nhỏ là đổi thói quen, và khi chuyển sang bước nhỏ, tính năng lớn có thể mất nhiều thời gian hơn để hoàn thành.

Nhánh phát triển và preview deployment

Theo tài liệu Environments của Vercel (cập nhật 17/9/2026), có 3 môi trường mặc định: Local (máy phát triển), Preview (kiểm thử mà không ảnh hưởng site thật) và Production (site cho người dùng cuối). Gói Pro và Enterprise có thêm môi trường tùy chỉnh như staging hoặc QA.

Vercel tạo preview deployment khi đẩy commit lên nhánh không phải nhánh production, khi mở pull request, hoặc khi chạy lệnh deploy không có cờ --prod.

Chi tiết dễ gây bất ngờ: lần triển khai đầu tiên của dự án mới luôn là production, kể cả khi đẩy từ nhánh khác. Lần đó build bằng biến của Production, nên biến chỉ gắn cho Preview sẽ không có.

Về staging, Vercel mô tả 3 cách: môi trường tùy chỉnh (Pro và Enterprise), nhánh preview cố định gắn domain như staging.example.com (mọi gói), hoặc triển khai production ở trạng thái chờ rồi mới promote. Cách thứ 3 dùng biến của Production nên có thể chạm vào dịch vụ và dữ liệu thật.

Bài hướng dẫn của Vercel (cập nhật 2/10/2026) nói preview mặc định có tiêu đề X-Robots-Tag: noindex, trừ khi gắn domain tùy chỉnh cho nhánh không phải production; khi đó chủ dự án phải tự thêm.

Kiểm thử tự động và bảo vệ nhánh chính

GitHub Docs cho phép đặt luật cho nhánh bằng ruleset hoặc branch protection. Theo trang Available rules for rulesets (đọc 23/10/2026), các luật liên quan gồm:

• Bắt buộc có pull request trước khi hợp nhất; không nhất thiết phải được duyệt, chỉ cần được mở, còn số lượt duyệt là tùy chọn.
• Bắt buộc status check đạt; chế độ strict đòi nhánh cập nhật với nhánh nền nên tốn thêm lượt build, chế độ loose ít build hơn nhưng check có thể hỏng sau khi hợp nhất.
• Chặn force push (bật mặc định), vì có thể làm mất commit mà người khác đã dựa vào.
• Giới hạn xóa nhánh, và có thể bắt buộc triển khai thành công vào một môi trường như staging trước khi hợp nhất.

Ruleset có ở kho công khai gói Free, và ở kho riêng tư với Pro, Team, Enterprise Cloud.

Có một bẫy cần thử. Trang About protected branches nói check bắt buộc phải có trạng thái thành công, bị bỏ qua hoặc trung tính. Tài liệu về status check nói một job bị bỏ qua báo trạng thái thành công và không chặn hợp nhất, kể cả khi là check bắt buộc.

Trang Troubleshooting required status checks phân biệt 2 ca. Job bị bỏ qua do điều kiện if báo Success. Workflow bị bỏ qua do lọc đường dẫn, nhánh hoặc nội dung commit thì check treo Pending và chặn hợp nhất.

Click Star chưa thử. Cách kiểm tra là mở một pull request cố ý làm kiểm thử hỏng và xem nó có bị chặn hay không.

Biến môi trường và bí mật theo từng môi trường

Tài liệu Environment variables của Vercel (cập nhật 17/9/2026) định nghĩa biến môi trường là cặp khóa và giá trị đặt ngoài mã nguồn để giá trị đổi theo môi trường. Mỗi biến chọn 1 hoặc nhiều môi trường: Production, Preview, Development hoặc môi trường tùy chỉnh.

Giá trị được mã hóa khi lưu; biến loại Secret không đọc lại được sau khi lưu. Thay đổi biến chỉ áp cho deployment mới.

Phía GitHub Actions, tài liệu Secrets (không ghi ngày) nói Actions chỉ đọc một secret khi workflow đưa nó vào tường minh, log che giá trị secret nhưng không được bảo đảm, và nên cấp quyền tối thiểu. Environment secrets có thể kèm người duyệt bắt buộc, tùy gói và loại kho.

Thay đổi cơ sở dữ liệu cần quy trình riêng

Mã quay lui được bằng cách đổi trỏ tên miền, nhưng cơ sở dữ liệu giữ trạng thái. Hộp xác nhận quay lui của Vercel nhắc rằng hành vi của API ngoài, cơ sở dữ liệu hay CMS có thể đã khác so với bản cũ (tài liệu Instant Rollback, cập nhật 7/7/2026).

Suy luận của Click Star: nếu lược đồ đã đổi, mã cũ phải chạy được với lược đồ mới thì quay lui mới an toàn, nên thay đổi lược đồ cần thứ tự phát hành riêng.

Martin Fowler (bài Parallel Change, Danilo Sato, 13/5/2014) mô tả mẫu expand, migrate, contract: mở rộng để hỗ trợ cả bản cũ lẫn mới, chuyển dần nơi dùng sang bản mới, rồi gỡ bản cũ. Mẫu này cho phép phát hành ở bất kỳ pha nào, và phần lớn tái cấu trúc cơ sở dữ liệu đi theo nó.

Ví dụ minh họa của Click Star (không lấy từ nguồn ngoài) khi đổi tên một cột: lần phát hành 1 thêm cột mới và ghi vào cả 2 cột, lần 2 chuyển chỗ đọc sang cột mới, lần 3 mới xóa cột cũ.

Về công cụ, tài liệu Database Migrations của Supabase (không ghi ngày) mô tả thay đổi lược đồ viết thành tệp SQL; sửa trực tiếp cơ sở dữ liệu từ xa bỏ qua lịch sử migration và làm lệnh db push báo lỗi đồng bộ.

Khung tham khảo của Click Star cho thay đổi dữ liệu: gửi migration cùng pull request với mã, chạy thử trên cơ sở dữ liệu preview hoặc staging, sao lưu trước khi áp lên production, và viết mã chạy được với cả lược đồ cũ lẫn mới trong 1 chu kỳ phát hành.

Quay lui: nhanh nhưng có giới hạn

Theo tài liệu Instant Rollback của Vercel, quay lui là gán lại domain production cho một deployment đã từng phục vụ production, không build lại, nên rất nhanh. Gói Hobby chỉ quay về bản liền trước; Pro và Enterprise quay về mọi bản đủ điều kiện.

Cần biết 3 điều trước khi dùng. Điều 1: sau khi quay lui, Vercel tắt tự động gán domain production, nên bản sửa lỗi đẩy lên main không tự lên cho đến khi hoàn tác (Undo Rollback) hoặc chạy vercel promote.

Điều 2: biến môi trường không đổi và bản cũ dùng lại bản build cũ, nên cấu hình có thể đã lỗi thời. Điều 3: không chạy song song 2 lần quay lui trên cùng một dự án.

Tài liệu Promoting Deployments (cập nhật 26/6/2026) liệt kê 3 cách: Instant Rollback, promote một preview (build lại hoàn toàn, biến chuyển sang bộ của Production, hợp khi cần dùng tạm một nhánh khác), và promote bản production đang chờ (chưa từng phục vụ, không build lại).

Cách đo: 5 chỉ số của DORA

Theo trang DORA's software delivery performance metrics (cập nhật 5/1/2026), có 5 chỉ số. Nhóm thông lượng gồm thời gian từ commit đến production, tần suất triển khai và thời gian khôi phục sau triển khai lỗi.

Nhóm bất ổn gồm tỷ lệ triển khai cần can thiệp ngay (change fail rate) và tỷ lệ triển khai ngoài kế hoạch do sự cố production (deployment rework rate).

DORA nói nghiên cứu của họ cho thấy tốc độ và độ ổn định không đánh đổi nhau, và nên đo từng ứng dụng riêng lẻ. Bẫy hay gặp: đặt chỉ số làm mục tiêu nên nhóm tìm cách làm đẹp con số, và so sánh giữa các ứng dụng quá khác nhau. Click Star không nêu ngưỡng "tốt" hay "kém", vì trang đã đọc không đưa ngưỡng.

Ý nghĩa với doanh nghiệp Việt Nam

Click Star không tìm thấy số đo về mức áp dụng CI/CD ở doanh nghiệp Việt Nam; phần này là suy luận từ tài liệu.

Đánh giá của Click Star. Với website hoặc ứng dụng nội bộ quy mô nhỏ, 3 việc đáng làm trước là: mọi thay đổi đi qua pull request, có preview để người không viết mã xem được, và có đường quay lui đã thử trước khi cần.

Kiểm thử tự động có thể bắt đầu nhỏ, với vài kịch bản bảo vệ chức năng quan trọng như biểu mẫu liên hệ. Preview giúp người duyệt mở một liên kết thay vì nhận tệp, nhưng cần được bảo vệ truy cập và dùng khóa, dữ liệu riêng.

Lộ trình 30 ngày (khung tham khảo của Click Star)

Lộ trình do Click Star đề xuất, không lấy từ nguồn ngoài.

• Tuần 1: tách môi trường Production, Preview và Development; chuyển mọi khóa ra biến môi trường; xoay khóa từng nằm trong mã.
• Tuần 2: bắt buộc pull request vào nhánh chính, bật workflow build và kiểm thử, đặt check bắt buộc và thử bằng pull request cố ý lỗi.
• Tuần 3: bảo vệ truy cập preview, kiểm tra tiêu đề noindex, thử quy trình migration 3 pha trên cơ sở dữ liệu preview.
• Tuần 4: diễn tập quay lui, ghi thời gian khôi phục, chọn 2 chỉ số DORA để theo dõi hằng tháng.

Những sai lầm thường gặp

1. Bật check bắt buộc rồi tin màu xanh mà không thử pull request cố ý lỗi, trong khi job bị bỏ qua do điều kiện vẫn báo thành công.
2. Gắn domain tùy chỉnh cho nhánh staging nhưng quên thêm tiêu đề noindex.
3. Cho preview hoặc bản production đang chờ dùng khóa và dữ liệu production.
4. Đổi tên hoặc xóa cột trong 1 lần phát hành, rồi thấy mã cũ vẫn cần cột đó khi quay lui.
5. Quay lui xong mà quên tự động gán domain bị tắt, nên bản sửa lỗi không lên.
6. Đổi biến môi trường và kỳ vọng bản đang chạy tự cập nhật.
7. Biến chỉ số DORA thành mục tiêu hoặc so sánh giữa các hệ thống khác nhau.

Điều chưa biết

Click Star không có số đo độc lập về mức áp dụng CI/CD của doanh nghiệp Việt Nam. Các trang GitHub Docs, trang CI của DORA và Supabase Docs không hiển thị ngày cập nhật khi đọc.

Click Star chưa tự thử check bắt buộc với job hay workflow bị bỏ qua; hành vi nêu trên lấy từ tài liệu GitHub.

Click Star chưa đọc tài liệu GitLab, Bitbucket, Azure DevOps hay cách quay lui migration của Supabase, và không nêu giá hay hạn mức theo gói.