Edificio Separato da Deployment con Hudson

Question

Abbiamo iniziato a utilizzare Hudson, e il flusso di lavoro attuale è:

cassa a livello locale> code> test eseguiti> aggiornamento> test eseguiti> impegnano

Piuttosto che polling, Hudson siede semplicemente lì finché non istanziamo una build. E poi:

cassa a livello locale> sceneggiatura Phing eseguire

Lo script Phing quindi:

svn export ultima revisione> test eseguiti (in caso di successo)> genera report ecc ..> comprime l'esportazione> SCP alla produzione server> .. fare magie per rendere il sito live ...

Che tutto funzioni bene e dandy, tuttavia non ci dà davvero la possibilità di alcun tipo di "controllo di qualità" del QA e ogni build crea il repo head revisione. Idealmente vorremmo Hudson effettuare il polling o l'uso post commettere ganci costruire ogni commit e:

cassa a livello locale> eseguire compito Phing per eseguire i test e in caso di successo, genera report ecc ..

quindi in grado di istanziare manualmente un distribuzione automatizzata (tramite attività Phing) a "staging QA o produzione da ogni build specifica.Tutti i commit verranno distribuiti al QA

Questo flusso di lavoro è possibile anche con Hudson, o avremo bisogno di per eseguire manualmente le attività di distribuzione di Phing dopo.

Answer 1

Ho finito per fare qualcosa di simile al suggerimento di Peter Schuetze. Ho usato solo l'unico lavoro comunque. Io uso 3 parametri di costruzione, deploy (bool), ambiente (scelta) e revisione (testo). Ho quindi modificato i miei script Phing per fare solo distribuzioni se il parametro deploy è vero, nel qual caso distribuirà la revisione specificata nell'ambiente specificato. Per impostazione predefinita, la distribuzione è falsa, la revisione è fondamentale e l'ambiente è in fase di gestione temporanea. Ora, quando Hudson esegue il polling di svn, vede che il parametro deploy è falso e ignora le attività di distribuzione.

Answer 2

Non sono completamente chiaro su cosa vuoi ottenere, ma mi chiedo se stai usando il plugin Phing? Forse quello che vuoi non è attualmente possibile attraverso Hudson e potrebbe richiedere di cambiare il tuo processo di sviluppo per renderlo possibile.

Answer 3

Ho separato il processo di build/test (job1) e il lavoro di distribuzione (job2). Job1 gira su trunk dopo ogni commit (i sondaggi di Hudson, ma anche il hook di commit post funzionerebbe). Archivia anche gli artefatti di costruzione. Job2 verrà avviato manualmente. Ottiene il numero build da job1 come parametro di build (mi piace il parametro run) e scarica le risorse da job1, nel proprio spazio di lavoro. Li gestisce la distribuzione. Nel tuo caso aggiungerei un altro parametro (parametro choice) per determinare a quale ambiente vuoi distribuire.

Con il plug-in del setter di descrizione, è possibile stampare il numero di esecuzione da job1 e dall'ambiente e si può facilmente vedere nella cronologia del lavoro quale build è stata distribuita quando a quale ambiente.