Endre et eksisterende system på en trygg måte

Finn kontraktene rundt endringen

Eksisterende programvare har kallere, lagrede data, planlagte jobber og driftsprosedyrer. Noen avhengigheter er ikke synlige i filen du vil redigere. En agent kan produsere en lokalt riktig endring som bryter en av disse kontraktene.

Før implementering må du identifisere hvem som leser og skriver de berørte dataene. Undersøk ruter, bakgrunnsjobber, rapporter og eksterne integrasjoner. Kontroller om andre team eller eldre klientversjoner avhenger av dagens oppførsel.

Be agenten vise bevisene for denne kartleggingen. Et søkeresultat er et nyttig utgangspunkt, men dynamiske kall og eksterne brukere kan kreve at en eier bekrefter avhengigheten.

Gjør dagens oppførsel observerbar

For en dårlig dokumentert modul legger du til målrettede kontroller rundt oppførsel som må forbli stabil. Kontrollene beskriver dagens kontrakt. De fastslår ikke at all eksisterende oppførsel er ønskelig.

Hvis dagens oppførsel strider mot et krav, registrerer du konflikten. Ikke bevar en sikkerhetsfeil bare fordi en test fanget den opp. Innhent beslutningen som trengs for å skille tilsiktet oppførsel fra en feil.

Bruk realistiske, ikke-sensitive testdata. Ta med gamle datastrukturer og ufullstendige opplysninger der de kan forekomme. Et nytt skjema som bare testes med nyopprettede data, kan skjule migreringsproblemer.

Gjennomgå overgangen mellom versjoner

Se for deg en fiktiv navneendring fra customer_name til display_name. En umiddelbar navneendring kan ødelegge for en gammel applikasjonsinstans under utrulling. Å oppdatere begge filene i én pull request gjør ikke utrullingen atomisk.

En trinnvis tilnærming kan bevare kompatibilitet:

1. Legg til det nye feltet uten å fjerne det gamle.
2. Definer hvordan nye skrivinger holder de nødvendige verdiene konsistente.
3. Etterfyll eksisterende opplysninger med en prosess som kan startes på nytt.
4. Verifiser fullstendighet og oppførselen til dem som leser.
5. Flytt leserne til det nye feltet.
6. Fjern det gamle feltet først når ingen bruker det lenger.

Den nøyaktige metoden avhenger av databasen og skrivemønstrene. Dobbeltskriving kan gi inkonsistens hvis én skriving feiler. En databasetransaksjon eller en annen uttrykkelig synkroniseringsmetode kan være nødvendig. Ikke bruk dette eksemplet uten å kontrollere systemets garantier.

Martin Fowler beskriver denne generelle overgangen som parallel change, også kalt expand-and-contract. Hovedideen er en kompatibel overgang før fjerning.

Planlegg gjenoppretting separat fra rollback

Rollback av kode gjenoppretter en tidligere applikasjonsversjon. Den angrer ikke automatisk en datamigrering. Den gamle versjonen forstår kanskje ikke de nye dataene. En destruktiv migrering kan fjerne informasjon som en rollback av kode ikke kan gjenopprette.

Finn gjenopprettingshandlingen for hvert trinn. En etterfylling som kan startes på nytt, kan være trygg å gjenoppta. En feil transformasjon kan kreve retting fra bevarte kildedata. En destruktiv operasjon kan kreve en verifisert gjenopprettingsprosedyre.

Spør hvem som eier beslutningen om gjenoppretting, og hvor lang tid den kan ta. Unngå å behandle «vi har sikkerhetskopier» som bevis på at gjenopprettingen oppfyller tjenestens krav.

Hold endringen mulig å gjennomgå

Skill opprydding som ikke hører til oppgaven, fra den funksjonelle endringen. Legg kompatibilitetsplanen, verifikasjonsresultatene og vilkårene for fjerning i pull requesten. Marker punktet der rollback krever ekstra arbeid.

En agent kan hjelpe med å undersøke brukere av grensesnittet og forberede migreringskode. En ansvarlig eier må fortsatt godta overgangs- og gjenopprettingsplanen. Det endelige designet er bare én del av en trygg endring.