Dotaz: Nasazení GITu v rámci vývoje webové aplikace

[famke]

Ahoj všem,

náš tým cca 10 vývojářů vyvíjí webovou aplikaci s databázovým backendem. Snažíme se pro účely vydávání verzí a nějaké rozumné správy vývoje nasadit git. V současné době se pracuje stylem kdy všichni přímo upravují kódy vývojové webové aplikace a provádí změny databáze. Vydání funkcionalit v dané verzi se řeší ručním přenášením změn z vývojové aplikace na release aplikaci ze které je vytvořena aktuálně vydávaná verze , databázové změny se zapisují do sql skriptu který s vydáním dané verze jde do světa. Že tento model není ideální je asi stejné jako říct, že Hitler trochu zlobil. Aplikace je psaná většinou v Classic ASP, takže nějaké continuous integration se jeví jako poměrně obtížně řešitelné.

V současné době je na stole tato varianta:

Uživatelé pracují na lokální kopii, která se synchronizuje s vývojovou verzí (nemají vlastní instanci web aplikace) a změny testují na vývojové verzi. Pokud jsou OK, provedou commit do centrálního repozitáře, ze které by byla vydána verze. Změny databáze by byly součástí tohoto commitu.

V plánu je držet spíše více větví pro nově přidávané/měněné funkcionality a po akceptaci je začleňovat do release větve. V současné době není na pořadu, že každý vývojář by měl vlastní instanci aplikace, kterou by si synchronizoval, s vlastní databází, takže byl navržen tento postup.

Napadá někoho jak to udělat, lépe, správněji?

Za každý postřeh, nebo nakopnutí děkuji.

---

---

Odpovědi

[cronin]

Už použitie akéhokoľvek VCS bude pre vás obrovským krokom vpred, urobte tak už DNES. Použitie rôznych workflows môžte zvážiť kedykoľvek neskôr.

[OldFrog {Ondra Nemecek}]

Každé použití VCS je lepší než žádné. Git je skvělá volba, kterou používám i pro své privátní projekty, které s nikým nesdílím. V podstatě jen kvůli průběžnému zálohování. Také se nemusím bát si v něm cokoli natrénovat, i když si třeba nejsem jist správným výsledkem. Odnaučilo mě to dříve oblíbené zakomentovávání kusů kódu.

Zatím jsem se všude setkal s tím, že vývojář si kompletní aplikaci rozchodí na svém lokálním počítači, s lokální databází. Když vývojář řeší nějakou feature či bug, založí si nový branch, ve kterém to napíše a odladí. Průběžně vše verzuje do doby, než je s prací hotov. Pak nechá udělat code review tím, že zažádá o merge do hlavní větve. Druhý vývojář to zkontroluje a po dohodě to jeden z nich merguje do větve master. Větev s feature či bugem se následně zruší. V určitém okamžiku se z větve master udělá další větev deploy, udělají se na ní poslední hotfixy a otaguje číslem verze. Může se nasadit.

S tímto primitivním schématem se dá fungovat až do docela vysoké složitosti projektu. Pro 10 lidí to může v pohodě stačit.

[MP]

Nejslozitejsi na nasazeni lokalniho vyvoje (krome nauceni se jineho workflow) je vyreseni situace kolem databaze. Pokud se databazove zmeny prenasi sql skriptem, tak je napul vyhrano, ale je nutne to vyresit i u tech dev, jak se jim to syncne. Sami to ted resime...

[OldFrog {Ondra Nemecek}]

spíše více větví pro nově přidávané/měněné funkcionality

Primárně se projekt pořád posunuje dopředu, takže pořád makáš na devu a něco přidáváš a měníš. Jednou za čas oddělíš release candidate, který chvíli stabilizuješ, pak vydáš release a případně z něj ještě děláš menší updaty. Prostě stálý vývoj se stabilními body. Jestli bokem s něčím experimentujete a až později to promergujete, tak se tím nic nemění.

Každý musí mít možnost kód hned testovat a commitne až splněný úkol (třeba i ve více krocích) a samozřejmě před tím zmerguje případné kolize s commity ostatních. Nechápu jak to chcete dělat na nějakém společném testovacím serveru, kde si všichni navzájem rozbíjí kód a commitují opravu každého překlepu.

To řeší i problém s databází. Buď se vytváří nová, nebo převádí stará a pak se samozřejmě verzuje a autor změny v DB doplní i převodní kód. Všichni vždy mají funkční verzi i když třeba každý jinou.

[kapo]

Popis: http://nvie.com/posts/a-successful-git-branching-model/
Implementace: https://danielkummer.github.io/git-flow-cheatsheet/

[Gilhad]

Jo, tohle jsem taky prosadil (s drobnyma zmenama) a dobre to bylo

plus samozrejme v gitu byl congif.example, zatimco config (se skutecnym jmenem databaza, IP, porty a tak) byl v .gitignore, takze kazdy vyvojar si ho nastavil podle sebe a mel svou databazi, ale komitoval zmeny od config.example (pokud neco pridal/zmenil/....)

samozrejmosti bylo, ze zmeny do databaze se delaly skripty (DJANGO je generuje automaticky - migrations), takze kdyz jsem si stahnul verzi od kolegy, tak jsem jen spustil migrace a mel to co on.

databazi si kazdy verzoval u sebe lokalne, takze nebyl problem kdyz zmeny neco rozbily to vratit zpet.

do develop se poustly az kompletni "squash" commity, ktere byly odladene a prosly testy.

(samozrejme cely kod byl pokryt testy - povinne - a pred commitem z vetve do develu musely projit vsechny.)

Jo, byl to opruz zavest a kolegy k tomu dokopat (i kdyz podpora vedeni byla na ideove urovni, ale hlavni bylo moje ultimatum (jako hlavniho vyvojare a otce systemu) - bud to bude verzovane a delane ciste, nebo proste odchazim) se zpetnym ohlednutim po pul roce si uz nedokazali predstavit, jak bez toho mohli neco rozumne delat. Vsechny ty rozbite releasy se staly v podstate prehistorii a hlavni vetev byla cista radka komitu, kde kazdy "zazrakem" resil jednu vec uplne a spravne. Feture vetve se zahazovaly prakticky jakmile se pridal ten squash merge do develu, protoze pak se z nej odstiply dalsi vetve a vychazelo se z toho stavu. (teda, nechaly se tak tyden, dva zahnivat kvuli moznym dohledavanim regresi, ale jejich aktivni zivot v podstate zaclenenim skoncil)

Rutinne (i kdyz rucne, protoze ne vzdy se to hodilo zrovna v tu chvili, kdy nekdo mel u sebe rozdelany komplexnejsi problem a nechodily mu na to testy) se mergoval novy stav develu do vsech otevrenych feature vetvi, rozhodne vzdy povinne pred sqash mergem zpet, takze merge z feature do develu byly vzdy bezproblemove (prakticky fast-forward, jen jinak zabaleny)

devel se pak obdobnym zpusobem choval jako "fetature vetev" releasu, takze kazdy release byl kompletni a funkcni a overeny - k nezaplaceni :)