Součástí aktualizace KEO4 jsou novinky (změny legislativy, nové věci, vylepšení programu a oprava chyb) nashromážděné zpravidla za měsíc práce vývojářů a testerů.
Vydávání aktualizací je zpravidla vždy na konci každého měsíce a v případě potřeby vydáváme ihned "opravnou" aktualizaci.
Co předchází zveřejnění aktualizace aneb životní cyklus nové verze
Každý požadavek na novou vlastnost, vylepšení, změnu z důvodu měnící se legislativy či zaevidování chyby je nejprve zdokumentován v našem centrálním systému požadavků a je stanovena priorita. Závažné chyby se opravují ihned, nová legislativa podle potřeby a u vylepšení a nových vlastností zvažujeme náklady, naši kapacitu a přínos pro co nejvíc uživatelů.
Než se požadavek začne programovat, specifikují se podrobně jeho vlastnosti, namaluje se grafický návrh (wireframe) a pečlivě se vše zdokumentuje. Tento návrh se probírá v širším kroužku metodiků a předělává se do té doby, než se nám zdá návrh perfektní. Následně se sejdou vývojáři a stanoví odhad pracnosti návrhu. Podle odhadu (náklady), naší kapacity, lobbingu uživatelů a zvážení přínosu vzhledem k ostatním prioritám se stanoví priorita požadavku.
V rámci metodiky Scrum plánujeme v každém týmu práci ve čtrnáctidenních sprintech. Tým každého projektu (modulu) se skládá z programátorů (vývojářů) a ověřovatelů funkčnosti (metodiků).
V každé fázi vývoje jsou implementovány automatické i ruční procesy ohledně zabezpečení.
1. Programování - vývoj
Vývojář naprogramuje daný požadavek podle zadání a kritérií, která byla stanovena v zadání. Dokumentuje implementační specifika.
2. Kontrola - inspekce kódu
Když vývojář dokončí požadavek, předá ho nejprve ke kontrole kódu ostatním vývojářům a ti, pokud najdou v kódu nedostatek, vrací požadavek k dopracování. Dbáme na dobrou dokumentaci kódu, čitelnost kódu a také na to, aby žádná nová úprava nezpomalila aplikaci (a neznamenala nové zatížení databáze ani serverů). Inspekce kódu se dokumentuje.
3. Kontrola - ověření funkčnosti
Až poté, co požadavek projde kontrolou ostatních vývojářů úspěšně, dostane se k ověření. Při ověření se dbá na to, zda výsledek v programu odpovídá kritériím, která byla stanovena v zadání. Pokud se najde nedostatek, zdokumentuje se, a požadavek se vrací zpět na začátek vývojáři k dopracování.
4. Kontrola - automatické testy
Vývojář píše ke každému svému kódu test (další kus programu), který se automaticky spouští při každém sestavení aplikace. Pokud se test kdykoliv v budoucnu rozbije (to znamená, že funkce, která dřív fungovala, už nefunguje), ihned se to tým dozví a musí se to opravit.
5. Kontrola - ruční ověřování požadavku
Před vydáním požadavku (legislativa, nová funkčnost, vylepšení, oprava chyb) v aktualizaci se každý znovu ověřuje na prostředí, které jsme sestavili pro zveřejnění nové aktualizace. Do výkazu se zaeviduje, kdo a kdy danou věc ověřil.
6. Kontrola - ruční ověřování základní funkčnosti
Každý modul obsahuje seznam nezbytné funkčnosti a ta se musí při každé aktualizaci ručně ověřit (i když se v dané části třeba nic neměnilo). Do výkazu se zaeviduje, kdo a kdy danou věc ověřil.
7. Kontrola - ruční kontrola na testovací produkci
Těsně před tím, než se aktualizace zveřejní, provedeme ji na lokálním serveru KEO4 u nás a tam se ještě ručně kontrolují jednotlivé moduly, zda v nich aktualizace proběhla v pořádku.
8. Zveřejnění aktualizace
Teprve poté, co projdou úspěšně změny všemi těmito procesy a nepadá žádný automatizovaný test, přistupujeme ke zveřejnění aktualizace.
Tento náročný a koordinovaný proces v mnohačlenném týmu vývojářů, ověřovatelů, metodiků a techniků je dnes již zavedená rutina v rámci metodiky Scrum a pomáhá nám spousta praktických nástrojů a evidencí. Samotné řízení aktualizací provádíme pomocí robotky Eve, kterou jsme si k tomu vyvinuli a řídíme ji pomocí příkazů ve společném chatu.
Aktualizace serveru
Jakmile aktualizaci zveřejníme, tak server KEO4 čeká, až uživatel daného tenanta přestane pracovat. Jakmile server KEO4 zjistí alespoň 15 minut neaktivitu (všech uživatelů, kteří mohou v dané databázi pracovat), tak se aktualizace na dané databázi provede. Pokud by v tu danou chvíli někdo z uživatelů chtěl KEO4 spustit, program zahlásí, že z důvodu aktualizace je program nedostupný; tento výpadek trvá jen několik minut, zpravidla v noci.
Klasický scénář může vypadat takto:
21:00 - Zveřejňujeme aktualizaci pro KEO4 v cloudu.
21:00 - Uživatel pracuje, vyvíjí v programu KEO4 aktivitu - třeba do 23:30 (pak uživatel program zavírá a jde domů).
23:45 - Aplikace zjistila, že se v daném tenantu 15 minut nepracuje a nainstaluje aktualizaci.
23:48 - Aplikace je znovu dostupná.
To znamená, že aktualizace serveru KEO4 jsou téměř bezvýpadkové a běžně o nich zákazník vůbec neví (probíhají v noci ve chvíli, kdy nikdo nepracuje).
Jak funguje právo "JASADM010 Aktualizace - plný přístup": v případě, že je pro daného tenanta dostupná aktualizace a uživatel vyvíjí aktivitu, tzn. oddaluje provedení aktualizace daného tenanta, může pracovní místo s právem JASADM010 vynutit (urychlit) provedení aktualizace daného tenanta. V rozcestníku je zobrazen modrý pruh a v něm tlačítko, které zahájí aktualizaci (uživatel, který v KEO4 vyvíjí aktivitu, je na tuto situaci upozorněn hláškou).
Aktualizace klienta
Pokud je spuštěn klient poprvé od instalace nové verze na serveru; uživatel je upozorněn, že dojde ke stažení nového klienta (trvá zpravidla 1 minutu podle vašeho připojení).
Aktualizační balíček klienta KEO4 se stahuje z cloudu KEO4.