Wijzig een bestaand systeem veilig

Identificeer contracten rond de wijziging

Bestaande software heeft aanroepers, opgeslagen gegevens, geplande taken en beheerprocedures. Sommige dependencies zijn niet zichtbaar in het bestand dat u wilt bewerken. Een agent kan een lokaal correcte wijziging maken die een van deze contracten breekt.

Identificeer vóór implementatie welke componenten de betrokken gegevens lezen en schrijven. Inspecteer routes, achtergrondtaken, rapporten en externe integraties. Controleer of andere teams of oudere clientversies afhankelijk zijn van het huidige gedrag.

Vraag de agent het bewijs voor deze kaart te tonen. Een zoekresultaat is een nuttig beginpunt. Bij dynamische aanroepen en externe afnemers kan een verantwoordelijke de dependency moeten bevestigen.

Maak huidig gedrag waarneembaar

Voeg voor een slecht gedocumenteerde module gerichte controles toe rond gedrag dat stabiel moet blijven. Deze controles beschrijven het huidige contract. Ze tonen niet aan dat elk bestaand gedrag wenselijk is.

Leg het conflict vast als huidig gedrag met een eis botst. Behoud geen beveiligingsdefect alleen omdat een test het heeft vastgelegd. Verkrijg het besluit dat nodig is om bedoeld gedrag van een defect te onderscheiden.

Gebruik realistische, niet-gevoelige testdata. Neem oude gegevensvormen en onvolledige records op waar die kunnen voorkomen. Een nieuw schema dat alleen met nieuwe gegevens wordt getest, kan migratieproblemen verbergen.

Review de overgang tussen versies

Neem een fictieve hernoeming van customer_name naar display_name. Direct hernoemen kan tijdens deployment een oude applicatie-instantie laten falen. Beide bestanden in één pull request bijwerken maakt de deployment niet atomair.

Een gefaseerde aanpak kan compatibiliteit behouden:

1. Voeg het nieuwe veld toe zonder het oude te verwijderen.
2. Definieer hoe nieuwe schrijfacties de vereiste waarden consistent houden.
3. Vul bestaande records aan met een herstartbaar proces.
4. Verifieer volledigheid en het gedrag van componenten die gegevens lezen.
5. Laat componenten die gegevens lezen het nieuwe veld gebruiken.
6. Verwijder het oude veld pas als de afnemers ervan verdwenen zijn.

De exacte methode hangt af van de database en schrijfpatronen. Dubbele schrijfacties kunnen inconsistentie veroorzaken als één schrijfactie faalt. Een databasetransactie of andere expliciete synchronisatiemethode kan nodig zijn. Pas dit voorbeeld niet toe zonder de garanties van het systeem te controleren.

Martin Fowler beschrijft deze algemene overgang als parallel change, ook expand-and-contract genoemd. Het kernidee is een compatibele overgang vóór verwijdering.

Plan herstel apart van rollback

Coderollback herstelt een eerdere applicatieversie. Die maakt een datamigratie niet automatisch ongedaan. De oude versie begrijpt de nieuwe gegevens mogelijk niet. Een destructieve migratie kan informatie verwijderen die coderollback niet kan terughalen.

Identificeer de herstelactie voor elke stap. Een herstartbare backfill kan veilig worden hervat. Een verkeerde omzetting kan correctie uit bewaarde brongegevens vereisen. Een destructieve operatie kan een geverifieerde herstelprocedure nodig hebben.

Vraag wie verantwoordelijk is voor het herstelbesluit en hoelang herstel kan duren. Behandel ‘we hebben back-ups’ niet als bewijs dat herstel aan de diensteis voldoet.

Houd de wijziging reviewbaar

Scheid niet-gerelateerd opruimwerk van de functionele wijziging. Geef het compatibiliteitsplan, verificatieresultaten en verwijderingsvoorwaarden in de pull request. Markeer het punt waarna rollback extra werk vraagt.

Een agent kan helpen afnemers te inspecteren en migratiecode voor te bereiden. Een verantwoordelijke moet het overgangs- en herstelplan nog steeds accepteren. Het eindontwerp is maar één deel van een veilige wijziging.