V následujícím článku se zaměříme na proces automatizovaného nasazování.
Ak máte zájem se dozvědět více informací, dolvolte nám pozvat vás na webinář Vývoj vs. konfigurace – Salesforce pro CIOs nebo IT manageri 16. 6. 2020 v 16:00.
V prvním díle se budeme věnovat správnému nastavení branch strategy – tedy jaké větve je vhodné používat a jak s nimi pracovat.
K nastavení automatizovaného procesu je nezbytné si stanovit, na jaké prostředí budeme v rámci projektu nasazovat. Podle počtu prostředí vhodně nastavit branch strategy v GIT repositáři.
Zajímavým příkladem branch strategy je git-flow. Jedná se o workflow přístup, který usnadňuje práci s gitem. Pomocí připravených příkazů (jeden příkaz z git-flow provede jeden nebo více operací ze standardních GIT příkazů) je možné vytvářet nové větve, případně provádět komplikovanější merge.
Já osobně vidím v git-flow komplikaci v nemožnosti nastavení oprávnění nad jednotlivým větvemi. Pro správnou funkci a plné využití možností, které workflow nabízí, je nutné, aby měl každý člen právo pushovat do každé větve (včetně master). Z tohoto důvodu jsme si převzali pouze názvosloví, které definuje vývojový stav tiketu dle prefixu dané větve.
Logika je následující:
- Develop – primární větev pro vytváření větví pro nové tikety
- Master – odráží produkční aplikaci
- Feature – jedná se o nový úkol, na kterém pracuje zpravidla jeden vývojář. Nová větev se vytváří z develop. Následný merge je opět do develop větve.
- Release – příprava nasazení z testu na produkci. Nová větev se vytváří z develop, následný merge je do master větve.
- Hotfix – nová větev se vytváří z master větve. Při ukončení se změny pushnou jak do master tak i develop větve.
Podle komplexity projektu a požadavků zákazníka je nutné stanovit si počet větví a definovat jaké z větve se bude nasazovat na dané prostředí. Pokud se jedná o enterprise projekt, pravděpodobně bude ze strany klienta požadovaný deployment model obsahující více prostředí.
Většinou se používají:
- Dev – prostředí, které využívá developer k základní otestování nové funkcionality
- Stage – zde se potkávají změny od vývojářů a testují se případné kolize
- Integration – prostředí pro integrační testy. Testuje se včetně synchronizace s ostatními částmi aplikace a třetích stran.
- UAT – akceptační prostředí, před nasazením na produkci.
- PROD – produkční prostředí
V dalších dílech se budeme postupně věnovat jednotlivým částem tohoto diagramu a popíšeme si jak řešíme proces nasazování u nás v Enehanu. V následujících částech se můžete těšit také na popis samotné CI/CD pipeline, proč je pro nás důležitá kvalita a jak řešíme code review a mnoho dalšího.
Autor: Petr Vích, Senior Java Developer, Enehano Solutions
