Compilazione e distribuzione continue

Quando molti sviluppatori collaborano a progetti software complessi, il processo di integrazione di diverse parti di codice può rivelarsi lungo e imprevedibile. È possibile, tuttavia, rendere tale processo più efficiente e affidabile compilando e distribuendo il progetto in modo continuativo.

Per integrazione continuata (CI, Continuous Integration) si intende il processo di integrazione del codice in un repository condiviso, eseguito il più spesso possibile. Durante l'integrazione del codice, un'interruzione di compilazione o un errore del test può notificare tempestivamente un errore nel codice.

Martin Fowler propone la suddivisione delle procedure seguente per l'integrazione continuata:

• Gestire un solo repository di origine.

• Automatizzare la compilazione.

• Rendere indipendente la compilazione.

• Eseguire l'archiviazione almeno una volta al giorno.

• Basare ogni archiviazione sul server CI.

• Mantenere veloce la compilazione.

• Eseguire test in un clone dell'ambiente di produzione.

• Rendere semplice l'acquisizione del file eseguibile più recente a qualsiasi utente.

• Essere sempre al corrente di tutto ciò che avviene.

• Automatizzare la distribuzione.

Per ulteriori informazioni, vedere la pagina Integrazione continuata del sito Web di Martin Fowler (la pagina potrebbe essere in inglese).

Visual Studio Application Lifecycle Management (ALM) consente di gestire il processo end-to-end di sviluppo software e supporta la procedura di integrazione continuata. Utilizzando le funzionalità di ALM di Visual Studio, il progetto può evitare ritardi imprevisti, costi eccessivi e rischi di esecuzione.

In questo argomento

• Gestione delle dipendenze

• Integrazione continuata in Visual Studio 2010

• Preparazione e informazioni introduttive

• Controllo della versione

• Compilazione

• Test e distribuzione

• Integrazione del progetto e comunicazione

Gestione delle dipendenze

L'integrazione di codice è un processo complesso a causa delle dipendenze nel codice stesso. Una libreria che disegna un cerchio sullo schermo, ad esempio, dipende dal metodo Sqrt() delle librerie matematiche del sistema. Se il metodo Sqrt() cambia, è necessario aggiornare la libreria di conseguenza. I componenti hardware e i sistemi operativi cambiano con una frequenza di gran lunga minore rispetto al progetto team. Se, tuttavia, si ignorano le modifiche in qualsiasi circostanza, possono verificarsi risultati gravi. È possibile integrare il codice quanto prima possibile per determinare se è basato su presupposti validi e se funziona nel modo previsto.

Le modifiche nel codice possono influire sulle dipendenze in modo diverso. Nella figura seguente vengono illustrate due situazioni. Nell'esempio a sinistra viene illustrata una modifica relativamente isolata. Nell'esempio a destra viene invece illustrata una modifica con un possibile impatto maggiore, in quanto presenta molte dipendenze.

Nella figura seguente viene illustrato come modifiche costanti possano avere effetti complessi se non si integra e aggiorna il codice in modo continuativo.

Nel passaggio 1 viene modificato il blocco di codice h, una modifica che può influire su tutti blocchi di codice dipendenti, ovvero a, b, d, e ed f. Nel passaggio 2 vengono modificati i blocchi di codice a e b. Se il team non esegue l'integrazione tra i passaggi 1 e 2, i blocchi a e b potrebbero non essere più validi. Nel passaggio 3 viene modificato il blocco di codice f. Presupponendo che il team non esegua l'integrazione tra i passaggi 2 e 3, questa operazione ha influito sul blocco di codice b in questo punto, lo ha modificato e quindi vi ha influito di nuovo. Di conseguenza, il blocco di codice b può diventare difficile da correggere.

Integrazione continuata in Visual Studio 2010

ALM di Visual Studio include set di strumenti integrati per supportare l'integrazione continuata. Come illustrato nella figura seguente, questi strumenti includono controllo della versione, compilazione, test, distribuzione in un ambiente lab, gestione degli elementi di lavoro e funzionalità di data warehouse.

È innanzitutto possibile utilizzare Controllo della versione di Team Foundationper gestire rami, insiemi di modifiche e la relativa integrazione. Ogni membro del team può utilizzare aree di lavoro per lavorare in modo indipendente. Per ulteriori informazioni, vedere Creazione di un ramo e unione e Configurare il computer di sviluppo per l'utilizzo del progetto del team.

In secondo luogo, è possibile utilizzare Team Foundation Build per compilare, testare e distribuire il software in un sistema automatizzato e distribuito. Come illustrato nella figura precedente, Team Foundation Build consente due tipi di compilazioni. Un tipo utilizza una compilazione continua per compilare il ramo di sviluppo. L'altro tipo utilizza un'archiviazione gestita per compilare il ramo principale. Visual Studio Team Foundation Server supporta cinque tipi di compilazioni: manuale, continua (attivata da ogni archiviazione), sequenziale (vengono accumulate archiviazioni fino al termine della compilazione precedente), archiviazione gestita e pianificata. Per ulteriori informazioni, vedere Creare una definizione di compilazione di base, Informazioni sul sistema Team Foundation Build e Archiviare modifiche in sospeso controllate da una compilazione di archiviazione gestita.

In terzo luogo, le funzionalità di gestione di ALM di Visual Studio consentono di definire e distribuire le compilazioni in ambienti lab fisici e virtuali. Per rilevare errori di integrazione in fase di esecuzione in un ambiente specifico, è possibile distribuire una compilazione in un ambiente lab e quindi eseguire gruppi di test su tale compilazione. Per ulteriori informazioni, vedere Utilizzo di un lab virtuale per il ciclo di vita dell'applicazione.

Le funzionalità di test di ALM di Visual Studio, inoltre, sono disponibili nei computer dei membri del team, nel computer di compilazione e nell'ambiente lab. Innanzitutto, l'esecuzione di gruppi di test nel computer dello sviluppatore consente di rilevare i problemi relativi al codice modificato o creato di recente. In secondo luogo, l'esecuzione di test nel computer di compilazione consente di rilevare i problemi relativi all'integrazione con altro codice. In terzo luogo, l'esecuzione di test nell'ambiente lab consente di rilevare i problemi relativi a un ambiente specifico configurato dal team. Per ulteriori informazioni, vedere Procedura: configurare ed eseguire test pianificati dopo avere compilato l'applicazione.

Nota

L'esecuzione di test può generare metrica di code coverage, che è possibile utilizzare per determinare la quantità di codice che può essere gestita dai test case. Non è tuttavia possibile utilizzare il code coverage per misurare la completezza o la qualità dei test. Per ulteriori informazioni, vedere Procedura: configurare code coverage mediante impostazioni di test per test automatizzati.

In quarto luogo, Visual Studio Team Foundation Server è il repository in cui vengono archiviati gli elementi di lavoro. È possibile creare e gestire gli elementi di lavoro, ad esempio bug o attività, assegnati ai membri del team. Se una compilazione viene interrotta durante l'integrazione di codice, il team deve correggere il problema non appena possibile. È possibile configurare Team Foundation Server per creare elementi di lavoro per le interruzioni della compilazione. Per ulteriori informazioni, vedere Rilevamento di bug, attività e altri elementi di lavoro.

I database del warehouse per Team Foundation Server e per SQL Server Analysis Services, infine, eseguono l'aggregazione e la correlazione di tutti i dati forniti dai sottosistemi in Team Foundation Server. Questi sottosistemi includono controllo della versione, compilazione, test, distribuzione e gestione degli elementi di lavoro. Il team può pertanto visualizzare il processo end-to-end di integrazione continuata. Per ulteriori informazioni, vedere Database warehouse per Visual Studio ALM.

Preparazione e informazioni introduttive

Il team può procedere come indicato di seguito per iniziare a utilizzare l'integrazione continuata e Team Foundation Server:

1. Utilizzare Controllo della versione di Team Foundation per integrare codice in una singola codebase.

2. Creare un tipo di compilazione manuale in Team Foundation Build.

3. Eseguire test case automatizzati per verificare la qualità della compilazione. Se non si dispone di un gruppo di test appropriato, creare un gruppo di test segnaposto e importare alcuni test case automatizzati. Questo gruppo può fungere da segnaposto per i test futuri.

4. Assicurarsi di fornire i file binari risultanti da una compilazione in un percorso condiviso. Questa strategia può semplificare la diagnosi dei problemi verificatisi durante i test.

5. Utilizzare Microsoft Test Manager per rilevare gli errori di integrazione in fase di esecuzione in un ambiente specifico.

Controllo della versione

Un sistema di controllo della versione fornisce un repository condiviso al codice. Un piccolo team può operare con un singolo ramo. L'utilizzo di due o più rami è tuttavia più efficace, in quanto è in genere necessario sviluppare più versioni del codice e rilasciare il progetto in attività cardine diverse. Per ulteriori informazioni su come creare e unire rami del codice, vedere la pagina Guida alla creazione di rami in Team Foundation Server 2.0 del sito Web CodePlex (la pagina potrebbe essere in inglese).

Compilazione

Nell'integrazione continuata un sistema di compilazione genera i componenti eseguibili che possono essere testati e distribuiti. Un sistema di compilazione fornisce inoltre feedback sotto forma di errori e avvisi di compilazione. Questi errori sono causati da modifiche introdotte nell'origine del progetto.

In Team Foundation Build sono disponibili i seguenti tipi di compilazione:

• Manuale: le compilazioni vengono accodate dai membri del team.

• Continua: le compilazioni vengono accodate da un'archiviazione in un ramo del controllo della versione.

• Sequenziale: le compilazioni vengono accumulate finché non termina la compilazione precedente.

• Archiviazione gestita: le archiviazioni vengono accettate solo se le modifiche inviate vengono unite e compilate correttamente.

• Pianificata: le compilazioni si verificano in base a una pianificazione definita.

Per ulteriori informazioni, vedere Creare una definizione di compilazione di base.

Aspettative dei membri del team per implementare correttamente l'integrazione continuata

I membri del team devono organizzare le origini in modo che la compilazione non richieda più di 10 minuti. Per progetti di dimensioni maggiori, questa frequenza potrebbe non essere possibile. Utilizzando Team Foundation Server, il team può configurare diverse definizioni di compilazione per compilare diversi sottoinsiemi della codebase. Se le compilazioni richiedono molto tempo, è possibile utilizzare un tipo di compilazione sequenziale per generare continuamente file binari per il codice non modificato.

Se e quando viene interrotta una compilazione, il team deve correggerla immediatamente. Presupponendo che il ramo principale non venga interessato+ da un'integrazione inversa errata, la maggior parte delle interruzioni di compilazione è causata da un'archiviazione errata in un ramo di lavoro o da un'integrazione in avanti dal ramo principale. È consigliabile assegnare l'attività di correzione delle interruzioni di compilazione a un membro del team per un certo periodo di tempo e quindi ruotare questa assegnazione tra gli altri membri del team.

Numero di compilazioni da eseguire al giorno

Quando si esegue l'integrazione continuata del codice, è possibile eseguire una compilazione continua per ogni archiviazione verificatasi in ogni ramo. È inoltre possibile eseguire una compilazione sequenziale indipendente dal nuovo codice archiviato. Per ulteriori informazioni, vedere Creare una definizione di compilazione di base e Monitorare lo stato di una compilazione in esecuzione.

Come ottenere compilazioni del codice più rapide tramite Team Foundation Server

La configurazione della definizione di compilazione per eseguire compilazioni incrementali consentirà di aumentare la velocità della compilazione. È possibile utilizzare i log di compilazione per identificare le parti lente della compilazione che è possibile migliorare. Per ulteriori informazioni, vedere Configurare Team Foundation Build per una compilazione incrementale.

Ridimensionamento dell'integrazione continuata tramite Team Foundation Build

I controller e gli agenti di compilazione semplificano il ridimensionamento del ciclo di integrazione continuata.

Per ulteriori informazioni, vedere Informazioni sul sistema Team Foundation Build.

Test e distribuzione

Utilizzo di test e distribuzione nell'integrazione continuata

Nella figura seguente viene illustrato il contributo delle funzionalità di test e distribuzione di ALM di Visual Studio per l'integrazione continuata.

Quando si esegue l'integrazione continuata del codice, innanzitutto, è possibile individuare i problemi relativi al codice dalla compilazione stessa. A seconda del compilatore utilizzato, la compilazione può avere esito positivo o negativo. È possibile generare un rapporto di compilazione contenente i messaggi di errore e di avviso del compilatore. In ALM di Visual Studio, il rapporto di compilazione fornisce anche altre informazioni, ad esempio i bug che sono stati corretti in questa compilazione, gli insiemi di modifiche che sono stati inclusi in questa compilazione e l'eventuale esecuzione dell'analisi del codice durante la compilazione. Utilizzando ALM di Visual Studio, è possibile verificare se la progettazione del codice segue le regole definite dal team. Per ulteriori informazioni, vedere Procedura: convalidare il codice .NET in base ai diagrammi livello.

In secondo luogo, è possibile individuare i problemi relativi al codice tramite l'esecuzione di unit test. Tali test consentono di diagnosticare i problemi in modo diverso dai compilatori. Le regole del compilatore verificano i problemi relativi a sintassi del codice e costrutti di linguaggio. Al contrario, gli unit test, che possono essere eseguiti in una compilazione al termine della compilazione stessa, possono verificare qualsiasi aspetto funzionale del codice. Questi unit test possono anche fornire metriche, ad esempio il code coverage in una compilazione, a partire da un set di unit test. Per ulteriori informazioni, vedere Procedura: configurare code coverage mediante impostazioni di test per test automatizzati.

Utilizzando Microsoft Test Manager, è possibile configurare un ambiente specifico in cui eseguire i test. Unit test isolati possono garantire un livello di verifica funzionale. Per gli ambienti, tuttavia, è necessario considerare gli importanti aspetti seguenti:

• Gli ambienti variabili possono influire sul funzionamento del codice. Ad esempio, le impostazioni di rete e la topologia potrebbero essere difficili da testare senza un ambiente Lab Management.

• L'automazione della distribuzione del codice in un ambiente specifico consente al team di ridurre i tempi di distribuzione e di aumentare il numero di iterazioni di distribuzione.

Per ulteriori informazioni, vedere How to: Create an Environment from Virtual Machine Templates e Configurazione di computer di test per l'esecuzione di test o la raccolta di dati.

Come organizzare i gruppi di test per consentire l'integrazione continuata

È possibile eseguire i gruppi di test più importanti per le compilazioni continue, in quanto una quantità eccessiva di test può provocare ritardi nel completamento della compilazione. Assicurarsi di eseguire tali test per l'iterazione corrente.

In un ciclo di compilazioni notturno o pianificato è inoltre possibile eseguire test da compilazioni precedenti e completare i test superati che verificano la funzionalità negli sprint precedenti.

Influenza dell'integrazione continuata sul team di test

L'integrazione continuata consente di identificare le compilazioni contenenti errori in modo che il team dei test non perda tempo installando e utilizzando compilazioni errate.

Integrazione del progetto e comunicazione

L'impegno richiesto per l'implementazione dell'integrazione continuata può essere notevole a seconda della dimensione del progetto. Il team deve definire e pianificare le attività per l'integrazione continuata nel primo sprint del progetto.

Se si desidera adottare l'integrazione continuata per fasi, è possibile iniziare implementando la compilazione automatizzata. È quindi possibile modificare tale compilazione perché includa l'esecuzione di unit test. È infine possibile aggiungere le funzionalità di distribuzione della compilazione testata in un ambiente lab e quindi eseguire test nell'ambiente per verificare se un ambiente variabile influisce sul codice.