Trunk-based development và GitFlow cho phát hành hàng tuần

Tại sao phát hành hàng tuần trở nên lộn xộn với mô hình nhánh sai

Phát hành hàng tuần nghe có vẻ đơn giản cho đến tuần bạn trễ hạn. Bản build "gần sẵn" vào thứ Năm, QA tìm lỗi muộn vào thứ Sáu, và thứ Hai biến thành dọn dẹp thay vì bắt đầu sạch.

Một nhân tố lớn là mô hình nhánh bạn dùng. Nó quyết định khi nào các thay đổi gặp nhau, nơi tích hợp diễn ra và bạn có thể phục hồi nhanh ra sao khi có sự cố. Nếu tích hợp bị dồn tới cuối tuần, bạn phải trả giá bằng xung đột merge, lỗi bất ngờ và môi trường test lung lay.

Khi workflow chống lại bạn, thường cảm giác như sau:

• Merge mất nhiều thời gian hơn so với công việc tạo ra chúng.
• QA test một hỗn hợp thay đổi sai vì các nhánh trôi dạt.
• Release trở thành thương lượng thay vì thói quen.
• Hotfix gây hoảng hốt vì không ai chắc còn gì sẽ được phát hành.
• Mọi người mất niềm tin vào QA và bắt đầu xin ngoại lệ.

Nhánh cũng hình thành độ ổn định của QA. Nếu QA phải liên tục chuyển giữa các luồng mã tích hợp một nửa, nó trở thành mục tiêu di động. Ngay cả tester giỏi cũng khó đưa câu trả lời rõ ràng khi hệ thống dưới thử nghiệm thay đổi mỗi vài giờ, hoặc một merge muộn âm thầm thay thế thứ họ đã test hôm trước.

Vì vậy các nhóm thường so sánh trunk-based development và GitFlow khi chuyển sang nhịp phát hành hàng tuần. Câu hỏi hữu ích không phải là cái nào phổ biến. Mà là cái nào giảm đau merge, giữ release có thể dự đoán, làm hotfix an toàn và nhanh, và giữ QA có ý nghĩa.

Giả sử một đội nhỏ đến vừa, một repo chung, CI chạy trên mỗi push. Có thể bạn phát hành web app và API. Hoặc một phần đội xây dựng trực quan trên nền tảng như AppMaster trong khi vẫn quản lý code sinh ra và deploy như bất kỳ đội sản phẩm nào.

Nếu quy trình hiện tại tạo ra những lần merge lớn vào cuối tuần, nhịp hàng tuần của bạn sẽ liên tục trượt. Nếu nó khuyến khích tích hợp nhỏ, thường xuyên, phát hành hàng tuần sẽ bắt đầu trở nên nhàm chán (theo nghĩa tốt).

Trunk-based development và GitFlow bằng ngôn ngữ đơn giản

Cả hai cách chỉ là tập hợp quy tắc về cách dùng nhánh để công việc đi từ "đang làm" đến "phát hành" mà không rối. Khác biệt thực sự là bạn giữ bao nhiêu nhánh tồn tại lâu dài, và công việc tách biệt bao lâu trước khi gặp mã của người khác.

• Trunk-based giữ hầu hết mọi thứ gần main.
• GitFlow giữ các làn riêng cho công việc đang làm và ổn định release.

Trunk-based development (nói đơn giản)

Trunk-based coi main (trunk) là trung tâm. Mọi người làm việc trên nhánh ngắn (vài giờ đến một hai ngày), merge thường xuyên, và giữ main ở trạng thái có thể phát hành.

Nếu điều gì đó chưa sẵn sàng, bạn giữ nó đủ nhỏ để hoàn thành nhanh, hoặc ẩn nó phía sau feature flag để có thể phát hành an toàn mà không hiển thị cho người dùng.

GitFlow (nói đơn giản)

GitFlow thường dùng một nhánh develop tồn tại lâu nơi các tính năng cập bến trước, cùng với các nhánh feature tách từ develop. Gần ngày phát hành, bạn cắt nhánh release/* để ổn định và test. Nếu production lỗi, bạn cắt hotfix/* (thường từ main) và merge lại.

Mô hình này tối ưu cho tách biệt: công việc tiếp tục trên develop trong khi nhánh release được test và vá.

Nhiều đau đầu đến từ hiểu sai thông thường:

• Xem trunk-based như "không dùng nhánh" (thực tế vẫn dùng nhánh, chỉ là ngắn).
• Dùng GitFlow nhưng không thực sự tạo nhánh release, khiến develop trở thành khu vực staging không ổn định.
• Để nhánh feature sống cả tuần, biến mọi mô hình thành vấn đề merge.
• Nhầm lẫn giữa "có thể phát hành" và "mọi thứ hoàn tất" thay vì "an toàn để deploy".

Ma sát merge: thứ gì thực sự gây ra

Xung đột merge thường đến từ hai nguồn: nhánh tồn tại quá lâu, và nhiều người thay đổi cùng vùng mã mà không phối hợp.

Khác biệt thực tế lớn nhất giữa trunk-based và GitFlow là công việc tách nhau bao lâu trước khi gặp nhau.

Với trunk-based, thay đổi vào dòng chính thường xuyên. Pull request nhỏ hơn, diff nhỏ hơn, và xung đột xuất hiện sớm khi ngữ cảnh còn mới. Xung đột vẫn xảy ra, nhưng thường dễ giải quyết hơn vì bạn chỉ đối chiếu vài dòng thay vì hai tuần drift. Đổi lại là kỷ luật: giữ build xanh, thay đổi từng bước, và coi main như sản phẩm.

Với GitFlow, công việc feature có thể nằm đó lâu hơn mà không ảnh hưởng đến người khác hàng ngày. Chi phí xuất hiện sau đó như các sự kiện merge lớn: feature vào develop, develop vào release/*, và release/* vào main. Mỗi lần merge là một cuộc gặp gỡ lớn hơn của các thay đổi, nên xung đột có khả năng xảy ra và khó gỡ hơn. Với phát hành hàng tuần, những merge lớn ấy thường rơi đúng lúc đội muốn test.

Tải kiểm duyệt code cũng thay đổi. Trunk-based thường có nhiều review hơn, nhưng mỗi review nhanh và dễ hiểu. GitFlow thường có ít review hơn nhưng nặng hơn, cộng thêm thời gian review trong các merge release khi mọi người mệt.

Để giảm ma sát merge trong cả hai mô hình:

• Giữ PR nhỏ và rõ ràng (mỗi PR một mục tiêu).
• Thống nhất ownership cho vùng rủi ro (migrations, cấu hình chung, UI lõi).
• Kéo thay đổi upstream hàng ngày để không drift.
• Nếu một file luôn "nóng", làm pair thay vì cùng đua song song.

Nếu xung đột cứ lặp lại, thường đó là dấu bạn tích hợp quá muộn, chứ không phải Git có vấn đề.

Độ dự đoán release cho nhịp hàng tuần

Dự đoán nghĩa là ba điều: bạn biết khi nào release đi, bạn biết có gì trong nó, và bạn biết các kiểm tra nào phải qua trước khi phát hành. Đội thường bỏ lỡ phát hành hàng tuần vì họ trộn quyết định phạm vi với sửa lỗi phút chót.

Trong trunk-based, phát hành hàng tuần ổn định khi main luôn xanh. Bạn merge các thay đổi nhỏ thường xuyên và kiểm soát phạm vi bằng feature flags thay vì nhánh lâu. Điều đó giữ tàu phát hành chạy ngay cả khi một tính năng chưa xong. Code có thể lên, nhưng hành vi hướng người dùng vẫn tắt cho tới khi sẵn sàng.

Cổng chất lượng thường đơn giản vì chỉ có một nơi để xác thực:

• Test tự động phải qua trên main.
• QA test một bản ứng viên ổn định, không phải thứ vừa được merge giờ trước.
• Các bước rollout và rollback được ghi rõ.
• Có thời hạn cắt rõ ràng cho release (dù commits vẫn có thể land).

Trong GitFlow, độ dự đoán đến từ nhánh release làm vùng đóng băng. Bạn chọn cutoff, tạo release/* và chỉ cho phép thay đổi cần thiết để ship. Ranh giới đó hữu ích, nhưng nó thêm khâu phối hợp vì sửa lỗi thường phải apply ở nhiều nơi (release và develop).

Công việc chưa hoàn tất xử lý khác nhau:

• Trunk-based: merge phần an toàn và giữ phần còn lại sau flags.
• GitFlow: giữ công việc chưa xong trong develop và loại trừ nó khỏi nhánh release.

Ví dụ: nếu cải thiện thanh checkout làm dở nửa chừng vào thứ Tư, trunk-based có thể merge refactor an toàn và giữ UI mới ẩn. GitFlow thường để nó trong develop, ship không có nó, và hoàn thành cho release tuần sau.

Luồng hotfix: đường ngắn nhất an toàn tới production

Hotfix không phải là công việc bình thường. Nó cần tốc độ, rủi ro thấp và con đường đưa thay đổi về nơi đội đang làm để không sửa lỗi hai lần.

Bắt đầu bằng một câu hỏi: mã chính xác đang chạy ở production là gì? Nếu bạn không trả lời được trong vài giây, hotfix sẽ trở thành phỏng đoán.

Hotfix với trunk-based development

Hotfix trong trunk-based có thể cảm thấy đơn giản vì main được coi là nguồn chân thực.

Một luồng phổ biến:

• Tạo nhánh ngắn từ commit production (thường là từ main).
• Sửa nhỏ nhất có thể (thêm test nếu được).
• Merge nhanh lại về main.
• Triển khai từ main và gắn tag release.

Vì đội thường tích hợp vào main, hotfix tự nhiên trở thành một phần của release tuần tiếp theo. Rủi ro lớn nhất là phá quy tắc "main phải có thể phát hành" bằng cách để công việc dở ngồi trong main. Feature flags giúp, nhưng hãy để chúng tắt theo mặc định và xác minh hotfix mà không bật các feature không liên quan.

Hotfix với GitFlow

Trong GitFlow, hotfix thường bắt đầu từ main (production), rồi phải merge lại vào develop để fix không bị mất.

Một luồng an toàn:

• Tạo nhánh hotfix/* từ main tại tag production.
• Sửa và phát hành (từ nhánh hotfix hoặc sau khi merge vào main).
• Merge hotfix vào main và cả develop.
• Nếu có release/*, merge vào đó nữa.

Thất bại phổ biến nhất là quên một trong những merge đó. Một tuần sau, bug "quay lại" vì develop chưa có patch.

Một quy tắc đơn giản ngăn hầu hết: hotfix chưa xong cho tới khi nó được merge vào mọi nhánh lâu dài sẽ ship tiếp.

Giữ môi trường QA ổn định (mà không chặn đội)

Phát hành hàng tuần sụp đổ khi "QA" nghĩa là "bất cứ thứ gì được deploy ngay lúc này." Hãy đặt tên môi trường và giao cho mỗi môi trường một nhiệm vụ: dev cho phản hồi nhanh, QA cho test đội, staging cho kiểm tra release, prod cho khách hàng. Nếu bạn không thể giải thích mục đích môi trường trong một câu, mọi người sẽ dùng sai.

Quy tắc ngăn mục tiêu di động

QA ổn định ít liên quan đến mô hình nhánh hơn đến thứ bạn deploy.

Trong trunk-based, đừng deploy các commit ngẫu nhiên lên QA. Deploy một candidate cố định (build có tag, số build hoặc nhánh release-candidate ngắn hạn) đã qua các kiểm tra giống nhau. QA có thứ cố định để test, ngay cả khi dev tiếp tục trên main.

Trong GitFlow, QA thường theo dõi nhánh release. Bẫy là để nhánh release tiếp tục thay đổi sau khi QA bắt đầu. Khi QA bắt đầu, hãy coi nhánh release như một hợp đồng: chỉ chấp nhận fix đã duyệt và chỉ theo quy trình rõ ràng.

Một tập quy tắc nhỏ giữ cả hai cách predictable:

• Deploy lên QA chỉ từ build đã pass.
• Ghim phiên bản được deploy (tag, số build hoặc head nhánh release) và công bố nó.
• Giới hạn thay đổi QA chỉ cho bug fixes, không cho tính năng mới.
• Reset dữ liệu test theo lịch và ghi lại thứ bị xóa.
• Giữ cấu hình dưới dạng code (biến và template) để giảm drift môi trường.

Nếu đội bạn dùng AppMaster cho một phần build, vẫn áp dụng nguyên tắc: tạo lại và deploy một build cụ thể cho QA, không một tập thay đổi liên tục.

Khi nhiều đội cùng dùng QA

Một môi trường QA chung trở thành cổ chai khi hai đội cần các phiên bản khác nhau. Nếu bạn không đủ tài nguyên để có nhiều môi trường QA, thêm quy tắc đặt chỗ nhẹ: một đội sở hữu QA trong khoảng thời gian, và đội khác dùng dev hoặc staging. Feature flags cũng hữu ích vì công việc chưa hoàn tất có thể deploy mà không hiển thị cho tester.

Ví dụ: Đội A đang xác nhận candidate release hàng tuần, nên QA ghim ở build 1842 cho đến khi sign-off. Đội B tiếp tục merge fix, nhưng các thay đổi đó chờ candidate kế tiếp thay vì làm dịch chuyển mục tiêu QA giữa chu kỳ.

Từng bước: chọn workflow đội bạn có thể theo mỗi tuần

Ghi ra "phát hành hàng tuần" nghĩa là gì với bạn. Chọn ngày và giờ release, quyết định mức rủi ro chấp nhận được (ví dụ, "không có bug P1 đang tồn tại"), và ghi lại kích thước đội cùng múi giờ. Điều này ngăn tranh luận nhánh biến thành tranh luận ưu tiên.

Chọn một mô hình cơ bản và cam kết dùng trong một tháng. Đừng trộn mô hình ngay ngày đầu. Trộn thường thêm quy tắc mà không giảm bất ngờ.

Một workflow hàng tuần đơn giản bạn có thể điều chỉnh:

• Giữ thời gian sống của nhánh ngắn (vài giờ đến 1-2 ngày) và merge ít nhất hàng ngày.
• Thêm hàng rào an toàn: CI nhanh, review ngắn, và một tập test tự động nhỏ bắt lỗi thật sự.
• Quyết định cách kiểm soát phạm vi: feature flags, một nhánh release ngắn gần cuối tuần, hoặc tag cho commit phát hành chính xác.
• Xác định bước hotfix: ai được kích hoạt, kiểm tra gì cần, và fix được đưa lại vào dòng chính ra sao.
• Giữ QA ổn định: quyết định QA theo dõi gì (nhánh release hay candidate ghim) và không thay đổi giữa chừng trừ khi restart chu kỳ test.

Viết quy trình tối thiểu trên một trang. Ngắn đủ để người mới theo mà không cần họp. Điều này càng quan trọng nếu một phần đội làm việc trực quan (ví dụ trong AppMaster) và phần khác viết code, vì bàn giao thất bại khi quy tắc chỉ nằm trong đầu ai đó.

Ví dụ: phát hành hàng tuần thực tế trong cả hai mô hình

Hình dung một đội 6 người phát hành vào thứ Sáu. Hai tester QA chia sẻ một staging, nên nếu staging không ổn, testing dừng cho mọi người.

Một tuần bận rộn với GitFlow

Thứ Hai: ba dev hoàn thành tính năng và mở PR vào develop. QA bắt đầu test staging build từ develop.

Thứ Tư: đội cắt release/1.8 để bảo vệ shipment thứ Sáu. Công việc mới tiếp tục vào develop, nhưng QA tập trung vào build release.

Chiều thứ Năm: một bug muộn xuất hiện. Fix được đưa vào release/1.8 trước để QA retest nhanh. Rồi ai đó merge fix đó về develop, nơi thường xảy ra sai sót.

Nhịp điệu điển hình:

• Thứ Hai - Thứ Ba: feature merge vào develop, staging thay đổi thường xuyên.
• Thứ Tư: tạo release/1.8, staging chuyển sang build release.
• Thứ Năm: fix trong release/1.8, rồi merge lại vào develop.
• Thứ Sáu: merge release/1.8 vào main, tag và deploy.

Cùng tuần đó với trunk-based development

Tuần được định hình bởi các merge nhỏ, thường xuyên vào main. Tính năng được ship sau flags để công việc chưa hoàn thiện có thể merge mà không ảnh hưởng người dùng.

Thứ Hai đến Thứ Năm: dev merge thay đổi nhỏ hàng ngày. QA test một candidate ghim.

Thứ Ba: xuất hiện sự cố production. Hotfix là nhánh ngắn từ main, merge lại ngay sau review, rồi promoted lên production. Vì main là nguồn chân thực, không có bước merge ngược thêm.

Dù theo cách nào, đội cần quy tắc promote rõ:

• Staging chạy candidate ghim, không phải mọi commit mới.
• QA yêu cầu candidate mới khi sẵn sàng, không tự động.
• Chỉ các fix cho release thứ Sáu mới được đổi candidate.
• Mọi thứ khác chờ sau flags hoặc ở ngoài candidate.

Những sai lầm phổ biến tạo ra churn và QA không ổn định

Hầu hết đội không thất bại vì chọn mô hình "sai". Họ thất bại vì thói quen hàng ngày không khớp với mô hình, nên QA ồn ào và release cảm thấy ngẫu nhiên.

Vấn đề phổ biến là để nhánh tồn tại mấy ngày vì "chưa xong." Mã lệch khỏi main, xung đột tích tụ và QA test một hỗn hợp cũ-mới mà không ai tái tạo được.

Một lỗi khác là dùng GitFlow mà không thực sự freeze. Nhánh release lẽ ra để ổn định, nhưng đội vẫn lén thêm "một thay đổi nữa." Điều đó biến nhánh release thành một dòng chính thứ hai, và không ai biết QA đang ký gì.

QA cũng bất ổn khi được coi như nơi chứa build dở. Nếu mọi commit đi vào QA không theo quy tắc, tester mất thời gian đuổi theo mục tiêu di động thay vì xác nhận release.

Những sai lầm gây churn nhiều nhất:

• Nhánh feature sống lâu rồi merge muộn làm vỡ công việc không liên quan.
• Nhánh release vẫn chấp nhận tính năng mới.
• Không có đường promote rõ, nên build QA test không phải build ship.
• Hotfix làm vội rồi không merge lại mọi nơi.
• Môi trường không có chủ, không mục đích và không kế hoạch reset.

Giữ một bộ quy tắc mọi người lặp lại được:

• QA chỉ test một candidate ghim.
• Bạn promote cùng một artifact từ QA lên production.
• Mỗi môi trường có chủ và lịch reset.
• Hotfix quay về dòng chính trong cùng một ngày.

Checklist nhanh cho phát hành hàng tuần không bất ngờ

Phát hành hàng tuần hoạt động khi đội bạn có thể tự tin trả lời vài câu hỏi nhàm chán. Nếu trả lời "không" cho hai câu trở lên, mong chờ sửa muộn và QA bị giật.

• Có một nhánh bạn có thể deploy an toàn hôm nay không? Nó nên build, pass smoke test và tránh thay đổi nửa vời.
• PR có nhỏ và vào trong một hai ngày không? PR tồn đọng dài thường dẫn đến feedback cũ và xung đột lớn.
• QA test một build cố định chứ không phải mục tiêu di động? QA nên xác minh số build hoặc release candidate cụ thể.
• Bạn giữ công việc chưa hoàn thành ra khỏi release mà không ầm ĩ không? Feature flags, toggle cấu hình hoặc quy tắc cắt scope rõ ràng.
• Có ai đó chạy hotfix và rollback mà không phải phỏng đoán không? Một runbook ngắn tốt hơn kiến thức truyền miệng.

Nếu cần một mục tiêu đo lường: ghim QA vào một release candidate và giữ candidate đó không đổi ngoại trừ các fix có chủ ý.

Bước tiếp theo: chọn một thay đổi để thử vào tuần tới

Nếu đội bạn kẹt ở tranh luận trunk-based vs GitFlow, đừng thiết kế lại toàn bộ. Chọn một vấn đề mất thời gian nhất và chạy thí nghiệm nhỏ cho release tới.

Nếu xung đột merge là nỗi đau lớn nhất, rút ngắn thời sống nhánh ngay. Mục tiêu land công việc hàng ngày (hoặc cách nhật) và dùng feature flags khi cần.

Nếu bất ổn QA là vấn đề lớn, bắt đầu bằng ghim thứ QA test và định nghĩa bước promote đơn giản.

Một pilot nhẹ:

• Chọn một repo và một đội.
• Đặt giới hạn tuổi nhánh (ví dụ, không nhánh nào hơn 2 ngày).
• Ghim QA vào một build và chỉ thay đổi nó qua promote rõ ràng.
• Theo dõi ba số: thời gian giải quyết merge, giờ rework của QA và thời gian hotfix tới production.
• Review sau 2-4 tuần và điều chỉnh.

Nếu bạn muốn giảm áp lực release cho công cụ nội bộ hoặc portal khách hàng, nền tảng no-code như AppMaster (appmaster.io) cũng có thể giúp bằng cách sinh backend, web và app mobile sẵn sàng production từ thiết kế trực quan. Nó vẫn hưởng lợi từ cùng thói quen: thay đổi nhỏ, candidate QA ghim và đường promote rõ ràng.