Séria: Ako písať dokumentáciu a manuály v IT projekte
Reálny problém z praxe
Nasadili sme novú verziu.
Niečo prestalo fungovať.
Nikto presne nevedel:
- čo všetko sa menilo v databáze
- ktoré skripty už boli spustené
- čo treba vrátiť späť
Rollback nebol pripravený.
A systém sa nedal rýchlo stabilizovať.
Problém nebol v kóde.
Bol v tom, že nasadenie nebolo riadené.
Čo sa tu vlastne pokazilo (analýza systému)
Nasadenie a upgrade existovali ako „proces v hlavách“.
- vývoj vedel, čo zmenil
- tester vedel, čo testoval
- admin vedel, čo nasadzoval
Ale neexistoval spoločný zdroj pravdy.
Chýbalo:
- prepojenie medzi zmenou a databázou
- evidencia vykonaných krokov
- kontrola, že všetko je zahrnuté v upgrade
To je typická situácia:
- systém funguje, kým sa nič nepokazí
Skutočné náklady (čas, chaos, riziko)
Ak nemáš riadený upgrade a rollback:
- nasadenie je rizikové
- rollback je improvizácia
- databáza sa dostáva do nekonzistentného stavu
- tím nevie, čo presne je nasadené
- incidenty sa riešia pomaly
A najhoršie:
„Nevieme, čo všetko sa zmenilo.“
Minimálny model riešenia
Cieľ nie je mať dlhý dokument.
Cieľ je mať kontrolu nad zmenami.
1. Evidencia databázových zmien
Každá zmena v databáze musí byť:
- zaznamenaná
- otestovaná
- prepojená s upgrade
Ty si to riešila prakticky:
Vytvorila si tabuľku, kde bolo evidované:
- ktorý SELECT (alebo skript) bol vykonaný
- v ktorom testovacom prostredí
- či bol zahrnutý do upgrade
To je presne to, čo chýba vo väčšine tímov.
2. Prepojenie na workflow (Jira)
Zaviedla si automatizáciu:
- keď vývojár zmenil stav tasku
- vytvorila sa úloha pre testera (overiť databázu)
- a úloha pre admina (zahrnúť do upgradu)
To znamená:
- zmena sa nedá „zabudnúť“
To už nie je dokumentácia.
To je kontrolný mechanizmus kvality.
3. Štruktúra kapitoly „Upgrade“
Admin príručka musí obsahovať:
Pred upgrade:
- záloha databázy
- kontrola verzií
- zoznam zmien
Počas upgrade:
- spustenie skriptov
- nasadenie verzie
- kontrola priebehu
Po upgrade:
- overenie funkčnosti
- kontrola logov
- základný test
Bez tejto štruktúry je upgrade len „spustenie balíka“.
4. Rollback (najčastejšie chýbajúca časť)
Rollback musí odpovedať na:
- kedy je možný
- ako sa vykoná
- čo sa obnovuje (DB, konfigurácia, verzia)
- čo sa môže stratiť
Príklad:
Ak zmena upraví databázovú schému a neexistuje záloha, rollback nie je možný.
Toto musí byť explicitne uvedené.
5. Prepojenie na databázu
Najväčšie riziko upgrade je databáza.
Dokumentácia musí obsahovať:
- zoznam zmien v DB
- poradie ich vykonania
- závislosti medzi nimi
Bez toho vzniká chaos.
6. Prepojenie na testovanie
Tester by nemal testovať len funkcionalitu.
Musí vedieť:
- čo sa mení v databáze
- čo sa má overiť po upgrade
- či je možné rollback otestovať
Ty si to vyriešila systémovo:
- tester overuje databázové zmeny
- admin ich implementuje do upgradu
To je ideálny stav.
Mini checklist
- Sú všetky databázové zmeny evidované?
- Sú prepojené s konkrétnymi taskmi?
- Existuje kontrola, že sú zahrnuté v upgrade?
- Je definovaný postup pred, počas a po upgrade?
- Existuje reálny rollback scenár?
- Vie tím, čo presne bolo nasadené?
Ak nie, upgrade je riziko.
Prepojenie na kvalitu a workflow
Nasadenie nie je technická operácia.
Je to moment, keď sa rozhoduje o kvalite.
Bez riadenia:
- vznikajú incidenty
- rastie závislosť na konkrétnych ľuďoch
- tím stráca kontrolu nad systémom
Tvoj príklad to ukazuje presne:
Automatizácia v Jire + evidencia databázových zmien
= prepojenie vývoja, testovania a prevádzky
Krátke zhrnutie
Upgrade a rollback nie sú „technická kapitola“.
Sú to kritické scenáre systému.
Administrátorská príručka musí obsahovať:
- evidenciu zmien
- riadený upgrade
- funkčný rollback
Ak nevieš presne povedať, čo si nasadila a ako to vrátiť späť,
nemáš systém pod kontrolou.