Your SlideShare is downloading. ×
Verziókövető rendszerek alkalmazása fejlesztési projektekben
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Verziókövető rendszerek alkalmazása fejlesztési projektekben

926
views

Published on

Mi az, amit minden fejlesztőnek tudnia kellene, de szinte nincs egyetem, ahol oktatnák? Ezek a verziókövető rendszerek, amit minden jól működő fejlesztőcég alkalmaz.

Mi az, amit minden fejlesztőnek tudnia kellene, de szinte nincs egyetem, ahol oktatnák? Ezek a verziókövető rendszerek, amit minden jól működő fejlesztőcég alkalmaz.


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
926
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Verziókövetőrendszerek alkalmazásafejlesztési projektekben Gyöngyösi Péter, BalaBit
  • 2. Mi az a verziókezelés? Egy adathalmaz konzisztens állapotait és változását rögzíteni képes és azt visszakövethetővé tevő rendszer.
  • 3. Miért verziókezelünk? Mert egy nagyon jó eszköz. (és a jó eszközöket szeretjük)
  • 4. Hogy tudjuk, mi történt• mikor mi és hogyan került a kódba• látni a kontextust• ticketekkel, bugokkal összekötni a kódot• ad egy timeline-t
  • 5. Backup• nem kell félni a változtatásoktól• szimpla backup egy idő után töröl, ha te törölsz• könnyen vissza lehet nyerni bármi korábbi állapotot• olcsón ki lehet próbálgatni dolgokat• build-management alapvetése: mindent lehessen újrabuildelni!
  • 6. Regression-keresés• „Ez hogy működhetett valaha, és mikor törtük el?”
  • 7. Együttműködés• több ember dolgozik a projekten – valahogy össze kell fésülni a munkájuk• „Na és ezért kinek törjem el a kezét?”
  • 8. Mindez a gyakorlatban• miért a git?• kollaboráció• fejlesztés-tracking• backup• regression-keresés
  • 9. Miért a git?• gyors, effektív• sok hasznos tool létezik hozzá• az elosztottság rengeteg speciális helyzetben egy nagyon kényelmes, hasznos dolog• az open source világhoz ezer szállal kötődünk, ott meg egyre dominánsabb...
  • 10. Kollaboráció – a BalaBit• sok programnyelv, heterogén fejlesztőkörnyezet• security termékek → erős kontroll a mainline-on• kis csapatok...• ...de sok közös komponens csapatok közt• újrabuildelhetőség nagyon fontos• sok külső, open source függőség
  • 11. Kollaboráció – a cherry-pick mainline patch 6 ✓ dev-gyp• terméken, csapaton belül patch 5 ✓ jatekpatch 3 használjuk főleg ✓ gyp patch 2• alapkoncepció: patch 4 ✓ • fejlesztőnek/tesztelőnek patch 3 ✓ jatekpatch 2 saját ág, ami az ő játszótere • az integrálandó patcheknek patch 2 ✓ ✓ gyp patch 1 kell jóknak lenni, azontúl olyan szemétdomb lehet, patch 1 ✓ jatekpatch 1 amit nem szégyell
  • 12. Kollaboráció – a cherry-pick mainline gyp feature 2 ✓ dev-gyp ✓ gyp patch 3• integrálás: gyp feature 1 ✓ jatekpatch 3 • közös review (személyesen, semmi fancy tool) ✓ gyp patch 2 patch 4 ✓ • patcheket szedünk • javíthatunk, összevonhatunk, patch 3 ✓ jatekpatch 2 darabolhatunk • conflict-feloldás itt, ha túl sok, patch 2 ✓ ✓ gyp patch 1 visszadobjuk • tiszta, önmagában értelmezhető patch 1 ✓ jatekpatch 1 patchek kellenek
  • 13. Kollaboráció – a cherry- jatekpatch 3pick mainline dev-gyp jatekpatch 2 jatekpatch 1 gyp feature 2 ✓ ✓ gyp patch 3 jatekpatch 3 gyp feature 1 ✓• fejlesztő időnként rebase-el • kidobja a saját patcheit ✓ gyp patch 2 • behúzza magához a mainline-t patch 4 ✓ • visszarakja egyesével a patcheket, conflictot old fel patch 3 ✓ jatekpatch 2 • amik már felkerültek, itt kidobja patch 2 ✓ ✓ gyp patch 1 • lehet itt is szerkeszteni, átrendezni, kidobálni patch 1 ✓ jatekpatch 1
  • 14. Kollaboráció – a cherry-pick• git alapon mindez: • mainline, fejlesztői ág: git repository-k • git remote-tal egymásnak megadva • git cherry, git cherry-pick • git rebase –interactive • kicsit buta, scripttel kell neki segíteni
  • 15. Kollaboráció – a merge zorp-mainline scb-mainline• főleg csapatok közt, közös komponensekhez• a git jobban „szereti”, ✓ scb patch 4 effektívebb eszközök zorp patch 4 ✓• de kifogástalan minőségű zorp patch 3 ✓ ✓ scb patch 3 ágakra van szükség! • egy Linux kernel-szintű zorp patch 2 ✓ ✓ scb patch 2 dolognál ez belefér... ✓ scb patch 1 • ...de egy átlagos fejlesztői zorp patch 1 ✓ projektnél ez túl drága
  • 16. Kollaboráció – a merge zorp-mainline scb-mainline zorp patch 5 ✓ ✓ scb patch 5/B• tipikusan mainline-ok merge ✓ ✓ scb patch 5/A között ✓ scb patch 4előre meghatározott zorp patch 4 ✓ pontokon (pl. új zorp patch 3 ✓ ✓ scb patch 3 release kezdetekor) merge-ölünk zorp patch 2 ✓ ✓ scb patch 2 ✓ scb patch 1 zorp patch 1 ✓
  • 17. Fejlesztés követése- rendes verziókezelést követelünk meg, amit a git támogat nem fájlonként, hanem patchenként commit olcsó, egyszerű brancheket csinálni, emiatt könnyebb tisztán tartani a dolgokatalap git toolok elegendőek: git log gitk gitweb
  • 18. Backuppofátlanul könnyen indítható verziókezelés git init; git add .; git commitolcsó, könnyű branchelésgit stashgit checkoutgit tag
  • 19. Regression-keresésgit checkout → visszaállás tetszőleges állapotragit log fájlra, git blamebest thing since slice bread: git bisect git bisect start git bisect good release-1.0.0 git bisect bad [make check] git bisect good/bad... (scriptelhető is!!!)
  • 20. Összegzésa verziókezelés nem szükséges macera, hanem eszköz!...de ehhez az kell, hogy ne legyen útban: akkor kelljen dolgozni vele, amikor akarunk legyen gyors legyen megbízható legyen flexibilis...és a git erre nagyon jó.
  • 21. Köszönöm.Gyöngyösi Pétergyp@balabit.hu