Creazione e distribuzione di un'applicazione Web con TFS 2015 Build

Abbiamo appena installato TFS 2015 (Update 1) on-premise e stiamo provando a creare un sistema di integrazione/generazione continua utilizzando il nuovo sistema TFS Build. La build funziona bene, e mi dà una luce verde, ma quando guardo la build di default ha solo costruito i binari dalla directory bin, e non sembra esserci un modo semplice per distribuire l'app on-premise su un server locale .Creazione e distribuzione di un'applicazione Web con TFS 2015 Build

Esistono due opzioni di distribuzione per una copia di file system e uno script di PowerShell, e sarebbe certamente abbastanza facile usarli per copiare i file su un nuovo server, ma poiché la compilazione ha creato solo i binari, non lo faccio vedere uno strumento per raccogliere le risorse Web (cshtml, immagini, script, css, ecc.) per questo.

Dopo una ricerca esaustiva google, ho trovato un solo articolo che parla di questo a:

http://www.deliveron.com/blog/building-websites-team-foundation-build-2015/

Tuttavia, questo utilizza WebDeploy e crea un pacchetto di implementare piuttosto disordinato.

Come posso distribuire il sito (applicazione Web MVC standard, in realtà i miei test utilizzano il sito di defaultplate creato dalla procedura guidata di creazione del progetto) completo di risorse utente su un server locale nel modo più semplice possibile? Non voglio installare WebDeploy sui server e preferisco usare PowerShell o qualcosa per distribuire le risorse finali.

La build è solo il modello di build standard di Visual Studio, con 4 passaggi (Build, Test, Index & Publish, Publish Build Artifacts).

fonte

2016-02-11 Erik Funkenbusch

Come è andata a finire per te? Sto cercando di assicurarmi che la distribuzione non si verifichi se il seguente passaggio di prova non riesce. Eri in grado di farlo? –

@ one.beat.consumer - È necessario dividere la compilazione/test dalla distribuzione come due fasi separate, quindi è possibile distribuire lo stesso codice negli ambienti test/qa/prod. –

Grazie. La funzione "Rilascio" sta distribuendo i pacchetti come hai menzionato. Quello che stavo avendo problemi era separare l'esecuzione dei test dal passo di costruzione, poiché gli unici esempi che ho trovato per XUnit erano le personalizzazioni alla build. Da allora ho trovato il pacchetto NuGet xunit.runner.visualstudio che mi consente di personalizzare in modo appropriato una fase di test. Tuttavia, occorrono due build ora: il primo per creare il prepping per il test e il secondo per creare un pacchetto di distribuzione se i test superano. –

Usiamo "Visual Studio Build" step e come argomenti per MSBuild usiamo seguente riga:

/p:DeployOnBuild=True /p:PublishProfile=$(DeploymentConfiguration)

su variabili scheda DeploymentConfiguration deve essere configurato. Deve essere il nome del profilo di pubblicazione (nome file del file pubxml). Se il nome del file è Build.pubxml, il profilo di pubblicazione è Build.

ad esempio:

/p:DeployOnBuild=True /p:PublishProfile=Build

fonte

2016-04-12 14:05:24

@Sabastian - Grazie. La mia domanda quindi è come può essere impedita questa distribuzione se le cose in un passaggio di compilazione del seguente test di Visual Studio falliscono? –

-5

Utilizziamo WebDeploy/MSDeploy per oltre 40 applicazioni e lo adoriamo. Installiamo WebDeploy su tutti i nostri server per consentirci di implementare più facilmente, ma è anche possibile utilizzare la funzione Web Deploy On Demand che non richiede WebDeploy essere preinstallato.

fonte

2016-02-12 03:51:10 chief7

I wanted to add that Ben Day has an excellent write-up that helped us package quickly and then release to multiple environments through Release Manager.

I suoi argomenti MSBuild simile a questa:

/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=$(build.artifactstagingdirectory)\for-deploy\website

La differenza tra questo e la risposta accettata è che questo set di parametri mette in scena tutto in una cartella di manufatti, e quindi lo salva come parte della costruzione. Possiamo quindi distribuire esattamente lo stesso codice ripetutamente.

Catturiamo i file web.env.config insieme alla cartella per la distribuzione e quindi utilizziamo le trasformazioni xdt nel processo di rilascio per garantire che tutto venga aggiornato per qualsiasi ambiente venga distribuito. Funziona bene per tutti i nostri progetti web.

fonte

2017-09-19 00:24:48

La directory di pubblicazione può essere impostata nel profilo di pubblicazione, non è necessario specificarla sulla riga di comando. Quindi, può essere versione più facilmente –

Questo è un buon punto. Per il nostro ambiente (forse siamo insoliti qui?) Abbiamo scelto questo metodo per ignorare qualsiasi profilo di pubblicazione al fine di acquisire il sito come artefatto di build e quindi distribuirlo a più destinazioni tramite TFS Release Manager. –

Creazione e distribuzione di un'applicazione Web con TFS 2015 Build

risposta

Problemi correlati