"prevenire è meglio che curare" è una delle frasi più famose riguardante la precauzione in termini di salute. Essa è valida anche per quello che riguarda il modo in cui ci si approccia alla produzione di codice.

La qualità del codice scritto, infatti, è importante, proprio per la salute dei nostri ambienti. Non si tratta solo di stile, anche se quella parte non dovrebbe essere trascurata, bensì anche di contenuti. Quando scriviamo SQL senza intermediari (senza ORM o librerie varie, ad esempio) e aggiungiamo file, script o codice compilato in stored procedure/funzioni, dovremmo sempre capire se tale codice rispetti:
- le regole aziendali, in termini di stile e di vincoli,
- le sintassi e le best practices riconosciute dalla community e/o dal prodotto
- la non regressione e la non perdita di dati su ambiente di produzione

In poche parole, dobbiamo essere sicuri di quello di cui andiamo a fare deploy. Negli ultimi tempi ho investito i nostri sforzi (team di DBA in azienda) nelle pratiche di prevenzione di questo tipo.
Condividerò con voi, in questa sessione:
- i punti su cui agire e perché
- lo strumento utilizzato (quello che abbiamo scelto tra varie possibilità)
- la necessità di attività personalizzate
- il rapporto costi/benefici
- il contesto DevOps di tutta la questione