Kas yra trunk-based development ir kaip jis palaiko CI/CD?

Question

IT Interview Practice · Accepted Answer

**Trunk-based development** yra šakos strategija, kurioje kūrėjai **dažnai integruoja nedideles pokyčius į vieną pagrindinę šaką (trunk)**, naudodami labai trumpaamžes šakas (arba tiesiogiai deldami). Tai yra stipriai susijusi su aukšto pasiteisingumo CI/CD, nes ji maksimaliai padidina nuolatinę integraciją.

## Kas yra trunk-based development

```text
Developers commit small, frequent changes to a SINGLE shared branch (trunk/main):
  → very SHORT-LIVED branches (merged within hours or a day) — or commit directly
  → integrate continuously (multiple times a day) into trunk
  → trunk is kept always RELEASABLE (working, deployable)
→ vs long-lived feature branches that diverge for days/weeks before merging.
```

## Kodėl tai gerai palaiko CI/CD

```text
✓ MAXIMIZES continuous INTEGRATION — frequent small merges = the essence of CI
  (catch integration issues immediately; tiny, easy-to-resolve conflicts)
✓ AVOIDS "merge hell" — no long-lived branches diverging → no big painful merges
✓ Small changes = lower risk, easier review, faster feedback
✓ Keeps trunk always deployable → enables continuous DELIVERY/deployment
→ Research (DORA) links trunk-based development to high delivery performance.
```

## Nebaigto darbo tvarkymas

```text
How to commit to trunk frequently when features aren't done?
  ✓ FEATURE FLAGS → merge incomplete features hidden behind off flags (don't break trunk)
  ✓ Break work into small, independently-mergeable, non-breaking pieces
  ✓ Branch by ABSTRACTION → introduce changes incrementally behind abstractions
→ The discipline: integrate small, keep trunk working, hide incomplete work.
```

## Trunk-based ir feature-branch (Git Flow) palyginimas

```text
TRUNK-BASED → short-lived branches, frequent integration, continuous delivery,
  feature flags — favored for high-velocity CI/CD
GIT FLOW (long-lived branches) → more structured, release-oriented, but longer
  divergence and bigger merges → less continuous
→ Trunk-based is generally preferred for true CI/CD; Git Flow for scheduled releases.
```

## Kodėl tai svarbu

Supratimas apie trunk-based development yra vertingas aukštesnio lygio žinios, nes jis yra **stipriai susijęs su aukšto pasiteisingumo CI/CD** ir atstovauja svarbią šakų filosofiją, todėl jis naudingas norint suprasti efektyvias pristatymo praktikas.

Pagrindinė idėja — kūrėjai integruoja **nedideles pokyčius dažnai į vieną trunk** naudodami trumpaamžes šakas (o ne ilgaamžes feature branches, kurios skiriasi dienomis ar savaitėmis) — tiesiogiai **maksimaliai padidina nuolatinę integraciją**, tai yra CI esmė: dažni maži merge'ai iš karto aptinka integracijos problemas ir sukuria nedideles, lengvai išsprendžiamas konflikto situacijas, **vengiama "merge hell"** iš ilgai skirtingų šakų.

Supratimas apie **kodėl tai gerai palaiko CI/CD** (maksimaliai padidina integraciją, vengia didelių skausmingų merge'ų, laikausi mažų ir žemo rizikos pokyčių, ir nuolat palaikaisi deployable trunk'ą, kad būtų galima nuolatinis delivery) paaiškina, kodėl jis yra pageidaujamas aukšto greičio pristatymo — ir nepralyginamai, **DORA tyrimai susieja trunk-based development su aukštu pristatymo pasiteisiningumu**, suteikdami jam empirinę paramą.

Supratimas apie **kaip tvarkytis nebaigtu darbu** tuo metu, kai dažnai deldžiate trunk'ą — naudojant **feature flags** (nebaigtu feature'ų merge'as paslėptas už off žymų, kad trunk lieka veikiantis), skaidant darbą į mažus nepriklausomai suderinamus gabalus ir abstrakcinius šakas — yra pagrindinė praktinė disciplina, dėl kurios trunk-based development yra galimas (jam reikalingos šios technikos, kad galima būtų integruoti nebaigtuš darbus nesulaužant trunk'o).

Supratimas apie **kontrastą su feature-branch/Git Flow** metodais (trunk-based aukšto greičio nuolatiniams pristatymo; Git Flow ilgaamžės šakos strukturuotiems, bet ne itin nenuolatiniams, suplanuotiems leidimams) atspindi tvirtą sprendimą dėl šakų strategijos.

Kadangi trunk-based development yra šakų metodas, kuris geriausiai leidžia tikrą nuolatinę integraciją ir pristatymą (tyrimai jį susieja su aukštu pasiteisiningumu), ir kadangi jo supratimas, kodėl jis palaiko CI/CD ir kaip jį praktikuoti (feature flags, maži pokyčiai) atspindi supratimą apie aukšto pasiteisingumo pristatymą, trunk-based development supratimas yra vertingas aukštesnio lygio žinios — svarbi praktika, susijusi su efektyviu CI/CD, atspindinti pristatymo praktiniu brandumą, kurio tikimasi iš aukštesnio lygio specialistų, kurie formuoja, kaip komandoms integruoti ir pristatyti.

Kas yra trunk-based development

Kodėl tai gerai palaiko CI/CD

Nebaigto darbo tvarkymas

Trunk-based ir feature-branch (Git Flow) palyginimas

Kodėl tai svarbu

Susiję klausimai