SVN branching strategie pro enterprise projekty

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.