Automatizace nasazování nejen v Salesforce

February 28, 2020
February 27, 2020
|
Petr Vích
|
5
Minutes

V následujícím článku se zaměříme na proces automatizovaného nasazování.

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

Latest Article

Let us handle the logistics for you

Ready to turn leads into cash?

LET us handle the logistics for you
Schedule your free analysis today!
Thanks for your email! We’ll get back to you ASAP.
Oops! Something went wrong while submitting the form.