Trunk-Based Development — τι είναι, αρχές και εργασία σε έναν κλάδο

Τι είναι το Trunk-Based Development;

Trunk-Based Development (TBD) — μεθοδολογία διαχείρισης εκδόσεων όπου όλοι οι προγραμματιστές ενσωματώνουν τις αλλαγές τους σε έναν ενιαίο κύριο κλάδο (trunk, main ή master) πολλές φορές την ημέρα. Σε αντίθεση με το Git Flow με τους μακρόβιους feature-κλάδους του, το TBD ελαχιστοποιεί τη διάρκεια ζωής των κλάδων σε λίγες ώρες, σπάνια σε 1–2 ημέρες. Κύριος στόχος είναι η αποφυγή της "κόλασης συγχώνευσης" (merge hell), όταν μια μεγάλη λειτουργία συγχωνεύεται με το trunk μετά από εβδομάδες ανάπτυξης.

Σύμφωνα με το Google Cloud DevOps, 2024, το Trunk-Based Development είναι μία από τις βασικές πρακτικές των υψηλών επιδόσεων ομάδων DevOps. Η έρευνα State of DevOps Report (Puppet, 2023) έδειξε ότι οι ομάδες που χρησιμοποιούν TBD ανακτούν 30% γρηγορότερα από αποτυχίες και αντιμετωπίζουν 50% λιγότερο συχνά κρίσιμα ελαττώματα στην παραγωγή. Το TBD είναι υποχρεωτικό για το Continuous Deployment.

Trunk-Based Development δεν σημαίνει ότι οι προγραμματιστές κάνουν commit απευθείας στο trunk χωρίς επαλήθευση. Στο TBD χρησιμοποιούνται βραχύβιοι feature-κλάδοι που μετά τη δημιουργία MR και γρήγορη ανασκόπηση κώδικα (μέσα σε λίγες ώρες) συγχωνεύονται στο trunk. Εάν η ανασκόπηση διαρκεί περισσότερο από μία ημέρα — σημαίνει ότι η λειτουργία πρέπει να χωριστεί σε μικρότερα μέρη.

State of DevOps Report: δεδομένα για το TBD

Η ετήσια State of DevOps Report (Puppet/DORA) παρακολουθεί τις πρακτικές ομάδων υψηλών επιδόσεων. Από το 2015, το TBD βρίσκεται στις top 3 πρακτικές που συσχετίζονται με υψηλή συχνότητα παράδοσης (deploy frequency) και χαμηλό χρόνο αποκατάστασης (MTTR). Οι ομάδες που εφαρμόζουν TBD αναπτύσσουν κώδικα 2–3 φορές συχνότερα και ανακτούν 30% γρηγορότερα από αποτυχίες (DORA, 2023).

Feature Toggles: διαχείριση μη ολοκληρωμένου κώδικα χωρίς κλάδους

Feature Toggles (σημαίες λειτουργιών, feature flags) — μηχανισμός ενεργοποίησης και απενεργοποίησης λειτουργικότητας χωρίς αλλαγή κώδικα. Στο TBD, τα feature toggles αντικαθιστούν τους feature-κλάδους: ο προγραμματιστής κάνει commit τον μη ολοκληρωμένο κώδικα στο trunk αλλά τον κρύβει πίσω από μια υπό συνθήκη σημαία. Όταν η λειτουργία είναι έτοιμη για προβολή, η σημαία αλλάζει στη διαμόρφωση χωρίς επαναληπτική ανάπτυξη.

Σύμφωνα με το Martin Fowler, 2024, τα feature toggles χωρίζονται σε τέσσερις τύπους: release toggles (διαχείριση ορατότητας λειτουργίας), experiment toggles (A/B δοκιμές), ops toggles (διαχείριση λειτουργικών παραμέτρων) και permission toggles (πρόσβαση βάσει ρόλων). Σε κινητά έργα, τα release toggles είναι ιδιαίτερα χρήσιμα: η νέα λειτουργικότητα είναι κρυμμένη μέχρι την ημερομηνία κυκλοφορίας, αλλά ο κώδικας είναι ήδη στο trunk και περνά από CI/CD.

// Feature Toggle στο Android σε Kotlin
object FeatureManager {
    private val remoteConfig = FirebaseRemoteConfig.getInstance()

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

// Χρήση στον κώδικα
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD στο Trunk-Based Development: υποχρεωτικές πρακτικές

Continuous Integration (CI) — το πιο σημαντικό συστατικό του TBD. Κάθε push στο trunk (ή σε προσωρινό κλάδο πριν από MR) ξεκινά ένα πλήρες pipeline: build, μοναδιαίες δοκιμές, δοκιμές ενσωμάτωσης, linters, στατική ανάλυση, έλεγχος κάλυψης κώδικα. Εάν τουλάχιστον ένα στάδιο αποτύχει — ο συγγραφέας των αλλαγών διορθώνει τον κώδικα πριν από το επόμενο commit. "Σπασμένο trunk — σταματημένη ανάπτυξη" είναι ο κύριος κανόνας του TBD.

Σύμφωνα με το Jez Humble, Continuous Delivery, 2024, το Trunk-Based Development απαιτεί CI pipeline που εκτελείται σε 10–15 λεπτά. Εάν το build διαρκεί περισσότερο — οι προγραμματιστές κάνουν commit λιγότερο συχνά, καταστρέφοντας την έννοια του TBD. Σε κινητά έργα Android και iOS, το build μπορεί να διαρκέσει 20–30 λεπτά, καθιστώντας το TBD λιγότερο βολικό. Σε τέτοιες περιπτώσεις, οι ομάδες χρησιμοποιούν Short-Lived Feature Branches (κλάδους 1 ημέρας) με άμεσο CI.

# GitHub Actions για 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

Βραχύβιοι κλάδοι: κανόνες εργασίας στο TBD

Βραχύβιοι κλάδοι (short-lived branches) — συμβιβασμός μεταξύ καθαρού TBD (άμεσα commits στο trunk) και Git Flow. Ο κλάδος ζει όχι περισσότερο από 1–2 ημέρες, περιέχει αλλαγές για 1–3 commits και μετά την ανασκόπηση (όχι περισσότερο από 4 ώρες αναμονής) συγχωνεύεται στο trunk. Εάν η λειτουργία απαιτεί περισσότερο χρόνο — χωρίζεται σε υποεργασίες, κάθε μία με τον δικό της βραχύβιο κλάδο.

Σύμφωνα με το TBD Documentation, 2024, κανόνες βραχύβιων κλάδων: ο κλάδος δημιουργείται από φρέσκο trunk (όχι παλαιότερο από 1 ώρα), δεν συγχρονίζεται με το trunk μέσω merge/rebase (εάν έχουν περάσει περισσότερες από 4 ώρες — δημιουργείται νέος κλάδος), το MR/PR δημιουργείται αμέσως μετά το πρώτο commit (ακόμη κι αν η εργασία δεν έχει ολοκληρωθεί — ως Draft).

Pre-tested commits: commits με εγγύηση

Για το Trunk-Based Development είναι σημαντική η τεχνική pre-tested commits: ο προγραμματιστής πριν από το commit εκτελεί το CI pipeline στον δικό του κλάδο και μόνο μετά από πράσινη κατάσταση το commit εισέρχεται στο trunk. Στο GitLab αυτό υλοποιείται μέσω Merge Request pipelines με την επιλογή "Merge when pipeline succeeds". Στο GitHub — μέσω branch protection rules με Required status checks. Αυτό εγγυάται ότι το trunk δεν περιέχει ποτέ σπασμένο κώδικα.

• 1–2 ημέρες — μέγιστη διάρκεια ζωής short-lived branch
• 1–3 commits — βέλτιστο μέγεθος αλλαγών
• 4 ώρες — μέγιστος χρόνος αναμονής για ανασκόπηση κώδικα
• Δημιουργήστε MR αμέσως μετά το πρώτο commit, ακόμη και σε κατάσταση Draft

Branch by Abstraction: αντικατάσταση κώδικα χωρίς διακλάδωση

Branch by Abstraction — τεχνική που επιτρέπει την αντικατάσταση ή σημαντική τροποποίηση ενός μέρους του συστήματος χωρίς δημιουργία μακρόβιου feature-κλάδου. Αντί για διακλάδωση στο Git, ο προγραμματιστής δημιουργεί μια αφαίρεση (διεπαφή) υπό την οποία λειτουργούν τόσο η παλιά όσο και η νέα υλοποίηση. Σταδιακά, όλοι οι καταναλωτές μεταφέρονται στη νέα υλοποίηση, μετά την οποία η παλιά διαγράφεται.

Σύμφωνα με το Branch by Abstraction, 2024, στάδια του Branch by Abstraction: 1) δημιουργήστε μια αφαίρεση για το υπό αντικατάσταση στοιχείο, 2) υλοποιήστε τη νέα έκδοση υπό την αφαίρεση, 3) μεταφέρετε τους καταναλωτές στη νέα υλοποίηση μέσω διαμόρφωσης, 4) διαγράψτε την παλιά υλοποίηση. Όλα τα βήματα γίνονται commit στο trunk σε μικρές δόσεις, καμία από τις οποίες δεν σπάει το CI/CD.

TBD vs Git Flow: σύγκριση προσεγγίσεων

Trunk-Based Development και Git Flow — δύο αντίθετες προσεγγίσεις διαχείρισης κλάδων. Το Git Flow χρησιμοποιεί μακρόβιους κλάδους και αυστηρή ιεραρχία, το TBD — έναν κλάδο και σύντομους κύκλους ενσωμάτωσης. Η επιλογή μεταξύ τους εξαρτάται από το μέγεθος της ομάδας, τη συχνότητα κυκλοφορίας και το επίπεδο αυτοματισμού CI/CD.

Τυπικά λάθη κατά την εφαρμογή του Trunk-Based Development

Λάθη TBD συνήθως σχετίζονται με ανεπαρκή CI/CD ή αδύναμη πειθαρχία commits. Το πρώτο λάθος — εφαρμογή TBD χωρίς CI, που σπάει στο πρώτο αποτυχημένο commit. Εάν το trunk δεν μπορεί να επιδιορθωθεί σε 15 λεπτά — η ομάδα χάνει την εμπιστοσύνη της στη διαδικασία και επιστρέφει σε μακρούς κλάδους. Δεύτερο — η επιτρεπτική ύπαρξη μακρόβιων κλάδων "αποκλειστικά για αυτή τη λειτουργία", που καταστρέφει ολόκληρη την ιδέα.

Σύμφωνα με το Paul Hammant, 2023, το τρίτο λάθος — η κακή αρθρωτότητα του κώδικα. Trunk-Based Development απαιτεί ο κώδικας να χωρίζεται σε ανεξάρτητες μονάδες. Εάν μια αλλαγή σε μια κλάση σπάει τρεις άλλες μονάδες — οι προγραμματιστές δεν μπορούν να κάνουν commit σε μικρές δόσεις. Τέταρτο — η αγνόηση των feature toggles: η απόπειρα commit μη ολοκληρωμένου κώδικα χωρίς σημαία οδηγεί στο σπάσιμο του trunk για ολόκληρη την ομάδα.

Trunk-Based Development στην κινητή ανάπτυξη

Trunk-Based Development σε κινητά έργα έχει ιδιαιτερότητες λόγω του μεγάλου χρόνου build (20–30 λεπτά για Android και iOS) και των αυστηρών απαιτήσεων ποιότητας. Οι Google και Spotify χρησιμοποιούν TBD στην κινητή ανάπτυξη, εφαρμόζοντας short-lived branches με υποχρεωτική διέλευση CI πριν από τη συγχώνευση. Τα feature toggles διαχειρίζονται μέσω Firebase Remote Config ή LaunchDarkly.

Σύμφωνα με το LaunchDarkly Docs, 2024, στην κινητή ανάπτυξη το TBD παρέχει πλεονέκτημα: οι λειτουργίες δοκιμάζονται στο trunk μαζί με τον υπόλοιπο κώδικα πριν από την ημερομηνία κυκλοφορίας, μειώνοντας τον κίνδυνο προβλημάτων ενσωμάτωσης. Εάν το CI pipeline διαρκεί περισσότερο από 15 λεπτά — τα short-lived branches 1 ημέρας με αυτόματο CI σε κάθε push είναι βέλτιστα. Για Apple App Store και Google Play, το TBD απαιτεί ρύθμιση σταδιακών κυκλοφοριών μέσω feature toggles.

Feature Flags ως υπηρεσία: LaunchDarkly και Firebase

Για τη διαχείριση feature toggles στο TBD χρησιμοποιούνται πλατφόρμες: LaunchDarkly (enterprise, πλήρης λειτουργικότητα), Firebase Remote Config (δωρεάν για μικρά έργα), Split.io (open-source). Παρέχουν: στοχευμένη ενεργοποίηση λειτουργιών ανά ποσοστό χρηστών, A/B δοκιμές, παρακολούθηση χρήσης και αυτόματη απενεργοποίηση σε σφάλματα. Σε κινητά έργα, το Firebase Remote Config είναι η πιο δημοφιλής επιλογή λόγω ενσωμάτωσης με το Firebase και του δωρεάν ορίου έως 1000 χρηστών.