Migrazione ecommerce senza downtime: blue-green, DNS e rollback

Senza downtime è un obiettivo operativo, non una promessa assoluta

Una migrazione ecommerce coinvolge molto più del trasferimento di un'applicazione. Nel percorso che porta una visita a diventare ordine entrano DNS, CDN, certificati TLS, storefront, API, sessioni, cache, database, media, pagamenti, code, webhook, analytics, consenso e servizi email. Definire la migrazione come una semplice accensione del nuovo hosting nasconde proprio le dipendenze che possono interrompere il funnel. L'obiettivo realistico è ridurre l'interruzione percepita, limitare l'esposizione al rischio e mantenere una via di ritorno verificata.

Il modello blue-green aiuta perché conserva due ambienti paralleli: blue è quello stabile che serve gli utenti, green è il candidato costruito e testato. Microsoft documenta questo schema con revisioni separate, test dell'ambiente green e spostamento del traffico, lasciando possibile il ritorno a blue. Il principio è portabile, ma non garantisce da solo continuità: dati mutabili, DNS e integrazioni esterne richiedono un piano dedicato.

Inventariare l'intero percorso prima di progettare il cutover

Dal dominio alla conferma ordine

Disegna una mappa end-to-end, non soltanto un diagramma dei server. Registra autorità DNS, record, proxy, CDN, certificati, regole di redirect, runtime del frontend, API, motore di ricerca, storage dei media, cache e servizi di autenticazione. Aggiungi il percorso commerciale: scheda prodotto, disponibilità, carrello, promozioni, checkout, pagamento, callback, creazione ordine, aggiornamento inventario, email e area cliente. Per ciascun elemento indica proprietario, configurazione, segreto o certificato necessario, dipendenze e segnale osservabile.

Completa l'inventario con code, job pianificati, webhook in entrata e in uscita, feed marketplace, analytics e gestione del consenso. Questi componenti possono continuare a puntare al vecchio ambiente anche quando la homepage appare corretta. L'elenco diventa la matrice di test, il perimetro del monitoraggio e la base per decidere cosa congelare, sincronizzare o riconfigurare.

Costruire green come artefatto identificabile e ripetibile

Una release immutabile, non una copia che cambia

Distribuisci su green una build identificata da commit e build ID immutabili. Versioni del runtime, dipendenze, configurazione e migrazioni devono essere riproducibili. Evita modifiche manuali effettuate solo sul nuovo server: rendono difficile sapere che cosa è stato testato e quasi impossibile ricostruire l'ambiente dopo un rollback. Blue e green possono avere capacità o implementazioni diverse, ma il loro confine deve essere documentato.

Esponi green mediante un hostname temporaneo o un indirizzo ristretto, protetto dall'accesso pubblico e tenuto fuori dall'indice. La guida di Google sul cambio hosting raccomanda di preparare e testare il nuovo sito, impedire l'indicizzazione dell'hostname di prova e verificare che Googlebot possa poi raggiungere il sito pubblico. Controlla certificati, header, canonical, robots, sitemap e redirect nel contesto reale, evitando che le protezioni della preview finiscano nella configurazione di produzione.

Provare journey, localizzazioni e integrazioni sul target

Esegui smoke test e prove sintetiche su navigazione, ricerca, pagina prodotto, carrello, coupon, login, reset password, checkout, pagamento di test e conferma ordine. Ripeti i percorsi nelle lingue e valute rilevanti e verifica asset, immagini, font, moduli, email e collegamenti interni. Per callback e webhook usa eventi controllati, chiavi di idempotenza e destinazioni non produttive quando il fornitore lo consente; una prova non deve creare addebiti o ordini ambigui.

Collega ogni test al build ID di green e conserva l'esito. Aggiungi controlli su errori applicativi, latenza, dipendenze, log e code. Nessuna singola pagina verde certifica il sistema: il gate è superato soltanto quando i percorsi definiti come critici producono lo stato atteso e i segnali sono attribuibili allo stesso artefatto che riceverà traffico.

Trattare lo stato mutabile come un workstream separato

Sincronizzazione, freeze e compatibilità

Il pattern blue-green replica l'ambiente di esecuzione, non protegge automaticamente database, ordini o inventario. Definisci dove viene scritto ogni dato durante preparazione, cutover e osservazione. Scegli consapevolmente tra sincronizzazione, replica, una finestra di freeze o una procedura applicativa compatibile con entrambi gli ambienti. La strategia dipende dallo stack e deve essere provata su copie rappresentative; non introdurre dual write improvvisati senza idempotenza, ordinamento e riconciliazione.

Stabilisci quale schema può essere letto da blue e green e quali modifiche renderebbero impossibile tornare indietro. Prima del cambio misura ordini, clienti, inventario, media e backlog; ripeti il confronto dopo ogni fase. Se green accetta scritture, il rollback di routing non basta: occorre riportare o riconciliare i dati prodotti nell'intervallo, con proprietari e procedura già assegnati.

Preparare DNS e instradamento senza confondere TTL e certezza

Abbassa il TTL con anticipo coerente con l'autorità DNS e con la configurazione corrente, poi verifica record, certificati e capacità di blue e green. Il TTL indica quanto a lungo un record può restare in cache; non è un conto alla rovescia che garantisce la propagazione completa. Cloudflare segnala inoltre che cache locali possono conservare risposte più a lungo. Mantieni quindi entrambi gli ambienti raggiungibili durante la finestra osservativa.

Quando la piattaforma lo supporta, uno schema di weighted routing può spostare gradualmente le richieste tra risorse dello stesso dominio. AWS Route 53 ne offre un'implementazione con pesi relativi e health check: è un esempio specifico del fornitore, non una percentuale o una procedura universale. Se non esiste instradamento progressivo, prepara un cutover DNS netto con monitoraggio da più resolver e una modifica inversa già provata.

Usare gate oggettivi per avanzare o tornare a blue

Definisci prima del cutover chi decide e quali segnali fermano la progressione. I gate possono includere tasso di errori, latenza, successo del checkout, ordini creati, callback di pagamento, backlog delle code, errori webhook, coerenza inventario e accesso dei crawler. Baseline, soglie e finestra di osservazione dipendono dal traffico e dal rischio del negozio; evita valori copiati da un runbook generico.

Il rollback deve specificare instradamento, configurazioni, processi asincroni e riconciliazione delle scritture effettuate su green. Tieni blue in servizio, con capacità e credenziali valide, finché la decisione non è conclusa. Provare il ritorno in una simulazione controllata rende visibili autorizzazioni mancanti, record non modificabili e procedure troppo lente prima che siano necessarie in produzione.

Osservare entrambi gli ambienti e dismettere con prudenza

• Traffico: controlla richieste e codici di risposta su blue e green da più punti di osservazione.
• Commercio: riconcilia checkout, pagamenti, ordini, inventario e notifiche.
• Integrazioni: verifica callback, webhook, code, feed, analytics e consenso.
• Ricerca: monitora accesso dei crawler, sitemap, robots, canonical e redirect.
• Release: collega log, metriche e alert al build ID effettivamente servito.

Google raccomanda di osservare i log del vecchio e del nuovo hosting e di spegnere il precedente solo quando non riceve più traffico. Anche allora conserva backup, audit e piano di ripristino secondo le policy aziendali. La migrazione è conclusa quando il sistema e i dati sono stabili, non quando il primo resolver restituisce il nuovo indirizzo. Per progettare ambienti, DNS e osservabilità coerenti, consulta i nostri servizi ecommerce e infrastrutturali.

Una migrazione controllata combina inventario, build immutabile, test dei journey, strategia dei dati, cutover osservabile e rollback provato. Se vuoi trasformare questi elementi in un runbook con responsabilità e gate misurabili, contatta AE Digital Agency per valutare architettura e piano di esecuzione.