ho cambiato ufficio. prima stavo in stanza col capufficio, persona molto in gamba, al quale chiedevo le cose che non capivo o non sapevo ecc.
ora sono in un’altra stanza, e i colleghi chiedono a me come fare…
il collega L. si sta arrovellando con una pagina jsp che non gli funziona:
L: ma come!!! faccio il submit della form e invece di andare nella pagina nuova finisce nella pagina vecchia!!!
io: guarda che quella pagina è stateless, non si ricorda da dove è venuta e chi l’ha generata. è html. non può sapere che prima esisteva la pagina vecchia. se hai scritto correttamente il form andrà dove tu vuoi che vada!
L: ma no, vedi, in debug mi entra nel controller, fa tutto il giro, non può essere…
io: guarda che no. hai cannato di scrivere la pagina oppure non l’hai aggiornata sul server
— passano due minuti. una bestemmia. sua.
L: noooo porc..@€%£@%§… stavo lavorando con i dati di produzione… stavo facendo le modifiche sul database di produzione… per forza che la pagina restava quella vecchia… è l’apocalisse…
per fortuna le modifiche che stava facendo erano non irreversibili anche sui dati di produzione. altrimenti avrebbe dovuto recuperare chissà come il backup di stanotte e integrare tutto il lavoro fatto da centinaia di filiali in tutto il mondo oggi…
insomma, imparate dalle “best practices”: usate tre ambienti di lavoro separati: sviluppo per lavorarci e massacrare tutto, test per provare con dati buoni che tutto giri correttamente, produzione con solo le cose funzionanti e i dati veri che servono al cliente.
fate in modo che passare dall’uno all’altro sia chiaro per voi. per esempio usate un colore diverso per le pagine web, in modo che sia visibile in modo chiaro quale è l’ambiente.
per ultima cosa vi ricordo le prime due regole del buon sysadmin, che vanno bene anche per un buon programmatore:
- se funziona non toccare niente
- fai sempre il backup. ma controlla anche che sia funzionante
2 risposte su “sviluppo, produzione, test”
Sulle due regole una nota
“se funziona non toccare niente”
il concetto va visto sotto due aspetti
1) sono in debug, devo cercare l’errore.
giusto concentrarsi su ciò che presumibilmente non funziona.
Se metto mano a ciò che funziona, il raggio della mia azione correttiva si allargherà e troverò l’errore con più difficoltÃ
2) non sono in debug, sto facendo sviluppo
in questi casi toccare è lecito, anche stravolgere, anche rifare tutto se necessario. L’importante è avere poi dei test [possibilmente automatici per controllare che tutto quello che funzionava prima funzioni ancora.
“fai sempre il backup. ma controlla anche che sia funzionante”
1) Il backup va sempre fatto, “automatizza” in modo che a certe ore del giorno venga portato a termine senza che tu debba ricordare di doverlo fare [ad esempio mentre sei in pausa pranzo]. Ma fai il backup “manuale” anche prima di operazioni importanti.
2) Fai il backup su supporti diversi, ad esempio server e chiavetta.
3) Integra il backup con un sistema di versioning.
4) Firma la copia di backup.