L'istruzione che ha cancellato le ventisei lingue sbagliate

Ho detto all’automazione del mio sito di ridurre il blog a quattro lingue. Due giorni dopo ho scoperto che aveva cancellato silenziosamente altre ventisei lingue anche dalla homepage, e non se n’era accorto nessuno: né io, né un solo visitatore.

TL;DR

• Un’istruzione pensata per la sezione blog è stata applicata invece a tutto il sito.
• 26 lingue su 30 sono sparite dalla homepage, dalla pagina CV e da ogni stringa di navigazione.
• Niente si è rotto, nessun errore 404, quindi per due giorni non se n’è accorto nessuno.
• La soluzione è arrivata dalla cronologia di git, non dal ricordo di come il sito appariva prima.
• La vera lezione: prima di far partire una modifica automatizzata, bisogna nominare esattamente i file che tocca, e leggere quella lista prima che venga cancellato qualcosa.

Perché volevo meno lingue, in primo luogo

Il mio sito era arrivato a trenta lingue nel giro di pochi mesi: homepage, pagina CV e un blog che aggiorno quasi ogni due o tre giorni. Ne avevo già parlato, di quanto sia rischioso: la traduzione automatica è abbastanza fluida da sembrare corretta e abbastanza sbagliata da metterti in imbarazzo, in una lingua che tu personalmente non puoi controllare. Homepage e CV cambiano poco, quindi quel rischio potevo permettermelo lì. Il blog era un’altra storia. Escono nuovi articoli di frequente, e onestamente non posso garantire la qualità della traduzione di un pezzo appena pubblicato in estone, lo stesso giorno in cui esce.

Così ho deciso di ridurre le lingue in cui traduco il blog alle quattro che riesco davvero a controllare io stesso: inglese, russo, tedesco, ceco. Tutte le altre restano fuori dal blog finché non trovo un modo migliore per verificarle. Questa parte del piano era solida. Il problema è stato come l’ho chiesta.

Una frase sola, il perimetro sbagliato

Ho dato un’unica istruzione: limita il blog a quattro lingue. Breve, precisa, o almeno così credevo. Quello che è stato eseguito davvero ha toccato tre cose diverse insieme. Ha ridotto correttamente le cartelle di contenuto del blog alle quattro lingue che volevo. Ma ha anche riscritto l’elenco master delle lingue del sito, il file di configurazione che dice quali lingue esistono in assoluto, e ha cancellato i contenuti della homepage e le stringhe di navigazione per le altre ventisei.

Il problema è che «il blog» e «l’elenco delle lingue di tutto il sito» vivono nello stesso file di configurazione. In quel file niente distingue quali lingue supporta il blog da quali supporta il sito. Togli una lingua da quell’elenco e ogni sezione che la legge, homepage compresa, la perde in un colpo solo. La mia istruzione indicava una sezione. La modifica che è stata eseguita aveva come perimetro l’intero sito.

Ecco la parte che l’ha resa pericolosa, e non solo sbagliata: niente si è rotto in modo rumoroso. Nessun errore, nessun 404, nessun fallimento della build. Il sito ha semplicemente smesso, in silenzio, di generare le pagine homepage e CV per ventisei lingue, e il selettore di lingua ha smesso di proporle. Un visitatore che prima leggeva il sito in portoghese si ritrovava, senza alcun avviso, in inglese. Sparito-perché-cancellato ha esattamente lo stesso aspetto di mai-esistito, e nessuno dei due genera un errore.

Sono passati due giorni prima che me ne accorgessi, e solo per caso, a metà di una correzione che non c’entrava nulla, quando un link “Blog” nella navigazione puntava a qualcosa di strano per una delle lingue che credevo ancora attiva. Quel singolo link rotto è stato l’unico filo visibile che riportava all’intero problema.

Cosa ha mostrato davvero il diff

L’errore vero, qui, non è lo sbaglio di perimetro in sé. È che non ho mai controllato l’elenco dei file che la modifica avrebbe effettivamente toccato prima di farla partire. Ho letto una descrizione di una riga su cosa avrebbe dovuto fare e ho dato per scontato che descrivesse anche cosa avrebbe fatto davvero. Non era così.

Per sistemarlo sono partito da una domanda: cosa è cambiato, e dove. Ho confrontato il sito live con l’ultimo commit precedente all’istruzione “riduci il blog”, e la risposta è arrivata immediata e inequivocabile: la configurazione master delle lingue, la cartella di contenuto della homepage e ventisei file di stringhe per lingua, nessuno dei quali vicino alla cartella del blog. Git aveva tutti quei file esattamente come erano prima. Non era andato perso nulla, era stato solo sovrascritto in produzione.

Ho ripristinato homepage, CV e stringhe di navigazione per tutte e trenta le lingue da quella cronologia, e ho lasciato la cartella del blog esattamente ridotta come la volevo: quattro lingue, di proposito. È rimasto un capo sciolto. Il link di navigazione “Blog”, per una lingua ripristinata, puntava a un’edizione del blog in quella lingua che non esiste più. Duplicare quattro articoli in altre ventisei lingue solo per riempire quel link non ne valeva la pena, quindi ho impostato il template perché reindirizzasse al blog in inglese, e l’ho lasciato così.

Cosa controllerei diversamente la prossima volta

Prima di lasciare che una modifica automatizzata tocchi un sito live e multi-sezione, adesso mi faccio ad alta voce una domanda in più: quali sono esattamente i file che questa cosa toccherà, non la funzionalità che dovrebbe sistemare. Se la risposta è vaga, è il segnale per fermarsi e controllare, non per eseguirla e vedere cosa succede. E prima che venga cancellato qualcosa, voglio avere davanti l’elenco reale dei file, non un riassunto di una riga su cosa l’istruzione avrebbe dovuto significare. Una parola di perimetro in un’istruzione, «il blog», «questo team», «solo il frontend», non coincide automaticamente con il perimetro della modifica che quell’istruzione innesca, e i due combaciano solo se qualcuno ha davvero verificato che sia così: che è esattamente la domanda che rigiro a voi. Qual è l’istruzione più piccola e apparentemente più sicura che avete dato di recente, e che non è mai stata verificata rispetto a cosa ha toccato davvero?