Distribuzione di un build specifico

di Jason Lee

Questo argomento descrive come distribuire pacchetti Web e script di database da una compilazione precedente specifica a una nuova destinazione, ad esempio un ambiente di staging o di produzione.

Questo argomento fa parte di una serie di esercitazioni basate sui requisiti di distribuzione aziendali di una società fittizia denominata Fabrikam, Inc. Questa serie di esercitazioni usa una soluzione di esempio, la soluzione Contact Manager, per rappresentare un'applicazione Web con un livello realistico di complessità, tra cui un'applicazione ASP.NET MVC 3, un servizio Windows Communication Foundation (WCF) e un progetto di database.

Il metodo di distribuzione al centro di queste esercitazioni si basa sull'approccio split project file descritto in Informazioni sul file di progetto, in cui il processo di compilazione e distribuzione è controllato da due file di progetto, uno contenente istruzioni di compilazione applicabili a ogni ambiente di destinazione e una contenente le impostazioni di compilazione e distribuzione specifiche dell'ambiente. In fase di compilazione, il file di progetto specifico dell'ambiente viene unito al file di progetto indipendente dall'ambiente per formare un set completo di istruzioni di compilazione.

Panoramica delle attività

Fino ad ora, gli argomenti di questa esercitazione sono stati incentrati su come compilare, creare pacchetti e distribuire applicazioni Web e database come parte di un processo singolo o automatizzato. In alcuni scenari comuni, tuttavia, desidererai selezionare le risorse che distribuisci da un elenco di build in una cartella di rilascio temporanea. In altre parole, la build più recente potrebbe non essere la compilazione che si vuole distribuire.

Si consideri lo scenario di integrazione continua (CI) descritto nell'argomento precedente , Creazione di una definizione di compilazione che supporta la distribuzione. È stata creata una definizione di compilazione in Team Foundation Server (TFS) 2010. Ogni volta che uno sviluppatore controlla il codice in TFS, Team Build compilerà il codice, creerà pacchetti Web e script di database come parte del processo di compilazione, eseguirà unit test e distribuirà le risorse in un ambiente di test. A seconda dei criteri di conservazione configurati durante la creazione della definizione di compilazione, TFS manterrà un certo numero di build precedenti.

=======

Si supponga ora di aver eseguito test di verifica e convalida su una di queste compilazioni nell'ambiente di test e si è pronti per distribuire l'applicazione in un ambiente di staging. Nel frattempo, gli sviluppatori potrebbero aver controllato il nuovo codice. Non si vuole ricompilare la soluzione e distribuirla nell'ambiente di staging e non si vuole distribuire la build più recente nell'ambiente di staging. Si vuole invece distribuire la build specifica verificata e convalidata nei server di test.

A tale scopo, è necessario indicare a Microsoft Build Engine (MSBuild) dove trovare i pacchetti Web e gli script di database generati da una compilazione specifica.

Sovrascrittura della proprietà OutputRoot

Nella soluzione di esempio il file Publish.proj dichiara una proprietà denominata OutputRoot. Come suggerisce il nome, si tratta della cartella radice che contiene tutti gli elementi generati dal processo di compilazione. Nel file Publish.proj è possibile notare che la proprietà OutputRoot fa riferimento al percorso radice per tutte le risorse di distribuzione.

<PropertyGroup>
  <!--This is where the .deploymanifest file will be written to during a build-->    
  <_DbDeployManifestPath>
    $(OutputRoot)ContactManager.Database.deploymanifest
  </_DbDeployManifestPath>    
  
  <!-- The folder where the .zip and .cmd file will be located for 
                ContactManager.Mvc Web project -->
  <_ContactManagerDest>
    $(OutputRoot)_PublishedWebsites\ContactManager.Mvc_Package\
  </_ContactManagerDest>
  
  <!-- The folder where the .zip and .cmd file will be located for 
                ContactManager.Service Web project -->
   <_ContactManagerSvcDest>
    $(OutputRoot)_PublishedWebsites\ContactManager.Service_Package\
  </_ContactManagerSvcDest>
  
  <!-- ... -->
</PropertyGroup>

Se si vuole che il file di progetto distribuisca pacchetti Web e script di database da un percorso diverso, ad esempio gli output di una build TFS precedente, è sufficiente eseguire l'override della proprietà OutputRoot . È necessario impostare il valore della proprietà sulla cartella di compilazione pertinente nel server Team Build. Se si esegue MSBuild dalla riga di comando, è possibile specificare un valore per OutputRoot come argomento della riga di comando:

msbuild.exe Publish.proj /p:TargetEnvPropsFile=EnvConfig\Env-Dev.proj 
  /p:OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\

In pratica, tuttavia, si vuole anche ignorare Build target—non ha senso compilare la soluzione se non si prevede di usare i risultati della compilazione. Puoi farlo specificando gli obiettivi che vuoi eseguire dalla riga di comando.

msbuild.exe Publish.proj /p:TargetEnvPropsFile=EnvConfig\Env-Dev.proj 
  /p:OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\
  /target:GatherPackagesForPublishing;PublishDBPackages;PublishWebPackages

Nella maggior parte dei casi, tuttavia, si desidera integrare la logica di distribuzione in una definizione di build TFS. Ciò consente agli utenti con l'autorizzazione Compilazioni in coda di distribuire il deployment da qualsiasi installazione di Visual Studio con una connessione al server TFS.

Creazione di una definizione di compilazione per distribuire compilazioni specifiche

La procedura seguente descrive come creare una definizione di compilazione che consente agli utenti di attivare le distribuzioni in un ambiente di staging con un singolo comando.

In questo caso, non si vuole che la definizione di compilazione crei effettivamente nulla, ma si vuole solo eseguire la logica di distribuzione nel file di progetto personalizzato. Il file Publish.projinclude la logica condizionale che ignora la destinazione di compilazione se il file è in esecuzione in Team Build. Lo fa valutando la proprietà predefinita BuildingInTeamBuild, viene effettuata automaticamente su true se si esegue il file di progetto in Team Build. Di conseguenza, è possibile ignorare il processo di compilazione ed eseguire semplicemente il file di progetto per distribuire una compilazione esistente.

Per creare una definizione di compilazione per attivare manualmente la distribuzione

1. In Visual Studio 2010, nella finestra Team Explorer espandere il nodo del progetto team, fare clic con il pulsante destro del mouse su Compilazioni e quindi scegliere Nuova definizione di compilazione.

   

2. Nella scheda Generale assegnare alla definizione di compilazione un nome (ad esempio , DeployToStaging) e una descrizione facoltativa.

3. Nella scheda Trigger selezionare Manuale : le archiviazioni non attivano una nuova compilazione.

4. Nella scheda Build Defaults, nella casella Copia l'output della compilazione nella seguente cartella di rilascio, digitare il percorso UNC (Universal Naming Convention) della cartella di rilascio (ad esempio, \TFSBUILD\Drops).

   

5. Nella scheda Processo, nell'elenco a discesa File del processo di build, lasciare selezionato DefaultTemplate.xaml. Si tratta di uno dei modelli di processo di compilazione predefiniti che vengono aggiunti a tutti i nuovi progetti team.

6. Nella tabella Parametri del processo di compilazione fare clic nella riga Items to Build (Elementi da compilare) e quindi fare clic sul pulsante con i puntini di sospensione .

   

7. Nella finestra di dialogo Elementi da compilare fare clic su Aggiungi.

8. Nell'elenco a discesa Elementi di tipo selezionare File di progetto MSBuild.

9. Passare al percorso del file di progetto personalizzato con cui si controlla il processo di distribuzione, selezionare il file e quindi fare clic su OK.

   

10. Nella finestra di dialogo Elementi da compilare fare clic su OK.

11. Nella tabella Parametri del processo di compilazione espandere la sezione Avanzate .

12. Nella riga Argomenti MSBuild specificare il percorso del file di progetto specifico dell'ambiente e aggiungere un segnaposto per il percorso della cartella di compilazione:

    /p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
    OutputRoot=PLACEHOLDER
    

    

    Annotazioni

    È necessario sovrascrivere il valore OutputRoot ogni volta che metti in coda una compilazione. Questa operazione è illustrata nella procedura successiva.

13. Fare clic su Salva.

Quando si attiva una compilazione, è necessario aggiornare la proprietà OutputRoot in modo che punti alla compilazione da distribuire.

Per distribuire una build specifica da una definizione di build

1. Nella finestra Team Explorer, fare clic con il pulsante destro del mouse sulla definizione di build e quindi scegliere Accoda nuova build.

   

2. Nella finestra di dialogo Compilazione coda, nella scheda Parametri, espandere la sezione Avanzate.

3. Nella riga Argomenti di MSBuild sostituire il valore della proprietà OutputRoot con il percorso della cartella di compilazione. Per esempio:

   /p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
      OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\
   

   

   Annotazioni

   Assicurarsi di includere una barra finale alla fine del percorso della cartella di compilazione.

4. Fare clic su Coda.

Quando metti in coda la compilazione, il file di progetto distribuirà gli script del database e i pacchetti web dalla cartella di output della build specificata nella proprietà OutputRoot.

Conclusione

In questo argomento è stato descritto come pubblicare risorse di distribuzione, ad esempio pacchetti Web e script di database, da una compilazione precedente specifica usando il modello di distribuzione split project file. È stato illustrato come eseguire l'override della proprietà OutputRoot e come incorporare la logica di distribuzione in una definizione di compilazione TFS.

Altre informazioni

Per altre informazioni sulla creazione di definizioni di compilazione, vedere Creare una definizione di compilazione di base e Definire il processo di compilazione. Per altre indicazioni sull'accodare le build, vedere Accodare una build.