Branch review

Branch review (neplést s Code Review) rozšiřuje Continuous Integration o možnost sestavit každou větev ve funkční aplikaci. Tyto aplikace jsou na sobě naprosto nezávislé – nesdílí žádná data, ani zdrojové kódy, ačkoliv je možné, že sdílí systémové prostředky serveru.

Běžně má vývojář aplikaci sestavenou a funkční na svém stroji a při vývoji nové úpravy ji je schopen lokálně otestovat. V lepším případě se při pushi spouští kontroly a automatizované testy jako součást CI procesu. Ale co když je potřeba úpravu otestovat manuálně testerem? Co když ji v průběhu implementace má připomínkovat i klient?

Často se pak úprava nahrává na dedikované testovací prostředí (dev, test, pre-production, staging, …), které přináší problémy, pokud chceme vidět úpravy izolovaně (i když je samo o sobě skvělé pro testování více úprav dohromady). Ve větším týmu je často rozpracovaných úprav více a pokud se vše testuje na jednom stroji, dostáváme se do spirály, kde se vývojáři musí dohodnout, kdo zrovna svoji úpravu nahraje na testovací prostředí, a pokud potřebují prezentovat najednou více úprav, musí se v rozpracované fázi nahrát na testovací prostředí všechny. Nezapomeňme na to, že si musíme připravit data, která mohou být vzájemně v rozporu. Také je možné, že v rané fázi vývoje jsou přítomny chyby, které ovlivní funkčnost jiné úpravy.

Jak z toho ven?

Jinými slovy jsme závislí na potřebách jiných vývojářů a tyto závislosti se rapidně zvyšují s počtem lidí v týmu. Ideálně bychom tedy chtěli mít možnost tyto úpravy oddělit do samostatných prostředí. A když už jsme u toho, nechceme úpravy na tato prostředí nasazovat ručně, ale automaticky. Aby každé prostředí mělo nahranou výchozí sadu demo dat. A aby byla větev dostupná pod nějakou URL i veřejně (případně za VPN). To vše splňuje Branch review.

Prvotní nastavení sice zabere nějaký čas, ale investice se v budoucnu mnohokrát vrátí v podobě spokojenosti vývojářů, testerů, product ownera i klienta. Nejprve budeme potřebovat někde umět rozjet dynamické prostředí. Pro to se dá využít například vlastní Kubernetes cluster, server s nainstalovaným Dockerem, cloudové služby (Google Cloud, nebo AWS), případně oficiální Symfony PaaS (Platform as a Service) Platform.sh.

V našem případě jsme zvolili pro každý projekt separátní server s nainstalovaným Dockerem. Abychom ušetřili zdroje serveru, náročnější služby jako např. Elasticsearch a PostgreSQL jsou sdílené napříč všemi prostředími a oddělené jsou na úrovni vlastních indexů (Elasticsearch) nebo databází (PostgreSQL).

Spuštění branch review

Jakmile je úprava pushnuta na Gitlab, nejprve se spouští sestavení aplikace v docker image se kterým poté pracují všechny další úrovně, které jsou následně využity pro testování a nasazení aplikace do produkčního prostředí. Využíváme tedy principu “build once, run many times”. Poté se spouští sada automatizovaných kontrol pro zajištění požadované kvality kódu a ověření funkčnosti. Paralelně s tím se spouští úloha, která již sestavenou aplikaci spouští na připraveném serveru. Zjednodušeně pouze stáhne image, spustí kontejner a připojí běžící kontejner do sítě pod unikátní url. Jako proxy, která dynamicky zpřístupní každý kontejner se nám osvědčilo používat Traefik.

Toto paralelní spouštění branch review, nám zaručí, že aplikace bude dostupná pro testování, i když například padá některý z automatických testů, nebo jsou porušeny coding standards. Tedy za předpokladu, že je možné aplikaci sestavit při vytváření docker image.

Tento způsob nicméně vyžaduje stále běžící server, kde musí jednotlivá prostředí běžet, což může být neekonomické. Například o víkendech, v noci, případně když se delší dobu na projektu neprovádějí žádné změny. V takovém případě může být vhodné spouštět prostředí dynamicky v cloudu.

Abychom měli na každém prostředí výchozí sadu demo dat, nahráváme je pomocí DataFixtures. Díky nim jsou testovací data přímo součástí repozitáře, díky čemuž jsou k dispozici jak pro vývoj, tak pro testování a není nutné si data připravovat ručně. A zároveň je možné používat přímo modelové třídy stejným způsobem, jako se používají v samotné aplikaci. Při odhalení chyby je možné přidat další kombinaci dat, kterou přímo využijí testy a bude k dispozici i v budoucnu pro další vývoj.