V bart-e vyvíjame desiatky projektov – raz na nich pracujeme z kancelárie, inokedy zase z domu. Ak chceme niečo kódiť, alebo testovať, projekt si u seba lokálne vždy musíme spustiť. Tento proces v našom prípade dosiaľ zahŕňal build (zmenšenie a kompiláciu kódu, doplnenie súčastí z knižníc a pod.) všetkých jeho súčastí (services). Čím viac services projekt používa (API, databázy…), tým dlhšie trvá, kým sa “rozbehá”, aby sa naň človek mohol reálne pozrieť alebo pracovať na ňom.
V praxi to vyzerá tak, že v niektorých prípadoch môžeš projekt spustiť a ísť na 10 minút na kávu, kým prebehnú všetky buildy a dá sa reálne zasiahnuť do kódu. Obzvlášť neefektívne to je, ak potrebuješ len doplniť jeden či dva príkazy alebo si niečo otestovať. Navyše, ak idete na projekte robiť dvaja, každý na svojom počítači, proces spúšťania prebehne u oboch. Na kávu tak aspoň môžete ísť spolu.
Zdĺhavé spúšťanie ťa pripravuje o tvoju (aj zákazníkovu) najdôležitejšiu komoditu – čas. A keďže my si svoj a klientov čas vážime, sadli sme si v jednu stredu po práci a dali si za úlohu vymyslieť rýchlejší spôsob rozbiehania projektu Crossuite. V poslednej dobe sme ho totiž poriadne rozšírili a celý systém tak už potreboval poriadnu optimalizáciu.
Na začiatku nás bolo šesť. Prvú hodinu sme si vysvetľovali štruktúru aktuálneho fungovania a dôvody, prečo vlastne treba systém spúšťania prekopať. Ďalšie 2 hodiny pripadli analýze a pizzi. Veľa sme brainstormovali, navrhli koncept a rozdelili si úlohy. No a posledných 5 hodín sa kódilo. Domov som dorazil 1:30 ráno, no s dobrým pocitom, že sa niečo podarilo.
A čo sa podarilo?
Nový systém spúšťania, ktorý sme navrhli a čiastočne aj otestovali, je postavený tak, že sa build vykonáva automaticky, napríklad po pushnutí kódu danej služby do repozitára. Zároveň sa vytvára tzv. image služby – verzia, ktorá je pripravená na používanie, ale nedá sa do nej zasiahnuť.
Keď si niekto následne appku spustí, táto sučasť sa už buildovať nemusí – riešenie jednoducho natiahne hotové images. Ak chce programátor v kóde niečo meniť, zbuilduje si len tú službu, ktorú potrebuje upraviť. Všetko ostatné je už predpripravené na použitie. Celkový čas spúšťania sa teda skráti z desiatok minút na sekundy.
Z tejto novej feature boli najviac nadšení kolegovia z QA tímu, ktorí často projekt spúšťajú bez potreby zásahu doň, len aby overili, či niečo funguje, ako má. Keďže nepotrebujú žiadnu časť kódu meniť, iba si pozrieť výsledok, images im úplne stačia a celý proces buildovania sa vynecháva.
Automatický build sa nám podarilo vyriešiť pre 6 najkritickejších služieb nášho projektu. Aby sme mohli riešenie nasadiť do produkcie, musíme ho zabezpečiť ešte pre tie ďalšie, spísať dokumentáciu, dokončiť iniciáciu databázy… Na hackatone sme však položili pevný základ a overili si niečo dosiaľ teoretické v praxi. A navyše sme sa skvele najedli aj nasmiali. Takéto stredy by mohli byť pokojne častejšie.
