Ändra ett befintligt system säkert

Identifiera kontrakten runt ändringen

Befintlig programvara har anropare, lagrade data, schemalagda jobb och driftrutiner. Vissa beroenden syns inte i filen du vill redigera. En agent kan skapa en lokalt korrekt ändring som bryter ett av dessa kontrakt.

Identifiera vilka som läser och skriver berörda data före implementationen. Granska router, bakgrundsjobb, rapporter och externa integrationer. Kontrollera om andra team eller äldre klientversioner är beroende av dagens beteende.

Be agenten visa underlaget för kartan. Ett sökresultat är en användbar utgångspunkt, men dynamiska anrop och externa konsumenter kan kräva att en ansvarig bekräftar beroendet.

Gör dagens beteende observerbart

Lägg till fokuserade kontroller av beteende som måste förbli stabilt i en dåligt dokumenterad modul. Kontrollerna beskriver det aktuella kontraktet. De fastställer inte att varje befintligt beteende är önskvärt.

Dokumentera konflikten om dagens beteende strider mot ett krav. Bevara inte ett säkerhetsfel bara för att ett test fångade det. Inhämta beslutet som behövs för att skilja avsett beteende från ett fel.

Använd realistiska testdata utan känsliga uppgifter. Ta med gamla datastrukturer och ofullständiga poster där de kan förekomma. Ett nytt schema som bara testas med nyskapade data kan dölja migreringsproblem.

Granska övergången mellan versioner

Betrakta ett fiktivt namnbyte från customer_name till display_name. Ett direkt namnbyte kan få en gammal applikationsinstans att fallera under driftsättningen. Att uppdatera båda filerna i en pull request gör inte driftsättningen atomär.

En stegvis metod kan bevara kompatibiliteten:

1. Lägg till det nya fältet utan att ta bort det gamla.
2. Definiera hur nya skrivningar håller de nödvändiga värdena konsekventa.
3. Fyll i befintliga poster med en process som kan startas om.
4. Verifiera fullständigheten och läsarnas beteende.
5. Flytta läsare till det nya fältet.
6. Ta bort det gamla fältet först när inga komponenter längre använder det.

Den exakta metoden beror på databasen och skrivmönstren. Dubbla skrivningar kan skapa inkonsekvens om en skrivning misslyckas. En databastransaktion eller en annan uttrycklig synkroniseringsmetod kan behövas. Använd inte exemplet utan att kontrollera systemets garantier.

Martin Fowler beskriver den allmänna övergången som parallel change, även kallad expand-and-contract. Grundidén är en kompatibel övergång före borttagning.

Planera återställning separat från rollback

Rollback av kod återställer en tidigare applikationsversion. Den ångrar inte automatiskt en datamigrering. Den gamla versionen kanske inte förstår de nya data. En destruktiv migrering kan ta bort information som rollback av kod inte kan återställa.

Identifiera återställningsåtgärden för varje steg. En återstartbar komplettering av befintliga data kan vara säker att återuppta. En felaktig omvandling kan kräva korrigering från bevarade källdata. En destruktiv operation kan kräva en verifierad återställningsrutin.

Fråga vem som ansvarar för återställningsbeslutet och hur lång tid det kan ta. Behandla inte ”vi har säkerhetskopior” som belägg för att återställningen uppfyller tjänstens krav.

Håll ändringen möjlig att granska

Skilj orelaterad städning från funktionsändringen. Ta med kompatibilitetsplan, verifieringsresultat och villkor för borttagning i pull requesten. Markera punkten efter vilken rollback kräver ytterligare arbete.

En agent kan hjälpa till att granska konsumenter och förbereda migreringskod. En ansvarig måste fortfarande acceptera övergångs- och återställningsplanen. Den slutliga utformningen är bara en del av en säker ändring.