Od MDSO k ONEPOST: jak na REBRANDING appky / díl 3

V minulé epizodě jsme společně s UX/UI designérem Vojtou rozebrali vizuální proměnu ONEPOSTu do posledního pixelu – od prvních skic až po finální logo. Teď se ale přesuneme do zákulisí, které není tolik vidět, ale rozhodně se tam děly velké věci.

Třetí díl naší minisérie ti ukáže, jak rebranding vypadal z technické perspektivy. DevOps Engineera by možná na první dobrou nenapadlo, že změna názvu a barviček může ovlivnit i infrastrukturu. Jenže pod kapotou jsme to celé přestavěli – od domén, přes CI/CD pipeline, až po monitoring a přechod do vlastního AWS accountu.

V tomhle díle tě čeká pohled do zákulisí velké migrace, spousta vychytávek, trochu stresu se SOLRem a hlavně poučení, že dobrý rebranding nezačíná ani nekončí jen na frontendu.

🔧 Technické dopady rebrandingu 

Co pro tebe jako DevOps engineera znamenal rebranding z technického hlediska? Co všechno se muselo změnit pod kapotou? 

Pod kapotou se toho změnilo hodně. Společně s rebrandingem, který je na první pohled vidět, jsme se svezli a udělali velké infrastrukturní změny, které pro uživatele naopak vůbec vidět nejsou. Dohnali a splatili jsme technický dluh, jako například přesun do vlastního AWS accountu, aby všechny prostředky pro ONEPOST byly oddělené. 

Které části infrastruktury byly rebrandingem nejvíce ovlivněné – domény, CI/CD pipeline, monitoring…? 

Setup cloudu, tj. AWS. Přesun do vlastního AWS accountu znamenal vytvořit celé prostředí znovu, takže kde chyběl Terraform kód popisující infrastrukturu, byl přidán, zrevidovali jsme všechny síťové požadavky, práva (IAM) a připravili se na přepnutí ze “starého” na “nové”. 

Jak jste řešili přechod na novou URL / doménu? Byly s tím spojené nějaké technické komplikace nebo rizika? 

Samotné přepnutí komplikované nebylo, nové i staré prostředí běželo vedle sebe už nějakou dobu, funkčnost tedy byla ověřená a bez problémů. Finální přepnutí znamenalo krátký výpadek služby v nočních hodinách, kvůli přesunu dat SOLRu, který byl lehce komplikovanější, ale poctivě nacvičený a nasimulovaný, takže ani tady žádná překvapení nebyla. 

 🚧 Výzvy a řešení 

Co byla nejnáročnější část celého procesu z tvého pohledu? A co tě naopak překvapilo, že šlo hladce? 

Přesun dat, byl trochu strašák, hlavně SOLR, tam to zabralo nějaký čas příprav, než jsme si byli opravdu jistí, že to máme pod kontrolou. 

Naopak velmi hladce šlo vše po aplikační stránce věci. Množství změn a refactoringu který se do rebrandingu dostal byl velký, jak na aplikační tak na infra vrstvě, ale vše si sedlo bez problémů a katastrof. 

Musel jsi kvůli rebrandingu zavést nějaké nové technologie nebo změnit zaběhlé postupy? 

Nic výrazně nového. Jen dohánění restů, jako kompletní pokrytí infrastruktury kódem a použití GitOps (FluxCD), kde ještě nebyl. 

Jak jste zajistili, že při změně názvu a URL vše běželo dál bez výpadků a zásahu do běžného provozu pro zákazníky? 

Původní domény zůstaly dál funkční, aby uživatelé nebyli překvapení, proč jim najednou aplikace, zažité postupy a uložené bookmarky v prohlížeči nefungují. Z původních domén je uživatel přesměrován do aplikace na nové doméně app.onepost.cz. 

Jaký byl váš plán záloh, nebo krizového scénáře, kdyby se něco během přechodu pokazilo? 

Vrátit zpět by se bylo možno teoreticky kdykoli, ale množství práce a komplikací se zvyšuje s postupem času. V momentu, kdy začnou novou aplikaci reálně používat uživatelé, už je ten návrat docela těžký. Takže nasazení rebrandingu, zveřejnění pro uživatele a jednotlivě infrastrukturní přesuny byly postupné, abychom mohli sledovat chování aplikace a mohli reagovat na problémy krůček po krůčku. Snažili jsme se vyvarovat jedné obrovské změně v jeden moment. 

🔍 Monitoring a stabilita 

Jak jste monitorovali stav aplikace během přechodu na nový brand? Sledujete nějaké specifické metriky, které by mohly indikovat problémy? 

Známe historické trendy z provozu, víme, co očekávat. Takže jsme se zaměřovali na ukazatele, které normálně sledujeme každý den. Od klasického vytížení serverů, přes 5xx odpovědi a výjimky v logu aplikací, až po věci typu nově založené schránky nebo přijaté a odeslané zprávy.  

Došlo během nasazení k nějakým incidentům nebo anomáliím, které jste museli řešit? 

Nic se nepřihodilo. Šlo to jako po másle. Až podezřelá nuda. 

🔄 Spolupráce a komunikace 

Jak probíhala spolupráce s ostatními – vývojáři, designéry, produkťákem, marketingem…? 

Jsme spolu všichni v jedné kanceláři, to je pro komunikaci obrovská výhoda a možná i jeden z důvodů, proč šlo všechno tak hladce. Cokoli se vyřeší rychle a okamžitě.  

⚙️ DevOps kultura a zpětná vazba 

Vnímal jsi rebranding spíše jako „běžný projekt“, nebo to pro tebe byl významný milník?  

Nebyl to úplně “bězný projekt” nebo úkol, ale spíše větší věc, kterou neděláme běžně a vyžadovalo to větší “koncentraci sil”. Byla by velká škoda, kdyby úsilí tolika lidí, kteří se rebrandinu podíleli, skončilo fiaskem kvůli nějaké technické chybě. Takže z pohledu reputačního rizika, jsme si dali opravdu záležet, aby všechno klaplo. 

Je něco, co bys dnes udělal jinak, s odstupem času? 

Pokud by to šlo, ještě méně “změn” které se do projektu “rebranding” dostaly, pokud přímo s rebrandigem nesouvisí. Jak na aplikační, tak na infra straně. 

💡 Osobní postřehy a doporučení 

Co tě osobně na tomhle projektu nejvíc bavilo? A co tě nejvíc stresovalo? 

Bavilo mě postavit celé prostředí pro aplikaci na AWS od nuly, všechno pokrýt Terraformem a GitOps s FluxCD, zbavit se prohřešků minulosti a mít tak vše “pod kontrolou”. 

Stresující byla data. Hlavně už zmíněný SOLR. Nakonec jsme se skamarádili, ale chvilku to trvalo. 

Jaký poznatek nebo zkušenost si z tohoto rebrandingu odneseš do budoucích projektů? 

Potvrzení dřívější poznatků. Malé změny. Krátké iterace. Co neměříme, to nevíme, to neumíme jistě a správně rozhodnout.