|
<< Zobrazit obsah >> Navigace: »Žádné kapitoly před« Aktualizace |
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.
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ývojář naprogramuje daný požadavek podle zadání a kritérií, která byla stanovena v zadání. Dokumentuje implementační specifika.
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.
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í.
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.
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.
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.
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.
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.
Jakmile aktualizaci zveřejníme, tak server KEO4 čeká, až daný zákazník přestane pracovat. Jakmile server KEO4 zjistí alespoň 15 minut neaktivitu (všech pracovníků, 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 pracovníků chtěl KEO4 spustit, program zahlásí, že z důvodu aktualizace je program nedostupný, ale 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 datovém centru.
21:00 - Zákazník stále pracuje a vyvíjí v programu aktivitu, třeba do 23:30 (pak program zavírá a jde domů).
23:45 - Aplikace zjistila, že už zákazník 15 minut nepracuje a nainstaluje aktualizaci.
23:48 - Aplikace je znovu dostupná.
To znamená, že aktualizace 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).
Pokud je spuštěn klient poprvé od instalace nové verze na serveru; obsluha je upozorněna, ž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 datového centra ALIS.
U vlastních serverů si spouštění aktualizací můžete řídit sami. Záleží na tom, jak je systém nastavený. Buď se nastaví automatická aktualizace v danou hodinu (např. v noci), nebo se nastaví právo na aktualizace třeba jednomu člověku u vás a ten aktualizaci spouští podle svého uvážení.
Pokud je spuštěn klient poprvé od instalace nové verze na serveru; obsluha je upozorněna, že dojde ke stažení nového klienta (trvá zpravidla 1 minutu podle rychlosti připojení klienta k lokálnímu serveru KEO4).
Aktualizační balíček klienta KEO4 se stahuje z lokálního serveru KEO4.