Modifica un sistema esistente in sicurezza

Individua i contratti attorno alla modifica

Il software esistente ha chiamanti, dati archiviati, job pianificati e procedure operative. Alcune dipendenze non sono visibili nel file che vuoi modificare. Un agente può produrre una modifica corretta localmente che viola uno di questi contratti.

Prima dell’implementazione, individua i componenti che leggono e scrivono i dati interessati. Esamina route, job in background, report e integrazioni esterne. Verifica se altri team o vecchie versioni dei client dipendono dal comportamento attuale.

Chiedi all’agente di mostrare le prove di questa mappa. Un risultato di ricerca è un punto di partenza utile, ma le chiamate dinamiche e i sistemi esterni che usano i dati possono richiedere la conferma del responsabile.

Rendi osservabile il comportamento attuale

Per un modulo poco documentato, aggiungi verifiche mirate sui comportamenti che devono restare stabili. Queste verifiche descrivono il contratto attuale. Non dimostrano che ogni comportamento esistente sia desiderabile.

Se il comportamento attuale contrasta con un requisito, registra il conflitto. Non mantenere un difetto di sicurezza solo perché un test lo ha registrato. Ottieni la decisione necessaria per distinguere il comportamento previsto da un difetto.

Usa fixture realistiche senza dati sensibili. Includi vecchie strutture di dati e record incompleti quando possono esistere. Uno schema nuovo verificato solo con dati appena creati può nascondere problemi di migrazione.

Esamina la transizione tra versioni

Considera una rinomina fittizia da customer_name a display_name. Una rinomina immediata può interrompere una vecchia istanza dell’applicazione durante il deployment. Aggiornare entrambi i file in una pull request non rende atomico il deployment.

Un approccio graduale può mantenere la compatibilità:

1. Aggiungi il nuovo campo senza rimuovere quello vecchio.
2. Definisci come le nuove scritture mantengono coerenti i valori richiesti.
3. Completa i record esistenti con un processo di backfill riavviabile.
4. Verifica completezza e comportamento dei componenti che leggono.
5. Sposta le letture sul nuovo campo.
6. Rimuovi il vecchio campo solo quando nessun componente lo usa più.

Il metodo preciso dipende dal database e dai modelli di scrittura. Le scritture doppie possono creare incoerenze se una scrittura fallisce. Può servire una transazione del database o un altro metodo esplicito di sincronizzazione. Non applicare questo esempio senza verificare le garanzie del sistema.

Martin Fowler descrive questa transizione generale come parallel change, detta anche expand-and-contract. L’idea principale è una transizione compatibile prima della rimozione.

Pianifica il recupero separatamente dal rollback

Il rollback del codice ripristina una versione precedente dell’applicazione. Non annulla automaticamente una migrazione dei dati. La vecchia versione potrebbe non comprendere i nuovi dati. Una migrazione distruttiva può eliminare informazioni che un rollback del codice non può recuperare.

Individua l’azione di recupero per ogni passo. Un backfill riavviabile potrebbe essere ripreso in sicurezza. Una trasformazione errata può richiedere una correzione dai dati sorgente conservati. Un’operazione distruttiva può richiedere una procedura di ripristino verificata.

Chiedi chi è responsabile della decisione di recupero e quanto tempo possa richiedere. Non trattare «abbiamo i backup» come prova che il recupero soddisfi il requisito del servizio.

Mantieni la modifica revisionabile

Separa la pulizia non pertinente dalla modifica funzionale. Inserisci nella pull request il piano di compatibilità, i risultati delle verifiche e le condizioni di rimozione. Segnala il punto oltre il quale il rollback richiede altro lavoro.

Un agente può aiutare a esaminare i componenti che usano i dati e preparare il codice di migrazione. Il responsabile deve comunque accettare il piano di transizione e recupero. Il progetto finale è solo una parte di una modifica sicura.