IT vývoj v startupe

Vývoj v startupe musí byť rýchly. Čas od analýzy, implementáciu až samotné nasadenie musí byť čo najkratší. Nemôže sa napríklad stať, že nasadzovanie novej verzie musí počkať na víkend alebo je sprevádzané veľkým časovým výpadkom aplikácie, prípadne sa tohto procesu musí zúčastniť veľa členov tímu[1]. V tomto blogu predstavíme dva softvérové procesy, ktoré vo Fumbi s úspechom využívame, či už na vývoji novej alebo zmeny existujúce funkcionality.

Práca na novej funkcionalite

Feature branches

Častý spôsob vývoja, spopularizovaný najmä Gitom, je vytvoriť feature branch. Inak povedané, developer(i) si vytvorí z hlavnej vetvy vlastnú, v nej sa vyvíja nezávisle od ostatných a nakoniec sa kód naspäť zlúči do hlavnej vetvy. Tento spôsob sa ukázal ako nie veľmi šťastný[2]. Výskumy ukázali, že problémy so zlučovaním kódu sa ukázali dosť podstatné v prípade, ak dĺžka vetvy presiahne jeden deň [3]. 

Feature flag/Feature toggle 

Jeden zo spôsobov, ako sa zaobísť bez feature branch, je vyvíjať v hlavnej vetve s možnosťou zapnutia/vypnutia vyvíjanej funkcionality, napr. pomocou konfiguračného súboru. Týmto môžeme dokonca nasadiť aplikáciu s nedokončenou implementáciou. Použitím tohto patternu získavame ďalšie možnosti, napr.  funkcionalitu  zapnúť len v testovacom prostredí alebo ju sprístupniť len obmedzenému množstvu zákazníkov na produkcii (napr. len pre slovenských zákazníkov alebo pre spolupracovníkov vo firme). Takto získame spätnú väzbu a môžeme zachytiť aj problémy, ktoré nesúvisia priamo s IT vývojom (ako nejasný text, či problémové grafické rozhranie) v skoršej fáze bez väčších škôd.

Feature flag je mocná technika. Niektorí ju odporúčajú používať už v prípade, ak programátor nestíha dokončiť svoju úlohu za pol dňa[4]. Ako sme písali, hodí sa skôr pre vývoj novej funkcionality. V prípade väčšieho refactoringu, resp. zmeny existujúceho správania, na scénu prichádza Strangler pattern.

Zmena existujúcej funkcionality alebo refactoring

Strangler pattern

Ak pracujeme na väčších zmenách v existujúcom kóde, môžeme použiť Strangler pattern. Základná myšlienka (viď obrázok nižšie) je postupne nahradzovať existujúcu funkcionalitu, pričom pôvodná sa dočasne zachová, až do okamihu, keď  môžeme pôvodný kód úplne odstrániť.

Tento pattern je trošku časovo náročnejší, no je dobré ho mať v zálohe v prípade, že meníme kľúčové komponenty aplikácie. Nemusíme hneď automaticky nahradzovať starý kód za nový. Nechajme ich bežať vedľa seba[4] (v literatúre[5] sa môžeme stretnúť s podobným vzorom Parallel run) a po čase starý kód úplne odstráňme. Pôvodne túto myšlienku predstavil Martin Fowler ako architektornický vzor[4], ale ukázal sa prospešný aj v menších škálach.

FUMBI

Vo Fumbi nasadzujeme nové verzie aplikácie priemerne viac ako jedenkrát denne. Od začiatku fungovania firmy sa vyskytli 2 prípady, kedy sme robili deploy, ktorý spôsobil (plánovanú) nedostupnosť aplikácie. Vždy sa snažíme, aby sa novo vyvinutá funkcionalita dostala čo najskôr do živého prostredia. Aj nám sa potvrdilo praxou, čím rýchlejšie sa skracuje čas medzi vývojom a nasadením, tým lepšie.

Zo začiatku sme skúšali feature branch, avšak nevyhli sme sa problémom so zlučovaním kódu. Naraz pribudlo veľa kódu v hlavnej vetve, čo spôsobilo problémy a celý proces nasadzovania nových verzií sa spomalil. Preto sme prešli k používaniu vzoru feature flag. Kód sa stále nachádza v hlavnej vetve (odpadol problém so zlučovaním), ale pre užívateľov sa stal neviditeľný. Funkcionalitu najprv zapneme v testovacom prostredí a až po dôkladnom testovaní ju spustíme v živom prostredí. Ukázalo sa, že takýto vývoj  nám nespomaľuje nasadzovanie nových verzií. Využitie tohto vzoru však ešte nekončí. Často nové produkty najprv sprístupníme len pre časť zákazníkov (napr. pochádzajúcich zo Slovenska) a keď nezachytíme problémy, sprístupníme ju pre všetkých.

Strangler pattern využívame menej často. Predsa len prestavuje komplikovanejší vzor. V startupe sa vyvíja hlavne nová funkcionalita a menej sa robí veľký refactoring alebo zmena starej funkcionality za novú. S úspechom sme ho využili pri kritickej zmene ukladania dát. V prvej fáze, ktorú sme implementovali, sme ukladali záznamy do starých tabuliek a zároveň do nových, pričom na čítanie sa používali staré tabuľky. Keďže sme chceli mať istotu, nechali sme systém bežať niekoľko týždňov, a celý čas sme porovnávali obsah v starých a nových tabuľkách. Keď sme nezaznamenali žiadny rozdiel, prešli sme do fázy dva, kde sme na čítanie začali používať nové tabuľky, pričom sme stále zapisovali dáta aj do starého systému. Po dlhšej dobe, keď sme s novým systémom nemali žiaden problém, odstavili sme starý systém úplne. Ako je vidieť, v každej fáze okrem poslednej, sme sa vedeli jednoducho vrátiť k starému systému. To nám umožnilo minimalizovať riziko a nasadiť kľúčové komponenty bez väčších problémov. Tento postup môže byť relatívne pomalý, keďže prechádza cez niekoľko fáz a v závislosti na ich dĺžke sa môže natiahnuť na niekoľko týždňov. Preto ho používame len pri nasadzovaní kritických častí aplikácie.

Záver

V tomto blogu sme opísali spôsoby ako vyvíjať čo najrýchlejšie s minimom chýb. Použitie Feature Flag výrazne zefektívňuje nový vývoj a Strangler pattern nám pomáha zamedziť chybám pri komplikovanom nahrádzaní existujúcej funkcionality. Na základe vlastných skúseností vo Fumbi ich môžeme doporučiť. 

Zdroje

[1] Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers)  Michael T. Nygard 2017 0978739213 Pragmatic Bookshelf
[2] Refactoring Martin Fowler 2018 Addison-Wesley Professional 0-13-475759-9
[3] Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations Nicole Forsgren PhD 2018  1942788339 IT Revolution Press
[4] Code That Fits in Your Head: Heuristics for Software Engineering (Robert C. Martin Series) Mark Seemann 2021 Addison-Wesley Professional 0137464401
[5] Building Microservices: Designing Fine-Grained Systems Sam Newman 2021 1492034029 O’Reilly Media; 2nd edition