Trunk-Based Development — khái niệm, nguyên tắc và làm việc trên một nhánh

Trunk-Based Development là gì?

Trunk-Based Development (TBD) là một phương pháp quản lý phiên bản trong đó tất cả nhà phát triển tích hợp các thay đổi của họ vào một nhánh chính duy nhất (trunk, main hoặc master) nhiều lần trong ngày. Không giống như Git Flow với các nhánh tính năng tồn tại lâu dài, TBD giảm thiểu thời gian sống của nhánh xuống còn vài giờ, hiếm khi 1–2 ngày. Mục tiêu chính là tránh “địa ngục hợp nhất” (merge hell), khi một tính năng lớn được hợp nhất vào trunk sau nhiều tuần phát triển.

Theo Google Cloud DevOps, 2024, Trunk-Based Development là một trong những thực hành chính của các đội DevOps hiệu suất cao. State of DevOps Report (Puppet, 2023) cho thấy các đội sử dụng TBD phục hồi sau sự cố nhanh hơn 30% và gặp lỗi nghiêm trọng trong sản xuất ít hơn 50%. TBD là bắt buộc cho Continuous Deployment.

Trunk-Based Development không có nghĩa là nhà phát triển commit trực tiếp vào trunk mà không có đánh giá. Trong TBD, sử dụng các nhánh tính năng ngắn hạn, sau khi tạo MR và đánh giá mã nhanh (trong vòng vài giờ), được hợp nhất vào trunk. Nếu đánh giá mất hơn một ngày, tính năng cần được chia thành các phần nhỏ hơn.

State of DevOps Report: dữ liệu về TBD

State of DevOps Report hàng năm (Puppet/DORA) theo dõi các thực hành của các đội hiệu suất cao. Từ năm 2015, TBD nằm trong top 3 thực hành tương quan với tần suất triển khai cao (deploy frequency) và thời gian phục hồi thấp (MTTR). Các đội thực hành TBD triển khai mã thường xuyên hơn 2–3 lần và phục hồi sau sự cố nhanh hơn 30% (DORA, 2023).

Feature Toggles: quản lý mã chưa hoàn thiện không cần nhánh

Feature Toggles (cờ tính năng, feature flags) là cơ chế bật và tắt chức năng mà không thay đổi mã. Trong TBD, feature toggles thay thế nhánh tính năng: nhà phát triển commit mã chưa hoàn thiện vào trunk nhưng ẩn nó sau một cờ có điều kiện. Khi tính năng sẵn sàng hiển thị, cờ được chuyển đổi trong cấu hình mà không cần triển khai lại.

Theo Martin Fowler, 2024, feature toggles được chia thành bốn loại: release toggles (quản lý khả năng hiển thị tính năng), experiment toggles (kiểm thử A/B), ops toggles (quản lý tham số vận hành) và permission toggles (truy cập dựa trên vai trò). Trong các dự án di động, release toggles đặc biệt hữu ích: chức năng mới bị ẩn cho đến ngày phát hành, nhưng mã đã có trong trunk và đi qua CI/CD.

// Feature Toggle trong Android trên Kotlin
object FeatureManager {
    private val remoteConfig = FirebaseRemoteConfig.getInstance()

    fun isEnabled(key: String): Boolean {
        return remoteConfig.getBoolean(key)
    }
}

// Sử dụng trong mã
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD trong Trunk-Based Development: thực hành bắt buộc

Continuous Integration (CI) là thành phần quan trọng nhất của TBD. Mỗi lần push vào trunk (hoặc vào nhánh tạm thời trước MR) kích hoạt một pipeline hoàn chỉnh: build, kiểm thử đơn vị, kiểm thử tích hợp, linters, phân tích tĩnh, kiểm tra độ phủ mã. Nếu ít nhất một giai đoạn thất bại, tác giả sửa mã trước commit tiếp theo. “Trunk hỏng — phát triển dừng lại” là quy tắc chính của TBD.

Theo Jez Humble, Continuous Delivery, 2024, Trunk-Based Development yêu cầu một pipeline CI hoàn thành trong 10–15 phút. Nếu build mất nhiều thời gian hơn, nhà phát triển commit ít thường xuyên hơn, điều này phá hủy ý nghĩa của TBD. Trong các dự án di động, build Android và iOS có thể mất 20–30 phút, làm cho TBD kém tiện lợi. Trong những trường hợp như vậy, các đội sử dụng Short-Lived Feature Branches (nhánh 1 ngày) với CI ngay lập tức.

# GitHub Actions cho TBD (Android)
name: CI - TBD Check
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew testDebugUnitTest
      - name: Static analysis
        run: ./gradlew ktlintCheck detekt

Nhánh ngắn hạn: quy tắc làm việc trong TBD

Nhánh ngắn hạn (short-lived branches) là sự thỏa hiệp giữa TBD thuần túy (commit trực tiếp vào trunk) và Git Flow. Một nhánh sống không quá 1–2 ngày, chứa các thay đổi của 1–3 commit và sau khi đánh giá (không quá 4 giờ chờ đợi) được hợp nhất vào trunk. Nếu một tính năng cần nhiều thời gian hơn, nó được chia thành các tác vụ con, mỗi tác vụ có nhánh ngắn hạn riêng.

Theo TBD Documentation, 2024, quy tắc nhánh ngắn hạn: nhánh được tạo từ trunk mới (không quá 1 giờ), không đồng bộ với trunk qua merge/rebase (nếu quá 4 giờ, một nhánh mới được tạo), MR/PR được tạo ngay sau commit đầu tiên (ngay cả khi công việc chưa hoàn thành — dưới dạng Draft).

Pre-tested Commits: commit có bảo đảm

Đối với Trunk-Based Development, kỹ thuật pre-tested commits rất quan trọng: nhà phát triển chạy pipeline CI trong nhánh của mình trước khi commit, và chỉ sau trạng thái xanh, commit mới đến được trunk. Trong GitLab, điều này được thực hiện qua Merge Request pipelines với tùy chọn “Merge when pipeline succeeds”. Trong GitHub — qua branch protection rules với Required status checks. Điều này đảm bảo trunk không bao giờ chứa mã hỏng.

• 1–2 ngày — thời gian sống tối đa của short-lived branch
• 1–3 commit — kích thước thay đổi tối ưu
• 4 giờ — thời gian chờ đánh giá mã tối đa
• Tạo MR ngay sau commit đầu tiên, ngay cả ở trạng thái Draft

Branch by Abstraction: thay thế mã không cần rẽ nhánh

Branch by Abstraction là kỹ thuật cho phép thay thế hoặc thay đổi đáng kể một phần của hệ thống mà không tạo nhánh tính năng tồn tại lâu dài. Thay vì rẽ nhánh trong Git, nhà phát triển tạo một abstraction (giao diện) mà dưới đó cả triển khai cũ và mới đều hoạt động. Dần dần, tất cả người tiêu dùng được chuyển sang triển khai mới, sau đó triển khai cũ được loại bỏ.

Theo Branch by Abstraction, 2024, các giai đoạn của Branch by Abstraction: 1) tạo abstraction cho thành phần cần thay thế, 2) triển khai phiên bản mới dưới abstraction, 3) chuyển người tiêu dùng sang triển khai mới qua cấu hình, 4) loại bỏ triển khai cũ. Tất cả các bước được commit vào trunk theo từng phần nhỏ, mỗi phần không làm hỏng CI/CD.

TBD so với Git Flow: so sánh cách tiếp cận

Trunk-Based Development và Git Flow là hai cách tiếp cận đối lập trong quản lý nhánh. Git Flow sử dụng nhánh dài hạn và phân cấp chặt chẽ, TBD sử dụng một nhánh duy nhất và chu kỳ tích hợp ngắn. Sự lựa chọn giữa chúng phụ thuộc vào quy mô đội, tần suất phát hành và mức độ tự động hóa CI/CD.

Sai lầm điển hình khi triển khai Trunk-Based Development

Sai lầm TBD thường liên quan đến CI/CD không đầy đủ hoặc kỷ luật commit yếu. Sai lầm đầu tiên là triển khai TBD mà không có CI, nó sẽ hỏng ngay từ commit thất bại đầu tiên. Nếu trunk không thể sửa trong vòng 15 phút, đội mất niềm tin vào quy trình và quay lại nhánh dài. Sai lầm thứ hai là cho phép nhánh dài hạn “chỉ cho tính năng này”, điều này phá hủy toàn bộ khái niệm.

Theo Paul Hammant, 2023, sai lầm thứ ba là tính mô-đun mã kém. Trunk-Based Development yêu cầu mã được chia thành các mô-đun độc lập. Nếu một thay đổi trong một lớp làm hỏng ba mô-đun khác, nhà phát triển không thể commit theo từng phần nhỏ. Sai lầm thứ tư là bỏ qua feature toggles: cố gắng commit mã chưa hoàn thiện mà không có cờ sẽ làm hỏng trunk cho toàn đội.

Trunk-Based Development trong phát triển di động

Trunk-Based Development trong các dự án di động có đặc thù do thời gian build dài (20–30 phút cho Android và iOS) và yêu cầu chất lượng nghiêm ngặt. Google và Spotify sử dụng TBD trong phát triển di động, áp dụng nhánh ngắn hạn với CI bắt buộc trước khi hợp nhất. Feature toggles được quản lý qua Firebase Remote Config hoặc LaunchDarkly.

Theo LaunchDarkly Docs, 2024, trong phát triển di động, TBD mang lại lợi thế: các tính năng được kiểm thử trong trunk cùng với phần còn lại của mã trước ngày phát hành, giảm rủi ro vấn đề tích hợp. Nếu pipeline CI mất hơn 15 phút, nhánh ngắn hạn 1 ngày với CI tự động ở mỗi lần push là tối ưu. Đối với Apple App Store và Google Play, TBD yêu cầu thiết lập triển khai theo giai đoạn qua feature toggles.

Feature Flags như một dịch vụ: LaunchDarkly và Firebase

Để quản lý feature toggles trong TBD, các nền tảng được sử dụng: LaunchDarkly (doanh nghiệp, đầy đủ tính năng), Firebase Remote Config (miễn phí cho dự án nhỏ), Split.io (mã nguồn mở). Chúng cung cấp: kích hoạt tính năng theo tỷ lệ người dùng, kiểm thử A/B, giám sát sử dụng và tự động tắt khi có lỗi. Trong các dự án di động, Firebase Remote Config là lựa chọn phổ biến nhất nhờ tích hợp với Firebase và ngưỡng miễn phí lên đến 1000 người dùng.