Verzió kezelési stratégiák, melyekkel biztosítható, hogy a fejlesztői, teszt és éles környezeteink között megbízhatóan tudjuk a kódjainkat mozgatni.
Az előadásról készült videó itt található:
http://www.ustream.tv/recorded/27330358
Budapest, PHP meetup: Termék életciklus és verzió kezelés
1. Termék életciklus és
a verziókezelés
Nagy Attila Gábor
Wildom Kft.
PHP Meetup 2012 november
2. Célok
●
Legalább három környezet:
– Fejlesztői
– Teszt
– Éles
●
Visszaállás lehetősége
●
Release early, release often
●
Éles környezetben is adódhatnak
változtatási igények
3. Hatalmas választék
CVS Team Foundation
Server
ClearCase
Subversion
Bazaar Darcs
Git
Mercurial
BitKeeper
4. Commit log!! Tippek az induláshoz
Commit log!!
●
Minden környezet azonos
forráskódot használjon
– Konfiguráció nem verzió kezelt
– Környezet függő konfigurációk
●
Rendszeres commitolás
●
Csak tiszta kódot commitoljunk
– Ignore fájlok, akár projekt szinten
●
Minimális változtatás elve
●
Conflictok kezelését ismerni
5. Subversion
●
Legelterjedtebb eszköz
●
Könnyen megtanulható
●
Használható branch-ek
●
Revíziók meghatározzák a projekt
állapotát adott időpontban
●
Rugalmasabb mint a CVS
6. Párhuzamos ágak
●
Intuitív
●
Gyakori
élesítésnél jobban
megfelel
●
„Csak előre”
szemlélet
●
Nincsenek
dedikált releasek
●
Nem kell
„újratelepíteni”
10. Megjegyzések
●
Jóval kevesebb merge
●
Könnyű elfeledkezni arról, hogy új
release-t hozzunk létre párhuzamos
branch-ek
●
Minden release „új telepítés”
– vagy: svn switch
●
Nem egyértelmű, hogy mi kerülhet a
release-be, és mi nem
– Fontos a jó policy
– Fontos azt betartatni
11. Merge tracking
●
Fontos tudni, hogy mely revíziókat
mergeltük már
– Többszörös merge conflict-ot okoz
●
SVN még nem igazán erős ebben
– 1.5.0 előtt nem volt SVN-ben
●
svnmerge: python script
– 1.5.0 óta mergeinfo
●
trunk → branch - ok
●
branch → trunk - csak egyszer
– „reintegrate”
12. Elosztott verzió
kezelő rendszerek
●
Hatékony branch-merge támogatás
– Linus: „a merge a lényeg,
branchelni mindenki tud”
●
Lokális branch-ek
●
Nagy szabadság
●
Implicit backup
●
Git, Mercurial, Bazaar
http://www.youtube.com/watch?v=4XpnKHJAok8
13. Hátrányok
●
Nehéz megtanulni
●
Sok branchet eredményezhet
– Kell egy jó rendező elv
●
Hol a legfrissebb kód?
●
Több idő megy el kód
managementre
14. Bizonytalan ügyfél
?
? probléma
3
3 ●
Revertelni nem lehet,
Jelmagyarázat
Még fontosabb
Inkább hagyjuk...
3
3 mert értékes
tartalom
feature
2
2
Mégsem olyan
Bocs, mégis sürgős
Nagyon sürgős
sürgős feature
feature
1
Egész ügyes, de...
Általános fejlesztés
1 ●
Mergelni sem lehet
4
4
2
2
●
Cherry pick
1
1 – Nehezen átlátható
3
3 – Kimaradhat valami
2
2 – Egy commit több
1
1 feature :(
R
R
15. Feature branch
●
Egy feature – egy
R
R
branch
R
R
4 4
●
Bármikor
4 4
tetszőleges release
3
3 3
3 3
3 3
3
összeállítható
2
2 2
2 2
2 2
2
1
1 1
1 1
1 1
1
●
Mindig lehet
commitolni
R
R
●
Kisebb brancheket
könnyebb átlátni
16. Ideális struktúra
●
Projekt eleje
szerteágazik
●
Release-ek egyesítik
a korábbi branche-
eket
●
Maradhatnak
oldalágak
– Nem került be a
releasebe
17. Tudnivalók
●
Megvalósítható Subversionnel
– Git, Mercurial erősebb ebben
●
Projekt elején néha célszerűbb
eltekinteni tőle
●
Lehetőleg minden feature külön
branchbe kerüljön
– Ha egymásra épülnek, akkor az új
branch az előzményből
származzon
code review
code review