Případová studie

Jak jsme v Autixu zkrotili technický dluh a ukázali cestu z monolitu

Mise Autixu je budovat robustní Dealer Management System (DMS) pro dealery aut. Systém pokrývá prakticky vše - fakturaci, skladové procesy, objednávky, katalog náhradních dílů i klientská data. Na začátku ale věděli, že mají problém: aplikace stála na křehkém technologickém základu a bez změn by dlouhodobě neobstála.

Problém

Překážky

01
  • Technický dluh. Aplikace na Nette s balíčky, které se už nevyvíjely.
  • Chybějící DevOps. Žádná dockerizace, žádné CI/CD, minimum testů.
  • Chybějící procesy. Tým fungoval spíš ad-hoc, bez jasně nastavených postupů a rytmu. Bylo potřeba zavést metodiku, která by vývoj stabilizovala a zpřehlednila.
  • Tlak byznysu. Paralelně s nápravou chtěl klient rychle vyvíjet nové funkce kvůli certifikacím od automobilek.

Řešení

Zlomový bod

Ve chvíli, kdy se ukázalo, že bez technického narovnání projekt narazí na limity, rozhodl se Autix přizvat externí partnery. Cílem bylo dostat projekt pod kontrolu - technicky i procesně.
02

Naše role

  • Technické narovnání. Připravili jsme docker image pro lokální vývoj, nastavili CI/CD v GitLabu a zavedli testování. Vývojáři konečně mohli vyvíjet v předvídatelném prostředí.
  • Procesní změna. Zavedli jsme Scrum: sprinty, stand-upy, grooming, retrospektivy. Tým začal fungovat systematicky a byznys dostal poprvé přehled, co se kdy dodá.
  • Architektura. Ukázali jsme cestu ven z monolitu. Vyvinuli jsme první malou mikroservisu v Symfony - objednávkový formulář s plným test coverage. Fungovala bez problémů a prokázala, že cesta k mikroservisám je reálná.
Výsledek

Výsledek

03
  • Stabilnější prostředí = méně hašení požárů. Díky dockerizaci a CI/CD ubylo incidentů hlášených od klientů. Tým mohl konečně trávit čas vývojem nových funkcí místo neustálým hasičským zásahům.
  • Lepší komunikace = konec “nestihli jsme to“. Scrum rytmus nastavil jasná očekávání. Business konečně věděl, co dostane každých 14 dní, a dramaticky se snížil počet situací, kdy slyšeli “nestihli jsme to“.
  • První mikroservisa = větší klid na všech stranách. Izolované služby znamenaly, že když něco selže, nepadá celý systém. Méně paniky, méně incidentů, více prostoru pro rozvoj.
  • Atmosféra v týmu. Pročistil se vzduch. Najednou všichni táhli za jeden provaz s jasným směrem a cílem. Z ad-hoc reaktivního fungování se stal koordinovaný tým.

Příležitost

Lessons learned

04
  • Technický dluh nepočká. Čím dřív se začne řešit, tím dřív se byznys může spolehnout na stabilní vývoj.
  • Monolit vs. mikroservisy. Když v monolitu něco spadne, padá všechno. Mikroservisy umožňují stabilitu a rychlejší inovace.
  • Procesy dávají klid. Transparentní Scrum rytmus znamenal, že byznys konečně věděl, na čem je.
  • Technologie je potřeba volit s rozmyslem. Nette v tomto případě ukázalo limity - a lekci, že udržitelnost stacku je klíčová.

Potřebujete pomoct nebo poradit s vaším IT řešením?