Sigurno promijenite postojeći sustav

Utvrdite ugovore sučelja oko promjene

Postojeći softver ima kod koji ga poziva, pohranjene podatke, zakazane poslove i operativne postupke. Neke ovisnosti nisu vidljive u datoteci koju želite urediti. Agent može proizvesti lokalno točnu promjenu koja narušava jedan od tih ugovora.

Prije implementacije utvrdite komponente koje čitaju i zapisuju zahvaćene podatke. Pregledajte rute, pozadinske poslove, izvješća i vanjske integracije. Provjerite ovise li drugi timovi ili starije verzije klijentskih aplikacija o trenutačnom ponašanju.

Zatražite da agent pokaže dokaze za taj pregled. Rezultat pretraživanja korisno je polazište, ali dinamički pozivi i vanjski sustavi koji upotrebljavaju podatke mogu zahtijevati potvrdu ovisnosti od odgovorne osobe.

Učinite trenutačno ponašanje vidljivim

Za slabo dokumentiran modul dodajte usmjerene provjere ponašanja koje mora ostati stabilno. Te provjere opisuju trenutačni ugovor. Ne potvrđuju da je svako postojeće ponašanje poželjno.

Ako trenutačno ponašanje proturječi zahtjevu, zabilježite sukob. Nemojte čuvati sigurnosnu pogrešku samo zato što ju je test zabilježio. Osigurajte odluku potrebnu za razlikovanje namjeravanog ponašanja od pogreške.

Upotrijebite realistične testne podatke bez osjetljivih informacija. Uključite stare strukture podataka i nepotpune zapise gdje se mogu pojaviti. Nova shema testirana samo novostvorenim podacima može sakriti probleme migracije.

Pregledajte prijelaz između verzija

Razmotrite izmišljeno preimenovanje iz customer_name u display_name. Trenutačno preimenovanje može pokvariti staru instancu aplikacije tijekom postavljanja. Ažuriranje obiju datoteka u jednom pull requestu ne čini postavljanje atomarnim.

Postupan pristup može sačuvati kompatibilnost:

1. Dodajte novo polje bez uklanjanja starog.
2. Definirajte kako nove operacije zapisivanja održavaju potrebne vrijednosti usklađenima.
3. Popunite postojeće zapise postupkom koji se može ponovno pokrenuti.
4. Provjerite potpunost i ponašanje komponenti koje čitaju podatke.
5. Prebacite te komponente na novo polje.
6. Uklonite staro polje tek kad nema komponenti koje ga upotrebljavaju.

Točna metoda ovisi o bazi podataka i obrascima pisanja. Dvostruko pisanje može uvesti nedosljednost ako jedna operacija zapisivanja ne uspije. Možda je potrebna transakcija baze podataka ili druga izričita metoda sinkronizacije. Nemojte primijeniti primjer bez provjere jamstava sustava.

Martin Fowler opisuje taj opći prijelaz kao paralelnu promjenu, odnosno expand-and-contract. Ključna je ideja kompatibilan prijelaz prije uklanjanja.

Planirajte oporavak odvojeno od povratka verzije

Rollback koda vraća prethodnu verziju aplikacije. Ne poništava automatski migraciju podataka. Stara verzija možda ne razumije nove podatke. Destruktivna migracija može ukloniti informacije koje rollback koda ne može vratiti.

Za svaki korak utvrdite radnju oporavka. Postupak popunjavanja koji se može ponovno pokrenuti možda je sigurno nastaviti. Pogrešna transformacija može zahtijevati ispravak iz sačuvanih izvornih podataka. Destruktivna operacija može zahtijevati provjeren postupak vraćanja podataka.

Pitajte tko odgovara za odluku o oporavku i koliko oporavak može trajati. Nemojte „imamo sigurnosne kopije” tretirati kao dokaz da oporavak zadovoljava zahtjev usluge.

Održite promjenu preglednom

Odvojite nepovezano čišćenje od funkcionalne promjene. U pull request uključite plan kompatibilnosti, rezultate provjere i uvjete uklanjanja. Označite točku nakon koje rollback zahtijeva dodatan rad.

Agent može pomoći pregledati komponente koje upotrebljavaju podatke i pripremiti migracijski kod. Odgovorna osoba i dalje mora prihvatiti plan prijelaza i oporavka. Konačni dizajn samo je jedan dio sigurne promjene.