Qualsiasi best practice per scrivere script di build in Ant o MSBuild

Question

Sto provando ad automatizzare il processo di compilazione dei miei progetti (sia java che .net) usando Ant e MSBuild. Ho letto su di loro e so come scrivere script di build in Ant e MSBuild. Ma mi chiedo, ci sono linee guida o best practice per scrivere script di compilazione in generale? Ecco due che ho trovato, ma mi piacerebbe sentire di più da altri sviluppatori.

• Nello scrivere uno script di build, fare affidamento solo sugli elementi che si trovano nella il controllo del codice sorgente e sono disponibili nella cartella di lavoro, mentre controllando le fonti. NON scrivere script di build che sono dipendenti da elementi che non sono conservati sul controllo del codice sorgente.
• Se un progetto contiene un insieme di sottosistemi e ciascun sottosistema ha propri script di compilazione, il file di build del progetto deve semplicemente chiamare gli script di compilazione dei sottosistemi. Inoltre, questi file devono importare un file di configurazione comune che contiene gli obiettivi, quali la compilazione, prova, pacchetto ecc

ho visto this post pure, ma è dettagliato sul modo di attività di scrittura. Ho bisogno di più linee guida di alto livello, come menzionato sopra.

Qui ci sono le linee guida che ho raccolto da risposte:

1. Esegui ogni costruire in un ambiente pulito. Significa che ogni script di costruzione ha bisogno di un target clean.
2. Generalmente gli script di build devono includere gli obiettivi compile, package e test.
3. Se un prodotto ha linee di sviluppo diverse (ad es. Dev, release), , tutti dovrebbero avere lo stesso script di compilazione. Ma i diversi parametri devono essere passati a questi script.
4. Le build eseguite sulle linee di sviluppo di solito contengono la compilazione, la confezione , la distribuzione e l'installazione dei passaggi. Tuttavia, le versioni sulla release includono ulteriori passaggi, ad esempio la codifica del prodotto e generando i log delle modifiche/note sulla versione.
5. Gli script di compilazione devono essere mantenuti anche sul controllo del codice sorgente.
6. cercare di mantenere tutte le informazioni in costruire script di build, non su server di integrazione continua (bambù, TeamCity, etc.)
7. Se la build usa un parametro che può cambiare in futuro (ad esempio, l'indirizzo di rete per copiare il creare risultati), non digitalizzarlo nello script di build. invece, usa i parametri di build per controllarlo più facilmente .

Answer 1

Se stai costruendo applicazioni VisualStudio, è meglio usare msbuild su Ant. Il comando msbuild eseguirà la generazione utilizzando il file di soluzione creato dagli sviluppatori e in pratica emulerà la stessa build eseguita.

Se vuoi veramente automatizzare tutto, dai uno sguardo allo Jenkins. Ha un plugin che può eseguire msbuild e attiverà automaticamente una build ogni volta che qualcuno apporta una modifica. Io uso una combinazione per msbuild e Ant con Jenkins. Faccio la build usando msbuild, quindi uso Ant per raccogliere e comprimere tutti i miei artefatti. Quindi, le persone possono scaricare gli artefatti creati direttamente da Jenkins.

Ora, con le tue applicazioni Java, dovrai usare Ant. Io uso le seguenti linee guida

• Ogni script di costruzione ha bisogno di un target clean. Questo target rimuove tutti i file che sono stati aggiunti durante il processo di compilazione, restituendo la directory di lavoro a uno stato prima dello clean.
• seguo quello che Maven fa quando si utilizzano nomi di destinazione, così i miei obiettivi sono nomi cose come pulita, compilare, e pacchetto.
• Inoltre, seguendo le linee guida Maven, tutti i file creati vengono inseriti nella directory target. In questo modo, il mio comando clean può semplicemente fare un <delete dir="${target.dir}/> e ripulire tutto in modo bello e brillante.
• Se si dispone di un sottoprogetto, ciascun sottoprogetto ha il proprio file build.xml. Il mio file master build.xml chiama semplicemente tutti i file build.xml dei sottoprogetti.
• Utilizzare Ivy. È facile da configurare e facile da usare.Non hai più il problema di archiviare i file jar nel tuo repository di origine o di perdere le versioni di quali file jar dipendono.
• Heck, se puoi, usa Maven e avanza con esso. Sfortunatamente, la maggior parte dei progetti più vecchi sono più difficili da mavenize di quanto valga la pena.
• Crea le tue build utilizzando Jenkins come server di generazione continua. E tutte le build che escono dal dipartimento (UAT, QA e build di protezione) devono essere una build di Jenkins.
• Incoraggia i tuoi sviluppatori a scrivere test unitari. Infatti, Jenkins può eseguire test unitari e mostrare i loro risultati sulla sua pagina di build.
• Utilizzare altre funzioni come stile di controllo, PMD, CPD, Findbug e altri prodotti di verifica del codice. E, naturalmente, Jenkins può eseguire ognuno di questi e visualizzare grafici graziosi che possono essere utilizzati per mostrare al tuo manager quanto stavi lavorando.

Answer 2

In MSBuild, gli obiettivi devono specificare input e output, laddove possibile (per abilitare il calcolo delle dipendenze). Se necessario, utilizzare l'attributo Returns per specificare un target che restituisce elementi diversi da quelli utilizzati per il calcolo delle dipendenze.

Gli elementi di input e output per un dato target devono essere generati utilizzando entrambe le trasformazioni oggetto (per trasformazioni semplici basate sul percorso) o un altro target (per trasformazioni più sofisticate).

Per MSBuild pre-4.x, per gli obiettivi che si definiscono in una.file di obiettivi, è consigliabile utilizzare il seguente modello per consentire ai consumatori di iniettare i propri obiettivi prima di quelli che si sta definendo:

<PropertyGroup> 
    <MyTargetDependsOn> 
    Target1; 
    Target2; 
    SomeOtherTarget 
    </MyTargetDependsOn> 
</PropertyGroup> 
<Target 
    Name="MyTarget" 
    DependsOnTargets="$(MyTargetDependsOn)"> 

</Target> 

Questo consente ai consumatori di iniettare i propri obiettivi prima che la destinazione specificata semplicemente modificando il valore del MyTargetsDependsOn proprietà:

<PropertyGroup> 
    <MyTargetDependsOn> 
    $(MyTargetDependsOn); 
    YetAnotherTarget 
    </MyTargetDependsOn> 
</PropertyGroup> 
<Target 
    Name="YetAnotherTarget"> 

</Target> 

In MSBuild 4.x, si può semplicemente utilizzare i BeforeTargets e gli attributi AfterTargets.

Answer 3

Solo un commento sul secondo punto si cui sopra:

Se un progetto contiene un insieme di sottosistemi e ogni sotto-sistema ha le script di generazione, il file di configurazione del progetto dovrei semplicemente chiamare gli script di costruzione dei sottosistemi .

Ogni sottosistema deve avere il proprio file di build ma quel file dovrebbe importare un file di build comune. Il file di configurazione comune conterrebbe obiettivi quali la compilazione, prova, pacchetto ecc

http://ant.apache.org/manual/Tasks/import.html

Il sottosistema di costruire file sono quindi molto semplici, non contengono la duplicazione e contengono solo le informazioni che è specifico per tale sottosistema (ad esempio compile.classpath).