5

Quello che sto cercando di fare è avere CI e una build automatizzata per tutte le mie filiali in un repository. Mi piacerebbe che ogni build di queste applicazioni web avesse il proprio progetto e fosse collocata come directory virtuale (o equivalente) su un sito di filiali. Sarebbe fantastico poter creare una nuova filiale e avviare automaticamente l'integrazione e il processo di creazione continua. L'aggiunta di una nuova directory virtuale in IIS non è un grosso problema, mi va bene farlo se il resto si mette semplicemente in posizione.Creazione automatica di filiali con SVN

Per esempio:

http://branch.domain.com/branch101/

http://branch.domain.com/otherBranchName/

Attualmente, sto usando SVN, Nant e CruiseControl.Net, ma sono aperto un altro server di integrazione continua o costruire scripting se la situazione lo richiede.

+0

Non capisco la domanda: stai cercando un nuovo progetto CC.net da creare automaticamente quando si dirama il codice?- o solo il modo migliore per configurare ccnet per costruire più filiali - si parla di directory virtuale - stiamo parlando di app web? – Richard

+0

Sì ad entrambi, ho modificato la domanda per essere più chiara (si spera!) –

risposta

1

Non capisco la vera domanda. Ad ogni modo ti suggerisco Hudson (http://hudson-ci.org/).

È facile da usare. È facile da configurare con i file XML. Ha un'API remota.

+0

+1 per Hudson. (Attenzione però: se costruisci su piattaforme multiple, Hudson non procederà alla costruzione successiva fino a quando non tutte le piattaforme saranno finite, il che significa che la macchina di test/generazione più lenta rallenta tutti gli altri. quando abbiamo provato.) – sbi

+0

Sei sicuro? Per piattaforma intendi un lavoro hudson? Perché puoi impostare più di un "Build Executor". Non lo uso mai, ma Hudson supporta la modalità "master/slave" per distribuire build. –

+0

@ungarida: Hudson è stato uno degli strumenti CI più promettenti che abbiamo valutato e ISTR che abbiamo abbandonato a causa di questo. Ma non ricordo nemmeno quali siano i "lavori" per Hudson, quindi immagino significhi, no, non ne sono sicuro. – sbi

1

Non penso a quello che vuoi per quanto riguarda la configurazione automatica dei tuoi progetti di integrazione continua basati sulla ramificazione. Tuttavia, se i tuoi rami sono abbastanza standard e non cambiano drasticamente, sarebbe piuttosto facile scrivere uno script di PowerShell (o qualsiasi altra lingua di scripting che preferisci) per impostare i nuovi progetti.

Mi chiedo se sia necessario, quando si diramano in CC.NET, ci vuole meno di un minuto per copiare i progetti dei tronchi e cercare e sostituire i campi necessari. L'unica volta che ci imbattiamo in problemi è quando abbiamo script personalizzati utilizzati durante la compilazione, se esistono anche quelli che devono essere modificati, ma ciò avverrà con qualsiasi sistema di integrazione continua.

3

Questo può essere fatto, ma molto dipende dai tuoi script di compilazione. Se si dice a cc.net di monitorare la cartella svn di livello superiore, ad esempio si ha il monitor di progetto:

http://myserver.com/svn/project anziché http://myserver.com/svn/project/trunk. Se si vedono cambiamenti in http://myserver.com/svn/project, verrà avviata una build.

Ora, è compito del tuo script di build determinare quale origine non è aggiornata o se c'è un nuovo ramo da costruire. Lo script di build creerebbe un nuovo VDir per ogni nuovo ramo.

Un'altra opzione potrebbe essere quella di avere un progetto cc.net progettato per fare nient'altro che aggiungere nuovi progetti al cc.net. (Chiamalo progetto BranchBuilder) Vorrei sfruttare il pre-processore in cc.net e disporre di un file .config di livello superiore che includeva solo il progetto per trunk e ogni ramo. Il progetto del costruttore di rami monitorerebbe il percorso di root su svn. Se vedesse delle modifiche, guarderebbe se ci fossero nuovi rami dall'ultima build. Se ce n'era una, poteva creare un file ccnet-branchname.config per quel ramo, creare il vdir e quindi aggiornare il file root di ccnet.config con un ulteriore include.

Dopo che ccnet config è stato aggiornato, cc.net riconoscerà che il file di configurazione è stato modificato e ricarica la configurazione aggiungendo il nuovo progetto di diramazione. Quel progetto di filiale inizierà a funzionare e costruirà la tua nuova filiale.

+0

Questa è, a mio parere, una pessima idea. Penso che tu stia automatizzando troppo. Quanto potrebbe essere difficile aggiungere un blocco al file ccnet.config rispetto a questa soluzione? –

+1

Lo facciamo anche a mano. Solo perché puoi fare una cosa, non significa che dovresti. Tuttavia, eseguirà la build automatizzata per la funzionalità di ramo richiesta dall'OP. Detto questo, non so quanto spesso si ramificano. Potrebbe essere decine di volte al giorno. I computer sono progettati per svolgere compiti ripetitivi, giusto? – PilotBob

+1

@JoshKodroff Penso che sia una questione di opinione, la ramificazione "costosa" è una ragione per cui un sacco di sviluppo si riunisce in una sola riga (aumento del rischio). Il fatto di dover accedere a una macchina per riconfigurare il processo di compilazione sembra aggiungere costi significativi alla ramificazione. –

Problemi correlati