Jaké změny se odehrály na pozadí vývoje

Share
12. 03. 2019

Přechod na agilní vývoj

ISPadmin má za sebou 15 let vývoje od živelného počátku s jedním programátorem po současný stav 10+ programátorů. A změnilo se mnohé – od technologií až po požadavky na dostupnost a kvalitu informačních systémů (IS). Bylo nutné provést zásadní organizační a procesní změny, které vedou k lepším výsledkům zejména v následujících oblastech:

  • Kvalita kódu
  • Testování
  • Rychlost
  • Dodržování termínů
  • Zapracování nových funkcí
  • Kontakt se zákazníkem a support

Vše začíná a končí na požadavcích od Vás – je to uzavřený kruh. Nejsme poskytovateli telekomunikačních služeb, a pokud tedy chceme vyvíjet informační systém šitý na míru Vám, providerům, který bude fungovat dle očekávání a šetřit čas, je nezbytná úzká spolupráce přímo s Vámi.

Kvalita kódu

Integrováním GitLabu do procesu vývoje jsme úspěšně zavedli tzv. „code review“. Zjednodušeně jde o proces, který by měl zaručit, že výsledný kód nebude „ošklivý“, bude dobře čitelný a bezpečný z pohledu nastavených firemních zásad. Cílem je zejména minimalizace nesprávných postupů a z nich vznikajících chyb.

Kvalita budoucího kódu se formuje již ve fázi analýzy, při které jeden z našich software architektů navrhne vhodné řešení zadaného požadavku a doplní potřebné detaily k danému úkolu. Ten si následně přebírá programátor a začíná psát. Nový kód vzniká naprosto izolovaně v oddělené větvi (tzv. branch) od produkčního kódu, ze kterého se vytvářejí aktualizace. Tato branch je průběžně připomínkována vedoucími vývojáři, tedy probíhá review.

Celému procesu přispívá i používání aplikace PhpStorm, která je špičkou na trhu mezi vývojovými prostředími pro programátory a hodně věcí tak ohlídá již při psaní kódu (například duplicity, napovídání funkcí, formátování kódu dle pravidel atd.).
Rutinní záležitostí je pak napsání testu pro aktuálně vytvořenou funkci, který se následně použije v automatických continuous integration (CI) testech.

Dobrý kód vytváří požadovanou stabilitu, rychlost a bezpečnost.

Testování

V minulosti opomíjené téma. Realita je taková, že bez testů se v dnešní zrychlené době neobejde žádná vývojářská firma, včetně nás, pokud chce mít vývojář, provider i koncový zákazník klidné spaní. Nic na tom nemění fakt, že testování je mnohdy časově náročnější než samotný vývoj.

Proč je tak důležité? Celý ekosystém internet, hardware a software zažívá neskutečný boom, který s sebou přináší mnohé obtíže. Největší přítěž zatím dělá bezhlavý hon za bezpečností, počínaje verzemi systémových balíčků, certifikáty a v neposlední řadě také vznikají a zanikají různé frameworky, nástroje, mění se API třetích stran atp. Zároveň však rostou požadavky na stabilitu a rychlost. Tato vzrůstající různorodost systémů a zvyšující se nároky na IS nás vedou k důkladnému testování, které sice ani tak neposkytuje 100% záruku, ale alespoň eliminuje lidskou chybu a potlačuje možnost vzniku opakujících se chyb v programu. Pokud je chyba opravena a doplněna testem, znovu se již nestane.

Aktuálně využíváme zmíněné CI testy a tradiční manuální uživatelskou kontrolu. Pokud je něco špatně, ihned vidíme, co se kde pokazilo a můžeme zjednat nápravu ještě před vydáním kódu do produkční verze, která se pak dostane k Vám.

Rychlost

Nastává trend slučování sítí, kdy jedna instalace ISPadminu řídí stále více koncových klientů a síťových prvků. Východiska jsou bohužel jen dvě: buď posilovat server, anebo optimalizovat kód, čímž je možné ušetřit nemalé prostředky za nákup nového stroje

V rámci posledních 3 let se nám podařilo kompletně přepsat celý kód do posledního Nette frameworku, který plně využívá rychlostního potenciálu PHP 7.2, které je ve zpracování kódu odhadem 5x rychlejší a má zhruba poloviční paměťové nároky. Z praxe již víme, že závislostí ovlivňujících rychlost je více a tak ne všude zrychlení pocítíte. Velkou rychlostní překážkou bylo i rozdělení hlavní plochy na dva framy, kdy v jednom bylo menu a ve druhém obsah. Toto omezení s příchodem verze 5.05 beta1 odpadá a frontend (ta část aplikace, kterou vidíte) reaguje o poznání rychleji

Dalším zlepšením je přechod ze storage enginu MyISAM na InnoDB včetně aktualizace na optimalizovanou verzi MySQL 5.7, kterou používají i giganti jako Facebook nebo Google. Formát InnoDB netrpí na uzamčení celých tabulek při konkurenčním zápisu, jak tomu bylo u MyISAM, čímž se odstranil bottleneck celého systému.

Postupně se také přepisují a optimalizují existující SQL dotazy, které jsou vyhodnoceny jako pomalé.

Dodržování termínů

Po náročném a dlouhém přepisu se nám konečně uvolnily kapacity. Aktuálně máme plán na celý rok 2019, ať už jde o helpdesk, nové grafy, lepší monitoring a správu HW, proces manažer, GPON atd. Funguje zde eskalace termínů plnění, takže máme kompletní informace o stavu vývoje.

Naše vize a cíl je dodávat Vám ty nejžádanější funkce ve stanoveném čase bez zbytečných průtahů.

Zapracování nových funkcí

Snažíme se držet krok s posledními verzemi OS od MikroTiku a Ubiquiti, avšak nezapomínáme ani na hlášené zranitelnosti, API rozhraní, QR kódy, použitelnost uživatelského rozhraní, GPON, IPTV služby a mnohé další technologie. V posledních měsících jsme vytvořili hned několik nástrojů usnadňujících správu MikroTiků a identifikaci napadených zařízení – viz https://wiki.ispadmin.eu/cz/changelog/ispadmin-5-02 a https://wiki.ispadmin.eu/cz/changelog/ispadmin-5-01 .

Jednou z velkých novinek bylo i přepracování implementace SledovaniTV, které s sebou přináší rozšířenou funkcionalitu a nové možnosti nastavení. Více informací najdete zde: https://wiki.ispadmin.eu/cz/changelog/ispadmin-5-04/5-04-beta1 .

Kontakt se zákazníkem a support

V prvé řadě se s Vámi chceme častěji setkávat. Jen tak je možné zajistit, aby Vám ISPadmin dobře sloužil a naplňoval Vaše očekávání. Na support jsme přijali posily, čímž by se měla zkrátit reakční doba a zefektivnit podpora. Zavedli jsme také tři úrovně technické podpory – BASIC, PLUS a PROFI, aby bylo možné zajistit kvalitní podporu pro operátory všech velikostí přesně dle jejich preferencí.

Pomohl Vám tento článek?