Newsgroup: it.comp.www.php
Titolo: è un freddo sabato sera berlinese

qiundi non avendo troppo da fare mi diletto nella riorganizzazione e
pianificazione del lavoro :)
tra le varie cose mi chiedevo quali sono i migliori metodi di
deploy/undeploy delle applicazioni. Mi interessa soprattutto la parte
dell'undeploy, cioè quando si verifica che il deploy di una cosa che in
testing andava bene improvvisamente in prod risula buggata o comunque non
funzionante. a quel punto si rende necessario ritornare allo stato
precedente "immediatamente" per permettere al (diciamo) sito di continuare
a funzionare.
Dalla mia cerco di automatizzare il piu' possibile queste fasi, certo
che a volte non è così semplice, soprattutto quando il deploy prevede
anche il cambiamento della struttura di qualche tabella del DB.
Questo il mio metodo:
supponiamo che il progetto X abbia file nelle directory (partendo dalla
DocumentRoot) /mioframework/application/[controller model views] più la
dir /css/applicazione /js/applicazione /img/applicazione (*)
e che la nuova versione debba alterare un paio di tabelle
aggiungendo,togliendo o modificando colonne
per il DEPLOY:
sul server di produzione:
serverino subversion
script "applicazione.sh" che tira giu' i file implicati e li mette nella
giusta posizione
script sql che altera le tabelle 
da quello di sviluppo:
commit di tutti i file su svn
fino a qua di solito va tutto bene
ma quando si rende necessario l'undeploy, cosa fare esattamente?
il mio metodo è di backuppare brutalente tutto , files che implicano il
progetto, e database, ed all'occorrenza spianare la nuova versione sia del
db che dei sorgenti e rimettere tutto a manina
c'è qualche strumento piu' indicato a effettuare l'operazione senza
dovermi sempre affidare alla bontà della mia memoria? (che spesso va a
farsi un giro :))
seconda domanda, dal blog di un mio amico che a fatto
l'università con me (e che sviluppa rails) leggo di questa simpatica
applicazione atta a popolare il db per la fase di testing:
http://www.ateapick.com/blog/popolare-il-database-di-sviluppo-in-un-progetto-rails
per quanto mi riguarda la popolazione del db è un altro scoglio de devo
bypassare manualmente, quali strumenti simili ci sono in php?
 
sì, è decisamente un freddo sabato berlinese :)
(*) domanda: organizzate le directory in modo diverso? 
ad esempio /applicazione/[css js img] o altro?

 ad esempio /applicazione/[css js img] o altro?
sul server di produzione di solito tengo solo lo stretto necessario
(quindi niente controllo di versione, paranoie sulla sicurezza). Per
il deploy di solito faccio un Makefile (troppi anni di C - addirittura
a volte scrivo make sul terminale dopo aver fatto una modifica sui
sorgenti, anche se non serve a nulla) che mi compatta in un tar.gz i
files con la struttura finale. Quando si decide di fare l'update metto
offline il server (o, moolto raramente, redirigo su una pagina work-in-
progress) e scompatto. Le modifiche SQL se non sono critiche tendo a
farle su tutti i server contemporaneamente, altrimenti si vede che
succede volta per volta :) fortunatamente non capita spesso.
Come hai capito tendo, sul server di produzione, a fare TUTTO
manualmente, visto che ogni stupidaggine diventa un'operazione
delicata. Quando un'operazione manuale sarebbe troppo lunga o troppo
ripetitiva scrivo un script bash, ma sempre ad-hoc e provandolo prima
sul server di sviluppo.
Non mi è mai capitato di fare "undeploy" visto che praticamente mai
faccio modifiche solo sul server di produzione ;)
Per "popolare" il db non credo esista alcuno strumento automatico che
funzioni. L'unica cosa che mi capita a volte di fare sono degli
"snapshot" di dati del db che riuso però per fare dei test su varie
versioni del php man mano che vado avanti col lavoro (di solito lo
faccio il venerdì sera, quando non ho la forza di scrivere codice
inutile e mi serve una buona scusa per il mio capo/committente :-) )
Per il resto pensa che c'è anche chi sta al freddo, ma non a
Berlino :) Saluti da un paese sperduto nei boschi, in visita alla
famiglia :(
Ciao!