Perché dovrei usare MSBuild invece dei file di Visual Studio Solution?

Il primo punto di fatto è che il file di soluzione diventa magicamente un file MSBuild quando MSBuild lo esegue, il che è ciò che accade quando costruisci la soluzione in Visual Studio. Inoltre, tutti i file di progetto sono solo file msbuild gestiti da Visual Studio. In effetti, i file di progetto gestiscono la maggior parte del vero lavoro sporco qui, non importa se stai costruendo da soluzioni o costruisci da uno script msbuild personalizzato.

Usiamo TeamCity anche per creare e pubblicare applicazioni e in genere finiremo con script msbuild personalizzati per la maggior parte dei progetti. Il ruolo di questi script - che non è molto semplice con un file di soluzione - è il confezionamento del progetto per l'implementazione o la distribuzione. In genere questi script gestiscono alcuni aspetti operativi più importanti delle cose, ad esempio la creazione di un progetto Web in una determinata cartella o la copia nelle configurazioni correnti rispetto alle configurazioni di sviluppo. Il sollevamento pesante tende ad essere gestito nei file di progetto stessi - lo script di costruzione fa semplicemente riferimento a quelli, non proviamo a ricreare quella ruota. Nel complesso funziona benissimo e non è un codice molto duplicato. In genere, una volta ottenuti gli script di compilazione, raramente dobbiamo toccarli fino a quando non ci sono enormi cambiamenti in un progetto che richiede la modifica massiva della build.

Il makefile per msbuild è il file .sln (o il file vcproj).

Una tipica riga di comando di msbuild sarebbe qualcosa come:

msbuild /p:Configuration=Release BigProject.sln

Il punto di utilizzo di msbuild è che puoi creare script e automatizzare il processo di compilazione. Che tu ne sia a conoscenza o meno, TeamCity ha sempre utilizzato msbuild.

Lascia che ti offra la mia opinione su questa domanda.

Sebbene tu possa semplicemente usare il tuo file .SLN come "processo di compilazione", il file stesso non costituisce realmente un processo di creazione. Il file della soluzione è in realtà solo una parte di Visual Studio e viene utilizzato per lo sviluppo. Ma Visual Studio è solo una parte del processo di generazione e rilascio. Non puoi fare affidamento su Soluzioni per gestire la tua build, e le soluzioni certamente non offrono una situazione di compilazione scalabile.

L'intero scopo di stabilire un processo di costruzione è creare build affidabili. Vale a dire, il processo di compilazione è così affidabile che, indipendentemente dalla configurazione di build, si otterrà un output di build prevedibile. Ogni volta, ogni macchina. Il risultato di una build prevedibile e affidabile è che il processo di test, distribuzione e rilascio può essere altamente automatizzato, riducendo ulteriormente il rischio di errore umano.

Stabilire un processo di costruzione richiede un investimento, ma in alcuni casi è richiesto l'investimento. Ecco alcuni fattori che favoriscono un processo di msbuild:

• Il tuo prodotto ha più team (interfunzionali o meno) che stanno lavorando nello stesso progetto di squadra
• La tua organizzazione ha un solo progetto di squadra (dovrebbe essere il caso del 99% dei negozi tradizionali, anche quelli con oltre 200 sviluppatori)
• Hai più di 20 progetti che devono essere creati, alcuni dei quali hanno dipendenze da altri e sono gestiti da team diversi
• Il tuo prodotto include più tecnologie .NET (C #, C ++, VB, F #, ASP.NET, ecc.) o anche tecnologie non.NET (Grunt, node, npm, Java, ecc.)
• Il tuo prodotto ha dipendenze pesanti o è costruito su una piattaforma pesante. SharePoint, ad esempio

Lasciatemi fare un esempio per espandere il mio ultimo punto. La mia attuale azienda sviluppa SharePoint. Lo sviluppo di SharePoint al minimo richiede l'installazione di SharePoint per eseguire build su progetti SharePoint. Parlando in termini di un server di build leggero, è del tutto impossibile richiedere che il server di build abbia installato SharePoint. SharePoint non è solo una bestia con requisiti elevati, ma potrebbe avere serie implicazioni sulle prestazioni in una build, e le build dovrebbero essere il più veloci e snelle possibili. L'uso di MSBuild mi consente di eliminare questo requisito di installazione sul server di build. In effetti, il nostro server di build non ha requisiti di installazione diversi dal framework .NET (richiesto da MSBuild) e dal nodo.

Come riferimento, ti consiglio di consultare questo libro di Sayed Ibrahim Hashimi: link

Questa è esattamente la domanda che mi sono posta qualche mese fa! Avevamo tutto ben organizzato:

• Il file della soluzione si trova bene nella directory principale dei repository
• Costruisci passaggi configurati in Teamcity, come
  • Ripristina i pacchetti NuGet
  • Crea soluzione
  • Esegui test delle unità
  • Impostazione dell'ambiente di test di integrazione
  • Esegui test di integrazione
  • Tear down integration test environment
  • Crea un pacchetto di distribuzione
  • Crea script di migrazione

E poi, quando si tratta di riproducibilità, è diventato evidente che questo ha segnato basso. Quando lasci che TeamCity sia il tuo script di compilazione diventa difficile riprodurre risultati simili, affidabili, sul tuo computer di sviluppo.

Quando hai uno script di build, lo script di build sa tutto ciò che deve essere fatto e ha tutte le variabili in atto. Quando si utilizza un server CI come script di compilazione e si verifica qualche problema, ad esempio un fallimento di un test complesso o la necessità di creare manualmente un pacchetto di distribuzione (come nel mio esempio), è necessario completare manualmente tutti i passaggi della compilazione.

Quindi, in breve , perché uno script di compilazione (MS)? Perché finirai per avere più requisiti quando si tratta della tua build. Probabilmente vorrai eseguire alcuni test e generare alcuni artefatti da quello. Probabilmente vuoi effettuare distribuzioni. E quando tutto ciò che vuoi deve essere eseguibile, che si trovi su un server di build o sul tuo computer, non può finire da nessuna parte se non in uno script di build.