Release Management jako největší slabost Salesforce projektů?

Když mluvíme o Release Managementu (zkráceně RM) co máme vlastně na mysli? RM je soubor několik dovedností, které je potřeba zkombinovat a upravit pro konkrétní situaci a klienta.

Do RM patří zejména:

• Návrh struktury prostředí
• Nastavení a návrh struktury repozitáře (pokud je potřeba)
• Návrh a zavedení procesu developmentu a deploymentu
• Návrh plánů nasazení / releasu
• Návrh použití nástrojů pro nasazení / deployment

Všechny tyto oblasti je nutné sladit, protože jedna na druhou mají zásadní vliv.

Velký vliv na nastavení RM má hlavně vyspělost zákazníka. Klienti jsou různí a je nemožné očekávat, že klienti bez sebemenší znalosti práce např. s repozitářem nebo nastavením prostředí budou schopni přejít na nástroje pro vysokou automatizaci a tzv. Continuous Integration (vice info na: https://www.atlassian.com/continuous-delivery/ci-vs-ci-vs-cd).

V zásadě rozlišujeme čtyři skupiny vyspělosti klientů:

• Neznalí – používají change sety, úprava produkce je manuální, jde hlavně o menší klienty z pohledu počtu licencí a uživatelů systému
• Nováčci – používají repozitář, manuální spouštění nasazení do produkce, jde hlavně o menší klienty z pohledu počtu licencí, někdy se objeví i velcí klienti
• Pokročilí – efektivní využívaní repozitáře, automatizované nasazování kódu, monitorování testovacích tříd, manuální regresní testy, největší část velkých klientů a někteří menší klienti
• Lídři – efektivní využívaní repozitáře, automatizované nasazování kódu, automatizované monitorování testovacích tříd a regresních testů, jednotky klientů obecně

Návrh struktury prostředí

Pro skupinu Neznalí a Nováčci je nastavení prostředí (sandbox) často velmi jednoduché. V zásadě se setkáváme s následujícími typy prostředí:

• Development Org – sandbox kde dochází k vývoji kódu a často i k jeho testování.
• Test Org – nebývá podmínkou, ale je někdy použit pro testování před nasazením do produkce.
• Produkce – produkční Org, tzv. „ostré“ prostředí, kde uživatelé pracují s klientskými daty.

Ve skupinách Pokročilých a Lídrů se setkáváme ještě s více typy prostředí:

• Integrační Org – přítomen zvlášť v případech kdy je potřeba kombinovat několik souběžně pracujících týmů od různých dodavatelů, nebo různé týmy pracující na dílčích částech systému odděleně, je zde prováděno integrační testování.
• UAT Org (User Acceptance Tests) – instance, která je určena výhradně pro uživatelské testování před nasazením do produkce.
• Training Org – školící prostředí, někdy bývá použito přímo UAT, ale to není dobrá praxe, školící prostředí by mělo projít obnovením (refresh) ideálně po každém nasazení do produkce.
• Mock deployment – prostředí, které je kopii produkce před provedením nasazení do produkce a slouží pro ověření, že všechny kroky a komponenty jdou nasadit správně do cílového prostředí.
• Support dev – developerské prostředí pro support a opravu produkčních incidentů.
• Support test / Hypercare – testovací prostředí pro opravu produkčních incidentů

Proč mít více prostředí?

• Kontrola verzí a kódu – i v omezené míře bez repozitáře oddělením jednotlivých prostředí získáme větší kontrolu nad tím jaké změny jsou nasazeny
• Oddělení přístupu – můžeme omezit přístup jednotlivým rolím, developerům / testerům pouze do určitých prostředí a omezit práva na změny komponent systému

Nastavení a návrh struktury repozitáře

Pokud je repozitář na projektu jde většinou dobré znamení. Je třeba si ale uvědomit, že samotné použití repozitáře ještě nemusí nést kýžené výsledky. Nastavení repozitáře vyžaduje určitou praxi, a hlavně musí korespondovat s nastavením prostředí a procesem vývoje.

Asi nejpoužívanější strategií nastavení struktury repozitáře je tzv. „environment based structure“. Základní myšlenku této strategie můžeme popsat jako „jedno prostředí = jedna vývojová větev (dále Branch)“.

Když tuto myšlenku převedeme na nejjednodušší příklad, máme tyto tři základní prostředí:

• Development Org
• Test Org
• Produkce

vývojové větve, které budou takovému scénáři odpovídat:

• Development Org = svoji branch nepotřebuje, všechny změny se nahrávají do nových tzv. feature branch (jedna úprava = jedna nová branch – kopie master)
• Test Org = Test branch – je obrazem prostředí a obsahuje všechny komponenty úplně ve stejném stavu jako jsou v prostředí Test Org
• Produkce = master – stejně jako Test branch, je přesným obrazem prostředí Produkce

Výhody použití repozitáře

• Verzování kódu – repozitář označuje každou změnu kódu a přiřazuje autora změny, takto máme k dispozici zálohu (backup) verzí kódu a může tak udělat krok zpět (roll-back) k dřívější verzi kódu
• Monitorování změn – v repozitáři můžeme dohledat každou změnu na všech souborech (metadatech), můžeme tak sledovat kolik změn a kdy bylo provedeno, můžeme tak i dohledat kdo přesně změnil komponentu, v kterém prostředí což může být obzvlášť užitečné, pokud je na projektu více dodavatelů nebo týmů, umožníme tak např. rychlejší opravy nebo dohledat autora „špatných změn“
• Automatizace – pokud víme, že repozitář obsahuje přesný obraz prostředí, můžeme velmi jednoduše umožnit automatické nasazování přímo z repozitáře

Jestli používat repozitář nebo ne, bude odpověď na následující otázky:

• Potřebujete, aby více uživatelů pracovalo paralelně na stejných komponentách?
• Máte problémy se změnami komponent a nevíte kdo a proč je změnil?
• Chcete automatizovat nasazování verzí a úprav do produkce a dalších prostředí?

Pokud jste si odpověděli ANO, měli byste začít používat repozitář.

Repozitář, už používáte? Něco nefunguje, jak má, nebo byste rádi zlepšili automatizaci máme pro Vás tool, který plně automatizuje deployment z repozitáře.

Jestli máte zájem dovědět se víc, nebo potřebujete pomoct s nastavením RM stačí, když mi napíšete.