Ændr et eksisterende system sikkert

Identificér kontrakterne omkring ændringen

Eksisterende software har kaldende systemer, lagrede data, planlagte jobs og driftsprocedurer. Nogle afhængigheder er ikke synlige i den fil, du vil redigere. En agent kan skabe en lokalt korrekt ændring, der bryder en af disse kontrakter.

Identificér læsere og skrivere af de berørte data før implementering. Undersøg routes, baggrundsjobs, rapporter og eksterne integrationer. Kontrollér, om andre teams eller ældre klientversioner afhænger af den nuværende adfærd.

Bed agenten vise dokumentationen for kortlægningen. Et søgeresultat er et nyttigt udgangspunkt, men dynamiske kald og eksterne forbrugere kan kræve, at en ansvarlig bekræfter afhængigheden.

Gør den nuværende adfærd observerbar

Tilføj fokuserede kontroller af adfærd, der skal forblive stabil, for et dårligt dokumenteret modul. Kontrollerne beskriver den nuværende kontrakt. De dokumenterer ikke, at al eksisterende adfærd er ønskelig.

Registrér konflikten, hvis nuværende adfærd strider mod et krav. Bevar ikke en sikkerhedsfejl blot fordi en test fastholder den. Få den beslutning, der skal til for at skelne tilsigtet adfærd fra en fejl.

Brug realistiske testdata uden følsomme oplysninger. Medtag gamle datastrukturer og ufuldstændige poster, hvor de kan forekomme. Et nyt skema, der kun testes med nyoprettede data, kan skjule migreringsproblemer.

Gennemgå overgangen mellem versioner

Overvej en fiktiv omdøbning fra customer_name til display_name. En øjeblikkelig omdøbning kan få en gammel applikationsinstans til at fejle under udrulning. Opdatering af begge filer i én pull request gør ikke udrulningen atomisk.

En trinvis tilgang kan bevare kompatibilitet:

1. Tilføj det nye felt uden at fjerne det gamle.
2. Definér, hvordan nye skrivninger holder de nødvendige værdier konsistente.
3. Udfyld eksisterende poster med en proces, der kan genstartes.
4. Verificér fuldstændighed og læsernes adfærd.
5. Flyt læsere til det nye felt.
6. Fjern først det gamle felt, når ingen længere bruger det.

Den præcise metode afhænger af databasen og skrivemønstrene. Dobbelte skrivninger kan skabe inkonsistens, hvis én skrivning fejler. En databasetransaktion eller en anden tydelig synkroniseringsmetode kan være nødvendig. Anvend ikke eksemplet uden at kontrollere systemets garantier.

Martin Fowler beskriver denne generelle overgang som parallel change, også kaldet expand-and-contract. Hovedidéen er en kompatibel overgang før fjernelse.

Planlæg gendannelse særskilt fra rollback

Rollback af kode gendanner en tidligere applikationsversion. Det fortryder ikke automatisk en datamigrering. Den gamle version forstår måske ikke de nye data. En destruktiv migrering kan fjerne oplysninger, som rollback af kode ikke kan gendanne.

Identificér gendannelseshandlingen for hvert trin. En genstartbar udfyldning kan være sikker at genoptage. En forkert transformation kan kræve rettelse ud fra bevarede kildedata. En destruktiv handling kan kræve en verificeret gendannelsesprocedure.

Spørg, hvem der har ansvaret for gendannelsesbeslutningen, og hvor lang tid gendannelsen må tage. Behandl ikke »vi har backups« som dokumentation for, at gendannelsen opfylder tjenestens krav.

Hold ændringen let at gennemgå

Adskil uvedkommende oprydning fra den funktionelle ændring. Medtag kompatibilitetsplan, verifikationsresultater og betingelser for fjernelse i pull requesten. Markér det punkt, hvorefter rollback kræver yderligere arbejde.

En agent kan hjælpe med at undersøge forbrugere og forberede migreringskode. En ansvarlig ejer skal stadig acceptere overgangs- og gendannelsesplanen. Det endelige design er kun én del af en sikker ændring.