Kdyz jsme pred dvěma lety začínali, měli jsme jednoduché pravidlo: vsichni commituji do trunku. Fungovalo to, dokud nas bylo pet. Teď máme šest vývojářů, tri paralelní projekty a klienta, který potřebuje hotfix na verzi v produkci.
Naše branching strategie¶
Po několika měsících experimentování jsme se ustálili na modelu: trunk/ pro hlavní vyvoj, branches/release-X.Y/ pri feature freeze, branches/hotfix-X.Y.Z/ pro urgentní opravy a tags/release-X.Y.Z/ jako immutable snapshoty. Feature branches nepouzivame — v SVN je mergovani bolestive.
Release proces¶
Dva měsíce vývoje v trunku, pak feature freeze a vytvoření release vetve. V release vetvi se opravují pouze bugy. Trunk se otevře pro další vyvoj.
Hotfix workflow¶
Klient volá v pátek v 16:00. Verze v produkci je 2.0.3, trunk je na 2.1-SNAPSHOT. Hotfix vetev z posledního release tagu, oprava, test, nasazeni, merge zpět. Nikdy neopravovat primo v tagu.
SVN hooks a pristupova prava¶
Pre-commit hook vynucuje JIRA číslo v commit message a zakazuje commit do tags/. Post-commit notifikuje Hudson. Authz soubor omezuje write pristup k release vetvim na seniory.
Závěrem¶
SVN branching není noční můra s jasnými pravidly. Az prejdeme na Git, bude to kvůli lepšímu mergovani, ne proto, ze by SVN nefungoval.
Potřebujete pomoc s implementací?
Naši experti vám pomohou s návrhem, implementací i provozem. Od architektury po produkci.
Kontaktujte nás