Monorepo React Native versijų valdymas

Monorepo React Native Version Control (Git Flow)

Teisingas darbo procesas su Git (VCS)

Correct Flow with Git (Version Control System)

Auksinė taisyklė

The Golden Rule

Netestuotas kodas NIEKADA negali būti sujungtas į Main šaką.

Untested code must NEVER be merged into Main.

Main šaka visada privalo būti paruošta leidimui.
Main should always be in a deployable state.

Domino efektas / Poveikio spindulys

The "Domino Effect" / Blast Radius

flowchart TD subgraph Mistake [The Mistake / Klaida] Dev[Developer] Untested[Untested Feature Branch] end subgraph Impact [Monorepo Impact / Poveikis] Shared[Shared UI/Logic Library] AppA[React Native App A] AppB[React Native App B] Web[Web Dashboard] end subgraph Result [Consequences / Pasekmės] CI[CI Pipeline / Builds] Block[❌ TEAM BLOCKED] Crash[❌ RUNTIME CRASH] end Dev -- Commits code --> Untested Untested -- "Merged without QA" --> Main Main -- Updates --> Shared Shared -- Consumed by --> AppA & AppB & Web AppA & AppB -- "Build Triggered" --> CI CI -- "Bug detected too late" --> Block Block -- "Cannot Release" --> Dev AppA -.-> Crash style Block fill:#ffcccc,stroke:#ff0000 style Crash fill:#ffcccc,stroke:#ff0000

Blogas Git procesas (Anti-pattern)

Bad Git Flow (Anti-pattern)

gitGraph commit id: "v1.0" commit id: "Dev_A_Feature" commit id: "CRITICAL_BUG" type: REVERSE commit id: "Emergency_Fix" tag: "Hotfix" commit id: "Main_Broken"

Tiesioginiai kėlimai į main užblokuoja visos komandos darbą.
Direct commits to main block everyone during failures.

Geras Git procesas (Best Practice)

Good Git Flow (Best Practice)

gitGraph commit id: "Initial" commit id: "Stable_v1.0" branch feature/login checkout feature/login commit id: "Work_In_Progress" commit id: "QA_Testing" commit id: "QA_Approved" type: HIGHLIGHT checkout main merge feature/login id: "Safe_Merge" tag: "v1.1" commit id: "Main_Stable"

Funkcijos patikrinamos izoliacijoje prieš pasiekiant pagrindinę šaką.
Features are verified in isolation before reaching the "Golden Master".

Kaip tvarkingai pradėti naują užduotį?

How to properly start a new task? (Step 0)

1. Sinchronizacija (Sync)

Prieš kuriant naują šaką, visada atsisiųskite naujausią `main` šakos versiją (`git pull`). Niekada nepradėkite darbo nuo pasenusio kodo.

2. Teisingas šaltinis (Base Branch)

Šaką kurkite TIK iš `main`. Niekada nekurkite darbinės šakos iš `staging` ar kito kolegos nebaigtos šakos, nebent tai būtina dėl priklausomybių.

3. Poveikio vertinimas (Impact check)

Jei planuojate keisti kodą `shared` aplankuose, iškart įsivertinkite, kurios aplikacijos bus paveiktos. Tai padės QA komandai geriau suplanuoti testavimą.

Mažų pataisymų grupavimo strategija (Batching)

Batching Strategy for Small Fixes

gitGraph commit id: "v1.0" branch fix-bundle checkout fix-bundle commit id: "fix-ui" commit id: "fix-text" commit id: "fix-logic" commit id: "QA_VERIFIED" type: HIGHLIGHT checkout main merge fix-bundle tag: "v1.0.1"

Sugrupuokite smulkius pataisymus į vieną šaką, kad sutaupytumėte laiko build'ams.
Group small fixes into one QA-ready branch to save build time.

Staging šakos naudojimas QA efektyvumui

Staging Branch Strategy for QA Efficiency

1. Lygiagretus testavimas (Parallel Testing)

QA žino, kad „šiandienos versija yra staging šakoje“. Jie gali ramiai testuoti visą dieną, kol programuotojai kaupia naujus pataisymus kitai dienai.

2. Mažiau „Context Switching“

Kadangi dirba tik 2 programuotojai, galite drąsiai sujungti abiejų darbus į staging. Jei build'as trunka 30 min., sutaupote po pusvalandį kiekvienam programuotojui kasdien.

Staging proceso srautas praktikoje

Practical Staging Workflow Flow

flowchart LR A[Dev: feat/fix-a] --> B[Code Review] B --> C[Merge to staging] D[Dev: feat/fix-b] --> E[Code Review] E --> C C --> F[CI/CD: Binary Build] F --> G[QA: App Center / TestFlight] G -- "QA OK" --> H[Merge staging to main]

Automation: QA gets Slack/Discord notifications automatically.

1. Monorepo daugybos efektas

The Monorepo Multiplier

  • Bendra infrastruktūra: Pakeitimai bendruose aplankuose naudojami keliose aplikacijose vienu metu.
    Shared Infrastructure: Changes in shared folders affect multiple apps.
  • Krosplatforminė rizika: UI pataisymas gali veikti iOS, bet sulaužyti Android versiją.
    Cross-platform Risk: A fix might work on iOS but crash Android.

2. Konteksto keitimo kaina

The Cost of Context Switching

10 kartų pigiau: Ištaisyti klaidą PR stadijoje (prieš sujungimą).
10x Cheaper: Fixing a bug during PR / before merge.

Brangu: Radus klaidą Main šakoje, visa komanda priversta stabdyti darbus.
Expensive: Finding bugs in Main forces the whole team to stop feature work.

3. React Native specifika

React Native Specifics: Build Pain

  • Binariniai failai: Native moduliai (Swift/Java) reikalauja ilgo kompiliavimo (IPA/APK).
    Binary Builds: Native modules require slow compilation.
  • Atšaukimo sunkumai: Negalite akimirksniu atšaukti išleistos versijos; vartotojai turi atsisiųsti naujinimą.
    Hard Rollbacks: You cannot instantly "undo" a binary release.

4. Organizacijos darbo sustabdymas

Freezing the Organization

Kritinė būsena: Negalima net pradėti naujo darbo

Jei `main` yra sugadintas, programuotojai negali sukurti „švarios“ darbinės šakos naujai užduočiai. Bet koks naujas darbas paveldės klaidą, todėl jo nebus įmanoma teisingai pratestuoti.

Blokuojami skubūs pataisymai

Kiti programuotojai negali saugiai sujungti savo kritinių pataisymų, kol nebus išvalytas `main` – visas inžinerinis procesas sustoja.

A broken main branch freezes the entire organization. You cannot even branch off from a clean state.

1 Variantas: Darbo procesas BE Staging šakos

Option 1: Workflow without Staging branch

  1. Dev: Sukuria šaką iš švaraus `main` ir atlieka darbą.
  2. Review: Kitas programuotojas peržiūri ir patvirtina kodą.
  3. QA: Generuojamas binarinis build'as (.apk/.ipa) TIESIOGIAI iš darbinės šakos.
  4. QA Approval: Gavus patvirtinimą, šaka sujungiama su `main`.

Best for: Critical one-off fixes or very urgent features.

2 Variantas: Darbo procesas SU Staging šaka

Option 2: Workflow with Staging branch (Recommended)

  1. Devs: Keli programuotojai sukuria šakas iš `main`, atlieka darbus ir gauna patvirtinimus.
  2. Integration: Visi patvirtinti darbai sujungiami į `staging` šaką (pvz., kartą per dieną).
  3. Batch QA: Generuojamas VIENAS build'as iš `staging`, kuriame yra visi tos dienos pataisymai.
  4. Final Approval: QA patikrina visą paketą. Jei viskas gerai, `staging` sujungiamas su `main`.

Best for: Daily efficiency, batching small fixes, and reducing build wait times.

Main šaka = Stabilumas 🟢

Main Branch = Stability

Patikra prieš sujungimą yra vienintelis būdas sėkmingai plėsti Monorepo projektą.
Verification before merge is the only way to scale a Monorepo.

Ačiū už dėmesį!

Thank you for your attention!

Paruošta Pauliaus Jarošiaus

su Gemini pagalbos privalumais