ordine di generazione in CruiseControl.NET con dipendenze di progetto

Question

Nel nostro negozio di sviluppo software .NET, abbiamo CruiseControl.NET istituito per costruire 28 progetti, alcuni dei quali sono interdipendenti. Ogni progetto rappresenta approssimativamente un progetto di Visual Studio o una libreria Flex abbinata a test di unità. Quello che mi infastidisce è che non ho trovato un buon modo per garantire che i progetti vengano creati in un ordine che rappresenta le dipendenze.

Ecco quello che sto facendo:

1. Tutto è nella stessa coda di costruzione. L'ho fatto in modo che le build vengano eseguite in sequenza e così posso evitare di dover utilizzare più directory di lavoro.
2. Ho impostato le priorità delle code sui progetti, che ho pensato avrebbero influenzato il loro ordine di costruzione. Ma dopo aver letto la documentazione con più attenzione, ho scoperto che controlla solo la priorità quando ci sono più richieste di compilazione in una coda.
3. Oltre a utilizzare intervallo di trigger per dare il via una build, io uso progetto innesca in modo che quando le dipendenze costruire con successo, a loro carico anche costruire.

In un certo senso, questa configurazione funziona. Il problema principale è se qualcuno commette modifiche al codice sia nel progetto A che nel progetto B, in cui il progetto B dipende dal progetto A. Talvolta, il progetto B verrà creato prima del progetto A. Poiché il progetto A non è ancora stato creato, questo può a volte causano la rottura del progetto B. Questo è temporaneo, poiché il trigger a intervalli fa in modo che il progetto A si sviluppi in un secondo momento, e la sua build di successo attiva il progetto B per ricostruire e correggere. Quello che voglio evitare è la costruzione del progetto B prima del progetto A, in modo che la rottura intermedia non possa accadere.

Quali pratiche si usa per gestire correttamente le interdipendenze sul server CruiseControl.NET? A questo punto, non sono disposto a passare a un pacchetto di integrazione continua non libero come TeamCity.

Answer 1

Non inserire la dipendenza nelle impostazioni del progetto CC.NET. È necessario controllare l'ordine di costruzione del progetto tramite lo script NAnt. Non devi costruire su un livello di soluzione, puoi costruire a livello di singolo progetto.

<target name="Project1" depends="Projects2" description="Builds project 1"> 
    <msbuild> 
     <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> 
     <workingDirectory>C:\dev\ccnet</workingDirectory> 
     <projectFile>CCNet.sln</projectFile> 
     <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs> 
     <targets>Build;Test</targets> 
     <timeout>900</timeout> 
     <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
    </msbuild> 
</target> 

<target name="Project2" depends="Projects3" description="Builds project 2"> 
    <msbuild> 
     <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> 
     <workingDirectory>C:\dev\ccnet</workingDirectory> 
     <projectFile>CCNet.sln</projectFile> 
     <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs> 
     <targets>Build;Test</targets> 
     <timeout>900</timeout> 
     <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
    </msbuild> 
</target> 

<target name="Project3" description="Builds Project 3"> 
    <msbuild> 
      <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> 
      <workingDirectory>C:\dev\ccnet</workingDirectory> 
      <projectFile>CCNet.sln</projectFile> 
      <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs> 
      <targets>Build;Test</targets> 
      <timeout>900</timeout> 
      <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
    </msbuild> 
</target> 

È possibile eseguire il test di unità a livello di singolo progetto, in modo da non dovrebbe essere necessario per una stampa duplicate su più progetti.

Answer 2

vi suggerisco di non attraversare il concetto di un progetto CruiseControl con un progetto di Visual Studio! Generalmente ho creato un progetto CC che comprende un corpo di lavoro. Per me questo significa che il progetto CC eseguirà uno script NAnt. Lo script NAnt ha un controllo molto dettagliato su cosa faccio e quando. Ciò significa che posso costruire la mia soluzione (che sa quale progetto costruire per primo!), Eseguire i miei test unitari, resettare un database, distribuire del codice, inviare alcune email, fare qualche analisi del codice (NDepend e NCover sono fantastici!), ecc. Ciò significa che ho un progetto in CCTray e questo rende le cose più fedeli a ciò che sono in realtà. Quindi posso creare un nuovo progetto in CC per controllare quando spingo da DEV a STAGING e da STAGING a PROD in modo da poter "spingere" questo task. Ma questo produce solo 3 progetti in cruise control ed è notevolmente più user friendly.

Answer 3

Anche se avete già accettato una risposta, vorrei suggerire qualcosa di diverso: non dovrebbe avere dipendenze dirette tra i due progetti. Con "diretto" intendo che ogni volta che binari nel progetto A cambiano, questo non dovrebbe significare che li usi automaticamente per costruire il progetto B.

Il processo di aggiornamento di questi riferimenti dovrebbe essere controllato (da te), altrimenti inevitabilmente finirai con un sacco di build rotti per il progetto B.

Tendo a tenere tutti i binari esterni sotto la directory lib (e sottodirectory) sotto il controllo del codice sorgente e aggiornarli solo quando decido di farlo. E per "esterno" intendo sia le librerie di terze parti che quelle di altri progetti nella mia azienda (esempio: http://code.google.com/p/projectpilot/source/browse/#svn/trunk/lib)