Distribuzione Web aziendale: Panoramica dello scenario

di Jason Lee

Questo set di esercitazioni usa una soluzione di esempio con un livello realistico di complessità, insieme a uno scenario di distribuzione aziendale fittizio, per fornire un'implementazione di riferimento e fornire le attività e le procedure dettagliate di un contesto comune. Questo argomento descrive lo scenario dell'esercitazione e introduce la soluzione di esempio.

Descrizione dello scenario

Fabrikam, Inc., un'azienda fittizia, sta creando una soluzione che consente ai team di vendita remoti di archiviare e recuperare le informazioni di contatto da un'interfaccia Web.

I processi di Gestione del ciclo di vita dell'applicazione (ALM) in Fabrikam, Inc. richiedono la distribuzione della soluzione in tre ambienti server in varie fasi del processo di sviluppo software:

• Un ambiente di test per sviluppatori o "sandbox".
• Ambiente di staging basato su Intranet.
• Ambiente di produzione con connessione Internet.

Ognuno di questi ambienti presenta requisiti di configurazione e sicurezza diversi e ogni situazione comporta problemi di distribuzione univoci.

Infrastruttura del server Fabrikam, Inc.

Si tratta dell'infrastruttura di sviluppo e distribuzione di alto livello presso Fabrikam, Inc.

Le workstation per sviluppatori, l'infrastruttura di controllo del codice sorgente, l'ambiente di test per sviluppatori e l'ambiente di gestione temporanea si trovano nella rete Intranet all'interno del dominio Fabrikam.net. L'ambiente di produzione si trova in una rete perimetrale ,nota anche come rete perimetrale, zona demilitarizzata e subnet schermata, isolata dalla rete Intranet da un firewall. Si tratta di uno scenario di distribuzione comune: in genere si isolano i server Web con connessione Internet dall'infrastruttura server interna tramite l'uso di firewall o server gateway.

Esempio:

• Un server Team Foundation Server (TFS) 2010 con un server di compilazione separato offre funzionalità di controllo del codice sorgente e integrazione continua (CI).
• L'ambiente di test per sviluppatori include un server Web Internet Information Services (IIS) 7.5 e un server di database SQL Server 2008 R2.
• L'ambiente di produzione include più server Web IIS 7.5 sincronizzati da un server controller WFF (Web Farm Framework), insieme a un server di database SQL Server 2008 R2. In pratica, il server di database può usare clustering o mirroring per migliorare la scalabilità e la disponibilità.
• L'ambiente di staging è progettato per replicare la configurazione dell'ambiente di produzione il più possibile.
• I criteri di isolamento del firewall e della rete non consentono la distribuzione diretta e automatizzata dalla rete Intranet alla rete perimetrale.

La configurazione di ognuno di questi ambienti è descritta in modo più dettagliato nella seconda esercitazione, Configurazione degli ambienti server per la distribuzione Web.

Ruoli del team per ALM

Questi utenti sono coinvolti nella creazione, gestione, compilazione e pubblicazione della soluzione Contact Manager:

• Matt Hink è uno sviluppatore di applicazioni Web presso Fabrikam, Inc. Fa parte del team che ha sviluppato la soluzione Contact Manager usando Visual Studio 2010. Matt ha diritti di amministratore completi sui server nell'ambiente di test per sviluppatori, che consente di configurare l'ambiente in modo da soddisfare le proprie esigenze. Ha anche accesso utente all'istanza di Visual Studio 2010 TFS in cui archivia il codice sorgente per la soluzione Contact Manager.

• Rob Walters è un amministratore del server per il team di sviluppo Fabrikam, Inc. Rob ha accesso amministrativo sul server TFS in modo che possa configurare tutti gli aspetti di TFS e Team Build. Rob ha anche accesso amministrativo ai server Web di test e gestione temporanea e funge da amministratore del database (DBA) per i server di database negli ambienti di test e gestione temporanea. Rob ha configurato Team Build nel server TFS per eseguire queste attività:

  • Compilare ed eseguire unit test nell'applicazione ogni volta che un utente controlla un file in TFS. Questo è chiamato CI.
  • Distribuire automaticamente l'applicazione Contact Manager nell'ambiente di test dopo che l'applicazione supera gli unit test. Ciò include la pubblicazione del database nei server di test nella distribuzione iniziale e gli eventuali aggiornamenti al database dopo la distribuzione iniziale.
  • Distribuire l'applicazione Contact Manager nell'ambiente di gestione temporanea in un processo singolo.
  • Creare un pacchetto Web che un amministratore del server Web e un DBA possono usare per pubblicare l'applicazione nell'ambiente di produzione.

• Lisa Andrews è un amministratore del server responsabile della distribuzione di applicazioni nei server di produzione Fabrikam, Inc. Ha accesso in lettura alla condivisione in cui TFS Team Build archivia il pacchetto di distribuzione Web dopo aver compilato l'applicazione Contact Manager. Ha anche accesso amministrativo ai server Web di produzione in modo che possa distribuire l'applicazione in produzione. Inoltre, agisce come DBA che distribuisce database e aggiornamenti del database nel server di database nell'ambiente di produzione.

Soluzione Contact Manager

La soluzione Contact Manager è progettata per consentire agli utenti registrati, connessi di aggiungere e modificare le informazioni di contatto tramite un'interfaccia Web. La soluzione Contact Manager è costituita da quattro singoli progetti:

• ContactManager.Mvc. Si tratta di un progetto di applicazione Web MVC3 ASP.NET che rappresenta il punto di ingresso per la soluzione. Offre alcune funzionalità di base dell'applicazione Web, ad esempio fornendo agli utenti la possibilità di creare e visualizzare i dettagli dei contatti. L'applicazione si basa su un servizio Windows Communication Foundation (WCF) per gestire i contatti e un database di servizi applicazioni ASP.NET per gestire l'autenticazione e l'autorizzazione.
• ContactManager.Database. Si tratta di un progetto di database di Visual Studio 2010. Il progetto definisce lo schema per un database che archivia i dettagli del contatto.
• ContactManager.Service. Si tratta di un progetto di servizio Web WCF. WCF espone un endpoint che consente ai chiamanti di eseguire operazioni create, recuperare, aggiornare ed eliminare (CRUD) nel database di Contact Manager. Il servizio si basa sul database di Contact Manager e sull'assembly di ContactManager.Common.dll.
• ContactManager.Common. Si tratta di un progetto di libreria di classi. Il servizio WCF si basa sui tipi definiti in questo assembly.

Una revisione completa della soluzione e dei relativi requisiti di distribuzione viene fornita nella prima esercitazione in questa serie, Distribuzione Web in Enterprise.

Attività di distribuzione

Esistono diverse attività distinte coinvolte nella distribuzione di applicazioni in ambienti diversi in un'organizzazione di grandi dimensioni. Queste sono le attività principali che illustrano le esercitazioni:

Ecco un elenco di ogni passaggio del processo di distribuzione dal punto di vista degli utenti descritti in precedenza in questo documento:

1. Tutti i membri del team esaminano la soluzione Contact Manager in Visual Studio 2010 per determinare i requisiti e i problemi di distribuzione chiave.
2. Matt Hink può distribuire la soluzione Contact Manager direttamente dalla workstation per sviluppatori all'ambiente di test per sviluppatori, per eseguire un test iniziale della logica di distribuzione.
3. Matt Hink aggiunge l'applicazione al controllo del codice sorgente in TFS.
4. Rob Walters crea varie definizioni di compilazione per la soluzione Contact Manager in Team Build. Una definizione di compilazione usa CI per distribuire la soluzione nell'ambiente di test per sviluppatori ogni volta che un utente controlla il nuovo codice. Un'altra definizione di compilazione consente agli utenti di attivare le distribuzioni nell'ambiente di staging in base alle esigenze.
5. Ogni volta che un utente controlla il nuovo codice, Team Build compila automaticamente i componenti della soluzione, esegue unit test e distribuisce la soluzione nell'ambiente di test per sviluppatori se la compilazione ha avuto esito positivo e il passaggio degli unit test.
6. Quando un utente attiva una distribuzione nell'ambiente di staging, la soluzione viene inserita in un pacchetto e distribuita in un processo in un singolo passaggio. Questo processo genera anche un pacchetto per la distribuzione manuale nell'ambiente di produzione.
7. Lisa Andrews distribuisce l'applicazione nell'ambiente di produzione importando manualmente il pacchetto Web creato nel passaggio 6.

Problemi di distribuzione chiave

La soluzione Contact Manager e lo scenario Fabrikam, Inc. evidenziano vari problemi e sfide comuni che possono verificarsi quando si distribuiscono soluzioni complesse e su scala aziendale. Ad esempio:

• È necessario essere in grado di distribuire progetti in più ambienti, ad esempio gli ambienti di sviluppo o di test, le piattaforme di gestione temporanea e i server di produzione. La soluzione deve essere distribuita con impostazioni di configurazione diverse per ogni ambiente.
• È necessario distribuire più progetti dipendenti contemporaneamente nell'ambito di un processo di compilazione e distribuzione automatizzato o in un singolo passaggio.
• È necessario essere in grado di guidare la distribuzione da un processo automatizzato. Ad esempio, si vuole usare un processo ci per distribuire applicazioni Web in un ambiente di gestione temporanea quando viene archiviato il nuovo codice.
• È necessario controllare il processo di distribuzione e impostare le variabili di distribuzione dall'esterno di Visual Studio, poiché gli sviluppatori potrebbero avere le impostazioni di configurazione corrette o le credenziali necessarie per ogni ambiente di destinazione.
• È necessario distribuire progetti di database basati sullo schema e conservare i dati esistenti nelle distribuzioni successive.
• È necessario distribuire i database di appartenenza in base ad hoc senza distribuire i dati dell'account utente. Potrebbe anche essere necessario aggiornare lo schema dei database di appartenenza distribuiti senza perdere i dati dell'account utente esistenti.
• È necessario escludere determinati file o cartelle quando si distribuisce il contenuto in vari ambienti di destinazione.

Inoltre, la gestione della distribuzione quando gli aggiornamenti sono frequenti e incrementali genera alcuni problemi aggiuntivi. Ad esempio:

• Si eseguono unit test ogni volta che uno sviluppatore controlla il nuovo codice. Si vuole distribuire la soluzione solo se il codice supera gli unit test.
• Quando si distribuisce un'applicazione Web in un ambiente di gestione temporanea o di produzione, si vuole reindirizzare gli utenti a un file diapp_offline.htm per la durata del processo di distribuzione.
• Si vuole registrare le attività di distribuzione. Il processo di distribuzione deve inviare notifiche tramite posta elettronica di distribuzioni riuscite o non riuscite ai destinatari designati.
• Se una distribuzione automatica ha esito negativo, il processo di distribuzione deve ritentare la distribuzione corrente o distribuire il pacchetto Web precedente.

IndietroAvanti