Kdyz jsme pred dvema lety zacinali, meli jsme jednoduche pravidlo: vsichni commituji do trunku. Fungovalo to, dokud nas bylo pet. Ted mame sest vyvojaru, tri paralelni projekty a klienta, ktery potrebuje hotfix na verzi v produkci.
Nase branching strategie¶
Po nekolika mesicich experimentovani jsme se ustalili na modelu: trunk/ pro hlavni vyvoj, branches/release-X.Y/ pri feature freeze, branches/hotfix-X.Y.Z/ pro urgentni opravy a tags/release-X.Y.Z/ jako immutable snapshoty. Feature branches nepouzivame — v SVN je mergovani bolestive.
Release proces¶
Dva mesice vyvoje v trunku, pak feature freeze a vytvoreni release vetve. V release vetvi se opravuji pouze bugy. Trunk se otevre pro dalsi vyvoj.
Hotfix workflow¶
Klient vola v patek v 16:00. Verze v produkci je 2.0.3, trunk je na 2.1-SNAPSHOT. Hotfix vetev z posledniho release tagu, oprava, test, nasazeni, merge zpet. Nikdy neopravovat primo v tagu.
SVN hooks a pristupova prava¶
Pre-commit hook vynucuje JIRA cislo v commit message a zakazuje commit do tags/. Post-commit notifikuje Hudson. Authz soubor omezuje write pristup k release vetvim na seniory.
Zaverem¶
SVN branching neni nocni mura s jasnymi pravidly. Az prejdeme na Git, bude to kvuli lepsimu mergovani, ne proto, ze by SVN nefungoval.