Canvieu un sistema existent amb seguretat

Identifiqueu els contractes que envolten el canvi

El programari existent té components que el criden, dades emmagatzemades, tasques programades i procediments operatius. Algunes dependències no són visibles al fitxer que voleu editar. Un agent pot produir un canvi localment correcte que trenqui un d’aquests contractes.

Abans de la implementació, identifiqueu els components que llegeixen i escriuen les dades afectades. Inspeccioneu rutes, tasques en segon pla, informes i integracions externes. Comproveu si altres equips o versions antigues dels clients depenen del comportament actual.

Demaneu a l’agent que mostri les evidències d’aquest mapa. Un resultat de cerca és un punt de partida útil, però les crides dinàmiques i els consumidors externs poden requerir que un responsable confirmi la dependència.

Feu observable el comportament actual

En un mòdul poc documentat, afegiu comprovacions centrades en el comportament que ha de romandre estable. Aquestes comprovacions descriuen el contracte actual. No acrediten que tots els comportaments existents siguin desitjables.

Si el comportament actual entra en conflicte amb un requisit, registreu el conflicte. No conserveu un defecte de seguretat només perquè una prova l’hagi recollit. Obteniu la decisió necessària per distingir el comportament previst d’un defecte.

Utilitzeu dades de prova realistes i no sensibles. Incloeu estructures de dades antigues i registres incomplets quan puguin existir. Un esquema nou provat només amb dades acabades de crear pot amagar problemes de migració.

Reviseu la transició entre versions

Considereu un canvi de nom fictici de customer_name a display_name. Un canvi immediat pot fer fallar una instància antiga de l’aplicació durant el desplegament. Actualitzar tots dos fitxers en una pull request no fa que el desplegament sigui atòmic.

Un procés gradual pot conservar la compatibilitat:

1. Afegiu el camp nou sense eliminar l’antic.
2. Definiu com les noves operacions d’escriptura mantindran coherents els valors necessaris.
3. Completeu els registres existents amb un procés que es pugui reiniciar.
4. Verifiqueu que s’hagin completat tots i com es comporten els components que els llegeixen.
5. Feu que els components lectors passin a utilitzar el camp nou.
6. Elimineu el camp antic només quan ja no tingui consumidors.

El mètode exacte depèn de la base de dades i dels patrons d’escriptura. Escriure tant al camp antic com al nou pot introduir incoherències si una de les operacions falla. Pot caldre una transacció de base de dades o un altre mètode explícit de sincronització. No apliqueu aquest exemple sense comprovar les garanties del sistema.

Martin Fowler descriu aquesta transició general com a canvi paral·lel, també anomenat expand-and-contract. La idea clau és fer una transició compatible abans de la retirada.

Planifiqueu la recuperació separadament de la reversió

Revertir el codi restaura una versió anterior de l’aplicació. No desfà automàticament una migració de dades. La versió antiga potser no entén les dades noves. Una migració destructiva pot eliminar informació que una reversió de codi no pot recuperar.

Identifiqueu l’acció de recuperació de cada pas. Pot ser segur reprendre un procés de compleció de dades que es pugui reiniciar. Una transformació incorrecta pot requerir una correcció a partir de les dades d’origen conservades. Una operació destructiva pot requerir un procediment de restauració verificat.

Pregunteu qui és responsable de la decisió de recuperació i quant pot durar. Eviteu tractar «tenim còpies de seguretat» com a evidència que la recuperació compleix el requisit del servei.

Manteniu el canvi fàcil de revisar

Separeu les tasques de neteja no relacionades del canvi funcional. Incloeu a la pull request el pla de compatibilitat, els resultats de verificació i les condicions de retirada. Marqueu el punt a partir del qual la reversió requereix feina addicional.

Un agent pot ajudar a inspeccionar els consumidors i preparar el codi de migració. Un responsable encara ha d’acceptar el pla de transició i recuperació. El disseny final és només una part d’un canvi segur.