Automatizace nasazování nejen v Salesforce

Automatizace nasazování nejen v Salesforce

 

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íce informací naleznete zde.

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.
Popis celé flow

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í
Samotné nastavení procesu automatizace nasazení popisuje tenhle diagram

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

Novinky a informace

Přímo do vaší emailové schránky

Prozkoumejte související články