Gestione del ciclo di vita delle applicazioni: dallo sviluppo alla produzione

  • Articolo

di Jason Lee

Questo argomento illustra come una società fittizia gestisce la distribuzione di un'applicazione Web ASP.NET tramite ambienti di test, gestione temporanea e produzione come parte di un processo di sviluppo continuo. In tutto l'argomento vengono forniti collegamenti per altre informazioni e procedure dettagliate su come eseguire attività specifiche.

L'argomento è progettato per offrire una panoramica generale per una serie di esercitazioni sulla distribuzione Web nell'organizzazione. Non preoccuparti se non hai familiarità con alcuni dei concetti descritti qui, le esercitazioni che seguono forniscono informazioni dettagliate su tutte queste attività e tecniche.

Nota

Per semplicità, questo argomento non illustra l'aggiornamento dei database come parte del processo di distribuzione. Tuttavia, l'esecuzione di aggiornamenti incrementali alle funzionalità dei database è un requisito di molti scenari di distribuzione aziendali ed è possibile trovare indicazioni su come eseguire questa operazione più avanti in questa serie di esercitazioni. Per altre informazioni, vedere Distribuzione di progetti di database.

Panoramica

Il processo di distribuzione illustrato di seguito è basato sullo scenario di distribuzione Fabrikam, Inc. descritto in Distribuzione Web aziendale: Panoramica dello scenario. Prima di studiare questo argomento, leggere la panoramica dello scenario. Essenzialmente, lo scenario esamina il modo in cui un'organizzazione gestisce la distribuzione di un'applicazione Web ragionevolmente complessa, la soluzione Contact Manager, attraverso varie fasi in un ambiente aziendale tipico.

A livello generale, la soluzione Contact Manager passa attraverso queste fasi come parte del processo di sviluppo e distribuzione:

  1. Uno sviluppatore controlla il codice in Team Foundation Server (TFS) 2010.
  2. TFS compila il codice ed esegue gli unit test associati al progetto team.
  3. TFS distribuisce la soluzione nell'ambiente di test.
  4. Il team di sviluppo verifica e convalida la soluzione nell'ambiente di test.
  5. L'amministratore dell'ambiente di gestione temporanea esegue una distribuzione "what if" nell'ambiente di gestione temporanea, per stabilire se la distribuzione causerà problemi.
  6. L'amministratore dell'ambiente di gestione temporanea esegue una distribuzione in tempo reale nell'ambiente di gestione temporanea.
  7. La soluzione viene sottoposta a test di accettazione dell'utente nell'ambiente di gestione temporanea.
  8. I pacchetti di distribuzione Web vengono importati manualmente nell'ambiente di produzione.

Queste fasi fanno parte di un ciclo di sviluppo continuo.

Queste fasi fanno parte di un ciclo di sviluppo continuo.

In pratica, il processo è leggermente più complicato di questo, come si vedrà quando si esamina ogni fase in modo più dettagliato. Fabrikam, Inc. usa un approccio diverso alla distribuzione per ogni ambiente di destinazione.

Fabrikam, Inc. usa un approccio diverso alla distribuzione per ogni ambiente di destinazione.

Il resto di questo argomento esamina le fasi principali di questo ciclo di vita della distribuzione:

  • Prerequisiti: come configurare l'infrastruttura server prima di mettere in atto la logica di distribuzione.
  • Sviluppo e distribuzione iniziali: operazioni da eseguire prima di distribuire la soluzione per la prima volta.
  • Distribuzione da testare: come creare un pacchetto e distribuire il contenuto in un ambiente di test automaticamente quando uno sviluppatore controlla il nuovo codice.
  • Distribuzione nella gestione temporanea: come distribuire compilazioni specifiche in un ambiente di gestione temporanea e come eseguire distribuzioni "what if" per assicurarsi che una distribuzione non causi problemi.
  • Distribuzione nell'ambiente di produzione: come importare pacchetti Web in un ambiente di produzione quando l'infrastruttura di rete impedisce la distribuzione remota.

Prerequisiti

La prima attività in qualsiasi scenario di distribuzione consiste nel garantire che l'infrastruttura server soddisfi i requisiti degli strumenti e delle tecniche di distribuzione. In questo caso, Fabrikam, Inc. ha configurato l'infrastruttura server come segue:

Sviluppo e distribuzione iniziali

Prima che il team di sviluppo di Fabrikam, Inc. possa distribuire la soluzione Contact Manager per la prima volta, deve eseguire queste attività:

  • Creare un nuovo progetto team in TFS.
  • Creare i file di progetto Microsoft Build Engine (MSBuild) che contengono la logica di distribuzione.
  • Creare le definizioni di compilazione TFS che attivano i processi di distribuzione.

Creare un nuovo progetto team

Creare la logica di distribuzione

Matt Hink crea vari file di progetto MSBuild personalizzati, usando l'approccio split project file descritto in Informazioni sul file di progetto. Matt crea:

  • File di progetto denominato Publish.proj che esegue il processo di distribuzione. Questo file contiene destinazioni MSBuild che compilano i progetti nella soluzione, creano pacchetti Web e distribuiscono i pacchetti in un ambiente server di destinazione.
  • File di progetto specifici dell'ambiente denominati Env-Dev.proj e Env-Stage.proj. Contengono impostazioni specifiche per l'ambiente di test e l'ambiente di gestione temporanea, ad esempio stringhe di connessione, endpoint di servizio e dettagli del servizio remoto che riceveranno il pacchetto Web. Per indicazioni sulla scelta delle impostazioni appropriate per ambienti di destinazione specifici, vedere Configurare le proprietà di distribuzione per un ambiente di destinazione.

Per eseguire la distribuzione, un utente esegue il file Publish.proj usando MSBuild o Team Build e specifica il percorso del file di progetto specifico dell'ambiente pertinente (Env-Dev.proj o Env-Stage.proj) come argomento della riga di comando. Il file Publish.proj importa quindi il file di progetto specifico dell'ambiente per creare un set completo di istruzioni di pubblicazione per ogni ambiente di destinazione.

Nota

Il modo in cui questi file di progetto personalizzati funzionano indipendentemente dal meccanismo usato per richiamare MSBuild. Ad esempio, è possibile usare direttamente la riga di comando di MSBuild, come descritto in Informazioni sul file di progetto. È possibile eseguire i file di progetto da un file di comando, come descritto in Creare ed eseguire un file di comando di distribuzione. In alternativa, è possibile eseguire i file di progetto da una definizione di compilazione in TFS, come descritto in Creazione di una definizione di compilazione che supporta la distribuzione.
In ogni caso il risultato finale è lo stesso: MSBuild esegue il file di progetto unito e distribuisce la soluzione nell'ambiente di destinazione. Ciò offre una notevole flessibilità nella modalità di attivazione del processo di pubblicazione.

Dopo aver creato i file di progetto personalizzati, Matt li aggiunge a una cartella della soluzione e li controlla nel controllo del codice sorgente.

Creazione delle definizioni di compilazione

Come attività di preparazione finale, Matt e Rob collaborano per creare tre definizioni di compilazione per il nuovo progetto team:

  • DeployToTest. Viene compilata la soluzione Contact Manager e distribuita nell'ambiente di test ogni volta che si verifica un'archiviazione.
  • DeployToStaging. In questo modo le risorse vengono distribuite da una build precedente specificata all'ambiente di gestione temporanea quando uno sviluppatore accoda la compilazione.
  • DeployToStaging-WhatIf. Viene eseguita una distribuzione "what if" nell'ambiente di gestione temporanea quando uno sviluppatore accoda la compilazione.

Le sezioni seguenti forniscono maggiori dettagli su ognuna di queste definizioni di compilazione.

Distribuzione da testare

Il team di sviluppo di Fabrikam, Inc. gestisce ambienti di test per condurre un'ampia gamma di attività di test software, ad esempio verifica e convalida, test di usabilità, test di compatibilità e test ad hoc o esplorativi.

Il team di sviluppo ha creato una definizione di compilazione in TFS denominata DeployToTest. Questa definizione di compilazione usa un trigger di integrazione continua, il che significa che il processo di compilazione viene eseguito ogni volta che un membro del team di sviluppo di Fabrikam, Inc. esegue un'archiviazione. Quando viene attivata una compilazione, la definizione di compilazione:

  • Compilare la soluzione ContactManager.sln. Questo a sua volta compila ogni progetto all'interno della soluzione.
  • Eseguire unit test nella struttura della cartella della soluzione (se la soluzione viene compilata correttamente).
  • Eseguire i file di progetto personalizzati che controllano il processo di distribuzione (se la soluzione viene compilata correttamente e supera gli unit test).

Il risultato finale è che se la soluzione viene compilata correttamente e supera gli unit test, i pacchetti Web e qualsiasi altra risorsa di distribuzione vengono distribuiti nell'ambiente di test.

Il risultato finale è che se la soluzione viene compilata correttamente e supera gli unit test, i pacchetti Web e qualsiasi altra risorsa di distribuzione vengono distribuiti nell'ambiente di test.

Come funziona il processo di distribuzione?

La definizione di compilazione DeployToTest fornisce questi argomenti a MSBuild:

/p:DeployOnBuild=true;DeployTarget=package;TargetEnvPropsFile=[path]\Env-Dev.proj

Le proprietà DeployOnBuild=true e DeployTarget=package vengono usate quando Team Build compila i progetti all'interno della soluzione. Quando il progetto è un progetto di applicazione Web, queste proprietà indicano a MSBuild di creare un pacchetto di distribuzione Web per il progetto. La proprietà TargetEnvPropsFile indica al file Publish.proj dove trovare il file di progetto specifico dell'ambiente da importare.

Nota

Per una procedura dettagliata su come creare una definizione di compilazione come questa, vedere Creazione di una definizione di compilazione che supporta la distribuzione.

Il file Publish.proj contiene destinazioni che compilano ogni progetto nella soluzione. Include tuttavia anche la logica condizionale che ignora queste destinazioni di compilazione se si esegue il file in Team Build. In questo modo è possibile sfruttare le funzionalità di compilazione aggiuntive offerte da Team Build, ad esempio la possibilità di eseguire unit test. Se la compilazione della soluzione o gli unit test hanno esito negativo, il file Publish.proj non verrà eseguito e l'applicazione non verrà distribuita.

La logica condizionale viene eseguita valutando la proprietà BuildingInTeamBuild . Si tratta di una proprietà MSBuild impostata automaticamente su true quando si usa Team Build per compilare i progetti.

Distribuzione in gestione temporanea

Quando una compilazione soddisfa tutti i requisiti del team di sviluppo nell'ambiente di test, il team potrebbe voler distribuire la stessa compilazione in un ambiente di gestione temporanea. Gli ambienti di gestione temporanea vengono in genere configurati in modo che corrispondano alle caratteristiche dell'ambiente di produzione o "live" il più possibile, ad esempio in termini di specifiche del server, sistemi operativi e software e configurazione di rete. Gli ambienti di gestione temporanea vengono spesso usati per i test di carico, i test di accettazione dell'utente e le revisioni interne più ampie. Le compilazioni vengono distribuite nell'ambiente di gestione temporanea direttamente dal server di compilazione.

Le compilazioni vengono distribuite nell'ambiente di gestione temporanea direttamente dal server di compilazione.

Le definizioni di compilazione usate per distribuire la soluzione nell'ambiente di gestione temporanea , DeployToStaging-WhatIf e DeployToStaging, condividono queste caratteristiche:

  • In realtà non creano nulla. Quando Rob distribuisce la soluzione nell'ambiente di gestione temporanea, vuole distribuire una compilazione specifica, esistente già verificata e convalidata nell'ambiente di test. Le definizioni di compilazione devono solo eseguire i file di progetto personalizzati che controllano il processo di distribuzione.
  • Quando Rob attiva una compilazione, usa i parametri di compilazione per specificare la compilazione contenente le risorse da distribuire dal server di compilazione.
  • Le definizioni di compilazione non vengono attivate automaticamente. Rob accoda manualmente una compilazione quando vuole distribuire la soluzione nell'ambiente di gestione temporanea.

Questo è il processo generale per una distribuzione nell'ambiente di gestione temporanea:

  1. L'amministratore dell'ambiente di gestione temporanea, Rob Walters, accoda una compilazione usando la definizione di compilazione DeployToStaging-WhatIf . Rob usa i parametri di definizione di compilazione per specificare la compilazione che vuole distribuire.
  2. La definizione di compilazione DeployToStaging-WhatIf esegue i file di progetto personalizzati in modalità "what if". Questo genera file di log come se Rob eseguisse una distribuzione dinamica, ma non apporta effettivamente modifiche all'ambiente di destinazione.
  3. Rob esamina i file di log per verificare gli effetti della distribuzione nell'ambiente di gestione temporanea. In particolare, Rob vuole controllare cosa verrà aggiunto, cosa verrà aggiornato e cosa verrà eliminato.
  4. Se Rob è soddisfatto che la distribuzione non apporta modifiche indesiderate a risorse o dati esistenti, accoda una compilazione usando la definizione di compilazione DeployToStaging .
  5. La definizione di compilazione DeployToStaging esegue i file di progetto personalizzati. Queste risorse pubblicano le risorse di distribuzione nel server Web primario nell'ambiente di gestione temporanea.
  6. Il controller Web Farm Framework (WFF) sincronizza i server Web nell'ambiente di gestione temporanea. In questo modo l'applicazione è disponibile in tutti i server Web nella server farm.

Come funziona il processo di distribuzione?

La definizione di compilazione DeployToStaging fornisce questi argomenti a MSBuild:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;OutputRoot=[path to build folder]

La proprietà TargetEnvPropsFile indica al file Publish.proj dove trovare il file di progetto specifico dell'ambiente da importare. La proprietà OutputRoot esegue l'override del valore predefinito e indica il percorso della cartella di compilazione che contiene le risorse da distribuire. Quando Rob accoda la compilazione, usa la scheda Parametri per fornire un valore aggiornato per la proprietà OutputRoot .

Quando Rob accoda la compilazione, usa la scheda Parametri per fornire un valore aggiornato per la proprietà OutputRoot.

Nota

Per altre informazioni su come creare una definizione di compilazione come questa, vedere Distribuire una compilazione specifica.

La definizione di compilazione DeployToStaging-WhatIf contiene la stessa logica di distribuzione della definizione di compilazione DeployToStaging . Include tuttavia l'argomento aggiuntivo WhatIf=true:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;
   OutputRoot=[path to build folder];
   WhatIf=true

All'interno del file Publish.proj , la proprietà WhatIf indica che tutte le risorse di distribuzione devono essere pubblicate in modalità "what if". In altre parole, i file di log vengono generati come se la distribuzione fosse andata avanti, ma non viene effettivamente modificato nell'ambiente di destinazione. In questo modo è possibile valutare l'impatto di una distribuzione proposta, in particolare ciò che verrà aggiunto, cosa verrà aggiornato e cosa verrà eliminato, prima di apportare modifiche.

Nota

Per altre informazioni su come configurare le distribuzioni "what if", vedere Esecuzione di una distribuzione "What If".

Dopo aver distribuito l'applicazione al server Web primario nell'ambiente di gestione temporanea, WFF sincronizza automaticamente l'applicazione in tutti i server della server farm.

Nota

Per altre informazioni sulla configurazione di WFF per sincronizzare i server Web, vedere Creare una server farm con Il framework della web farm.

Distribuzione in produzione

Quando una compilazione è stata approvata nell'ambiente di gestione temporanea, il team di Fabrikam, Inc. può pubblicare l'applicazione nell'ambiente di produzione. L'ambiente di produzione è il punto in cui l'applicazione diventa "attiva" e raggiunge il pubblico di destinazione degli utenti finali.

L'ambiente di produzione si trova in una rete perimetrale con connessione Internet. Questo è isolato dalla rete interna che contiene il server di compilazione. L'amministratore dell'ambiente di produzione, Lisa Andrews, deve copiare manualmente i pacchetti di distribuzione Web dal server di compilazione e importarli in IIS nel server Web di produzione primario.

L'amministratore dell'ambiente di produzione deve copiare manualmente i pacchetti di distribuzione Web dal server di compilazione e importarli in I S nel server Web di produzione primario.

Questo è il processo generale per una distribuzione nell'ambiente di produzione:

  1. Il team di sviluppo consiglia a Lisa che una compilazione è pronta per la distribuzione nell'ambiente di produzione. Il team consiglia lisa della posizione dei pacchetti di distribuzione Web all'interno della cartella di rilascio nel server di compilazione.
  2. Lisa raccoglie i pacchetti Web dal server di compilazione e li copia nel server Web primario nell'ambiente di produzione.
  3. Lisa usa Gestione IIS per importare e pubblicare i pacchetti Web nel server Web primario.
  4. Il controller WFF sincronizza i server Web nell'ambiente di produzione. In questo modo l'applicazione è disponibile in tutti i server Web nella server farm.

Come funziona il processo di distribuzione?

Gestione IIS include un'Importazione guidata pacchetto applicazione che semplifica la pubblicazione di pacchetti Web in un sito Web IIS. Per una procedura dettagliata su come eseguire questa procedura, vedere Installazione manuale dei pacchetti Web.

Conclusione

Questo argomento ha fornito un'illustrazione del ciclo di vita della distribuzione per una tipica applicazione Web su scala aziendale.

Questo argomento fa parte di una serie di esercitazioni che forniscono indicazioni su vari aspetti della distribuzione di applicazioni Web. In pratica, in ogni fase del processo di distribuzione sono disponibili numerose attività e considerazioni aggiuntive e non è possibile includerle tutte in una singola procedura dettagliata. Per altre informazioni, vedere le esercitazioni seguenti:

Indietro