Střet s produkční realitou

AI změnila aplikaci. Aktualizace změnila vaše plány.

Berte incident jako regresi, ne jako pozvánku k deseti spekulativním promptům. Nejprve obnovte službu, potom vylepšujte.

01

Co se stalo?

Generovaná aktualizace může sáhnout do vzdálených souborů, balíčků, schématu i konfigurace. Skutečný rozsah ukazuje diff, ne shrnutí agenta.

02

Proč se to děje

  • Široká editace přidala změny mimo původní úkol.
  • Frontend, backend a databáze se posunuly každý jinam.
  • Nevratná migrace znemožnila prostý rollback aplikace.

03

Co můžete zkontrolovat sami

  1. Najděte přesně poslední dobrou a první vadnou verzi.
  2. Porovnejte kód, lockfile, konfiguraci i migrace.
  3. Před rollbackem zjistěte, zda vydání změnilo produkční data.

NEJSTE VÝVOJÁŘ

Teď jsou důležitější dvě věci — a není to kód.

Nemusíte číst aktualizaci, abyste pomohli. Stačí popsat, co se změnilo z vašeho pohledu.

  1. Přestaňte žádat o další opravy nad rámec aktualizace — časovou osu to jen víc zamotá, ne rozmotá.
  2. Napište si přesně, co fungovalo předtím a co přestalo fungovat po aktualizaci.
  3. Poznamenejte si, jestli od nasazení aktualizace aplikaci někdo používal, zadával data nebo nakupoval — ovlivňuje to, jestli je rollback bezpečný.
  4. Uchovejte předchozí funkční verzi, nespoléhejte se na to, jak si pamatujete, že to fungovalo.

S touhle časovou osou dokáže Shipvise nebo vývojář izolovat změnu a rozhodnout, jestli je bezpečnou cestou zpět rollback, oprava, nebo obojí.

04

Jak opravu bezpečně ověřit

Opravu dejte do samostatné větve, ověřte ji v produkčně podobném stagingu a nasaďte konkrétní schválenou verzi. Předem si ponechte funkční artefakt a ověřený postup rollbacku.

05

Kdy potřebujete vývojáře

Seniorního vývojáře přizvěte, když změna sahá do dat, přihlášení, oprávnění, plateb nebo infrastruktury, případně když nikdo nedokáže vysvětlit příčinu. Shipvise spojuje staging, automatické kontroly, AI nebo seniorní review, řízené nasazení, hosting a rollback.

FAQ

Na co se lidé skutečně ptají

Mám okamžitě udělat rollback?

Při významném dopadu a známém bezpečném postupu ano. Nejdřív ověřte databázi a externí side effects.

Mohu věřit souhrnu změn od AI?

Použijte ho jako orientaci. Zdrojem pravdy je diff, historie příkazů a nasazený commit.

Jak tomu příště zabráním?

Používejte malé větve, automatické kontroly, staging, kontrolované diffy, explicitní schválení a natrénovaný rollback při každém produkčním vydání.

Jak vrátím aplikaci zpátky, když nepoužívám Git?

Zkontrolujte, jestli váš AI nástroj nemá historii verzí nebo checkpointů, případně předchozí export nebo nasazení, které lze obnovit. Bez toho požádejte AI, aby přesně ukázala, co v aktualizaci změnila, a tyhle konkrétní změny pak vraťte zpět místo hádání.

Co když aktualizace změnila i databázi, ne jen kód?

Pak prostý rollback kódu nestačí — vrácení verze aplikace může způsobit, že nebude sedět k datům. Před rollbackem zjistěte, jestli aktualizace spustila nějaké migrace nebo změnila tvar dat, a ověřte, že se mezitím nic důležitého neuložilo podle nové struktury.

Mám nechat AI opravit vlastní aktualizaci, nebo začít znovu?

Nejdřív ji nechte vysvětlit, co a proč změnila. Pokud je oprava malá a dá se ověřit proti původnímu problému, oprava stačí; pokud vysvětlení nesedí nebo změna zasáhla spoustu souborů, obvykle je rychlejší a bezpečnější vrátit se k poslední funkční verzi.