Acquisizione di MSDeploy sul nostro server di build/integrazione: è necessario un aggiornamento MSBuild?

Question

Abbiamo quello che penso sia un processo di compilazione standard: 1. Sviluppatore: Check-in codice 2. Build: repo dei sondaggi, vede il cambiamento e inizia il build che: 3. Build: aggiornamenti da repo, Build w/MSBuild, Esegue test di unità w/NUnit, 4. costruire: crea pacchetto di installazione

il nostro team di sicurezza ci permette di tirare dal server di build, ma non consente al server di build per spingere. Pertanto, in genere eseguiamo il rdp in, d/l gli installer e li eseguiamo, il che esclude i servizi di distribuzione chiari, quindi avrei bisogno di generare pacchetti. Mi piacerebbe usare MSDeploy, se non che abbiamo i seguenti problemi:

1. Siamo in .NET 3.5, e l'obiettivo MSBuild (Package) che utilizza MSDeploy impone 4.0. C'è qualcosa che avrei bisogno di installare diverso da. NET 4.0 RC per questo? (MSBuild farà parte di questo aggiornamento?)
2. Quando si generano pacchetti con MSDeploy, vedo che non ho solo 1 file. C'è un file zip, deploy.cmd, SourceManifest.xml e SetParameters.xml. Per cosa sono tutti gli altri file e perché non dovrebbero essere tutti nel "pacchetto"?
3. Sembra come se fosse possibile creare pacchetti dicendo al sistema di controllare un sito IIS funzionante. Ma se i pacchetti sono costruiti da un ambiente CI, non sei sostanzialmente sfortunato qui? Sembra che ne abbiano progettato un po 'per gli sviluppatori su piccola scala che utilizzano il loro ambiente di sviluppo. Questo è un buon caso d'uso, ma sono interessato a vedere quale sia l'esperienza aziendale di tutti con lo strumento

Qualche suggerimento?

Answer 1

Se non si utilizza Visual Studio 2010 per la vostra applicazione, allora vorrei suggerire che si sceglie una delle seguenti opzioni:

1. Usa msdeploy.exe
2. Installare Visual Studio 2010 sul server di build e ci le attività MSDeploy stesse

Lasciatemi spiegare un po 'di più.

Opzione 1

MSDeploy per sé non ha dipendenze da MSBuild così si potrebbe installarlo da solo sul server di build per creare i pacchetti per voi. È possibile scaricarlo da here. Successivamente è possibile creare uno script di distribuzione MSBuild utilizzando l'attività Exec per richiamare msdeploy.exe con il comando per creare il pacchetto.

Circa la seconda opzione File

I .targets, nonché i compiti per MSDeploy non vengono distribuiti con il framework .NET, ma con Visual Studio 2010 se stessa. Quindi, se si desidera sfruttare uno di questi, è necessario installare VS 2010 sul server di build.

Hai menzionato l'utilizzo del pacchetto target nel tuo post. Non sarai in grado di usarlo perché quell'obiettivo è parte di un processo di compilazione più grande per i progetti .NET 4.Che cosa si potrebbe fare è quello di creare un file MSBuild separato (separata come nel non file di progetto), che utilizza MSBuild 4 a chiamare i compiti che vengono consegnati con VS 2010 per distribuzione Web.

qui rispondo proprio elenco numerato specificamente

1. Si dovrà installare Visual Studio 2010 in quanto tali compiti sono forniti con VS stesso e non il quadro.
2. Questi file sono utilizzati per interagire con il pacchetto. Il tuo pacchetto presenta la tua domanda nel suo insieme. Il deploy.cmd invocherà msdeploy.exe per eseguire la distribuzione per te. SourceManifest.xml e SetParameters.xml vengono utilizzati per personalizzare la distribuzione della tua app. deploy.cmd userà quei file quando invocherà msdeploy.exe. In altre parole, se si desidera personalizzare il percorso in cui installare l'applicazione Web, è necessario impostarlo in SetParameters.xml insieme ad altre opzioni.
3. A destra le impostazioni possono provenire da IIS, ma molti sviluppatori preferiscono utilizzare il server delle applicazioni VS anziché IIS. Questa è la mia preferenza. Quello che suggerirei in questo caso è distribuire la tua applicazione in un ambiente che utilizzerai come modello. Crea tutte le impostazioni IIS necessarie, crea il tuo pacchetto MSDeploy e poi prendi il file archive.xml dal pacchetto e usalo quando crei il tuo pacchetto. Un'altra opzione è quella di configurare un server IIS su cui il processo di compilazione può essere distribuito, quindi utilizzare MSDeploy per sincronizzare solo i file che compongono la tua app e quindi ancora una volta per generare il pacchetto da quel server IIS.