Integrazione continua - Guida rapida

L'integrazione continua è stata introdotta per la prima volta nel 2000 con il software noto come Cruise Control. Nel corso degli anni, l'integrazione continua è diventata una pratica chiave in qualsiasi organizzazione di software. Si tratta di una pratica di sviluppo che richiede ai team di sviluppo di garantire che una build e il successivo test siano condotti per ogni modifica di codice apportata a un programma software. Questo concetto aveva lo scopo di rimuovere il problema di trovare le occorrenze tardive dei problemi nel ciclo di vita della build. Invece degli sviluppatori che lavorano in isolamento e non si integrano abbastanza, è stata introdotta l'integrazione continua per garantire che le modifiche al codice e le build non fossero mai eseguite in modo isolato.

Perché l'integrazione continua?

L'integrazione continua è diventata una parte integrante di qualsiasi processo di sviluppo software. Il processo di integrazione continua aiuta a rispondere alle seguenti domande per il team di sviluppo software.

• Tutti i componenti software funzionano insieme come dovrebbero? - A volte i sistemi possono diventare così complessi che ci sono più interfacce per ogni componente. In questi casi, è sempre fondamentale garantire che tutti i componenti software funzionino perfettamente l'uno con l'altro.

• Il codice è troppo complesso per scopi di integrazione? - Se il processo di integrazione continua continua a fallire, potrebbe esserci la possibilità che il codice sia troppo complesso. E questo potrebbe essere un segnale per applicare modelli di progettazione adeguati per rendere il codice meno complesso e più gestibile.

• Il codice è conforme agli standard di codifica stabiliti? - La maggior parte dei casi di test verificherà sempre che il codice aderisca agli standard di codifica appropriati. Eseguendo un test automatico dopo la compilazione automatizzata, questo è un buon punto per verificare se il codice soddisfa tutti gli standard di codifica desiderati.

• Quanto codice è coperto dai test automatici? - Non ha senso testare il codice se i casi di test non coprono la funzionalità richiesta del codice. Quindi è sempre una buona pratica assicurarsi che i casi di test scritti coprano tutti gli scenari chiave dell'applicazione.

• Tutti i test hanno avuto esito positivo dopo l'ultima modifica? - Se un test fallisce, non ha senso procedere con la distribuzione del codice, quindi questo è un buon punto per verificare se il codice è pronto per passare alla fase di distribuzione o meno.

Flusso di lavoro

L'immagine seguente mostra un rapido flusso di lavoro del funzionamento dell'intero flusso di lavoro di integrazione continua in qualsiasi progetto di sviluppo software. Lo esamineremo in dettaglio nei capitoli successivi.

Quindi, in base al flusso di lavoro di cui sopra, questo è generalmente il modo in cui funziona il processo di integrazione continua.

• Innanzitutto, uno sviluppatore salva il codice nel repository di controllo della versione. Nel frattempo, il server Continuous Integration sulla macchina di compilazione dell'integrazione interroga il repository del codice sorgente per le modifiche (ad esempio, ogni pochi minuti).

• Subito dopo il commit, il server Continuous Integration rileva che sono state apportate modifiche nel repository di controllo della versione, quindi il server Continuous Integration recupera l'ultima copia del codice dal repository e quindi esegue uno script di build, che integra il software

• Il server Continuous Integration genera feedback inviando tramite posta elettronica i risultati della compilazione ai membri del progetto specificati.

• Gli unit test vengono quindi eseguiti se la build di quel progetto viene superata. Se i test hanno esito positivo, il codice è pronto per essere distribuito sul server di staging o di produzione.

• Il server Continuous Integration continua a eseguire il polling delle modifiche nel repository di controllo della versione e l'intero processo si ripete.

La parte software è l'aspetto più importante di qualsiasi processo di integrazione continua. Questo capitolo si concentra sul software che sarà necessario per l'intero processo di integrazione continua.

Repository del codice sorgente

Il repository del codice sorgente viene utilizzato per mantenere tutto il codice sorgente e tutte le modifiche apportate ad esso. I due più popolari per la gestione del repository del codice sorgente sono subversion e Git con Git che è il sistema popolare più recente. Vedremo ora come installare Git sul sistema.

Requisiti di sistema

Memoria	2 GB di RAM (consigliato)
Spazio sul disco	HDD da 200 MB per l'installazione. È richiesto spazio di archiviazione aggiuntivo per memorizzare il codice sorgente del progetto e questo dipende dal codice sorgente aggiunto.
Versione del sistema operativo	Può essere installato su Windows, Ubuntu / Debian, Red Hat / Fedora / CentOS, Mac OS X.

Installazione di Git

Step 1 - Il sito web ufficiale di Git è https://git-scm.com/. Se si fa clic sul collegamento, si accederà alla home page del sito Web ufficiale di Git, come mostrato nello screenshot seguente.

Step 2 - Per scaricare Git, scorri verso il basso sullo schermo e vai alla sezione Download e fai clic su Download.

Step 3 - Fare clic sul collegamento di Windows e il download per Git inizierà automaticamente.

Step 4- Fare clic sul file .exe scaricato per Git. Nel nostro caso, stiamo usando il file Git-2.6.1-64-bit.exe. Fare clic su Esegui che viene visualizzato nella schermata successiva.

Step 5 - Fare clic sul pulsante Avanti che appare nella schermata seguente.

Step 6 - Fare clic su Avanti nella schermata seguente per accettare il contratto di licenza generale.

Step 7 - Scegli la posizione per la tua installazione di Git.

Step 8 - Fare clic su Avanti per accettare i componenti predefiniti che devono essere installati.

Step 9 - Scegli l'opzione "Usa Git dal prompt dei comandi di Windows" poiché utilizzeremo Git da Windows.

Step 10 - Nella schermata seguente, accetta l'impostazione predefinita di "Checkout in stile Windows, conferma le terminazioni di riga in stile Unix" e fai clic su Avanti.

Step 11 - Nella schermata seguente, scegli l'opzione "Usa la finestra della console predefinita di Windows", poiché stiamo utilizzando Windows come sistema per l'installazione di Git.

L'installazione verrà ora avviata e sarà possibile seguire i passaggi successivi per configurare Git, una volta completata l'installazione.

Configurazione di Git

Una volta installato Git, è necessario eseguire i passaggi di configurazione per la configurazione iniziale di Git.

La prima cosa da fare è configurare l'identità in Git e quindi configurare un nome utente e un indirizzo email. Questo è importante perché ogni fileGit commitusa queste informazioni e sono immutabilmente incorporate nei commit che inizi a creare. È possibile farlo aprendo il prompt dei comandi e quindi immettere i seguenti comandi:

git config –global user.name “Username”
git config –global user.email “emailid”

Lo screenshot seguente è un esempio per una migliore comprensione.

Questi comandi cambieranno di conseguenza il file di configurazione di Git. Per assicurarti che le tue impostazioni abbiano effetto, puoi elencare le impostazioni del file di configurazione Git utilizzando il seguente comando.

git config --list

Un esempio dell'output è mostrato nella seguente schermata.

Server di integrazione continua

Il prossimo software cruciale richiesto per l'intera pipeline di integrazione continua è il software di integrazione continua stesso. Di seguito sono riportati i software di integrazione continua più comunemente utilizzati nel settore:

• Jenkins- Questo è un software di integrazione continua open source utilizzato da molte comunità di sviluppo.

• Jet Brains TeamCity - Questo è uno dei software commerciali di integrazione continua più popolari disponibili e la maggior parte delle aziende lo utilizza per le proprie esigenze di integrazione continua.

• Atlassian Bamboo- Questo è un altro popolare software di integrazione continua fornito da una società chiamata Atlassian Pvt. Ltd.

Tutti i software sopra menzionati funzionano sullo stesso modello per l'integrazione continua. Ai fini di questo tutorial, esamineremoJetbrains TeamCity per il server Continuous Integration.

Installazione di TeamCity

Di seguito sono riportati i passaggi ei requisiti di sistema per l'installazione di Jet Brains TeamCity sul tuo computer.

Requisiti di sistema

Memoria	4 GB di RAM (consigliato)
Spazio sul disco	HDD da 1 GB per l'installazione. È necessario spazio di archiviazione aggiuntivo per archiviare l'area di lavoro di compilazione per ogni progetto.
Versione del sistema operativo	Può essere installato su Windows, Linux, Mac OS X.

Installazione

Step 1 - Il sito web ufficiale di TeamCity èhttps://www.jetbrains.com/teamcity/. Se si fa clic sul collegamento fornito, si accederà alla home page del sito Web ufficiale di TeamCity, come mostrato nello screenshot seguente. È possibile sfogliare la pagina per scaricare il software richiesto per TeamCity.

Step 2 - Il file .exe scaricato viene utilizzato a scopo di esecuzione TeamCity-9.1.6.exe. Fare doppio clic sull'eseguibile e quindi fare clic su Esegui nella schermata successiva che si apre.

Step 3 - Fare clic su Avanti per avviare la configurazione.

Step 4 - Fare clic sul pulsante "Accetto" per accettare il contratto di licenza e procedere con l'installazione.

Step 5 - Scegli la posizione per l'installazione e fai clic su Avanti.

Step 6 - Scegli i componenti predefiniti per l'installazione e fai clic su Avanti

Questo avvierà il processo di installazione. Una volta completato, seguirà il processo di configurazione.

Step 7- Scegli un numero di porta per il server da eseguire. La cosa migliore è usare una porta diversa come8080.

Step 8- Successivamente chiederà quale account TeamCity deve essere eseguito. Scegli l'account SYSTEM e fai clic su Next.

Step 9- Successivamente richiederà i servizi che devono essere avviati. Accetta quelli predefiniti e quindi fai clic su Avanti.

Configurazione di TeamCity

Una volta completata l'installazione, il passaggio successivo è la configurazione di TeamCity. Questo software può essere aperto navigando sul seguente URL nel browser:

http://locahost:8080

Step 1- Il primo passo è fornire la posizione delle build, che saranno eseguite da TeamCity. Scegli la posizione desiderata e fai clic sul pulsante Procedi.

Step 2- Il passaggio successivo è specificare il database per archiviare tutti gli artefatti di TeamCity. Ai fini del tutorial, è possibile scegliere il fileInternal (HSQLDB), che è un database interno più adatto quando si utilizzano prodotti a scopo di test.

TeamCity elaborerà quindi tutti i passaggi necessari per renderlo operativo.

Step 3- Successivamente ti verrà chiesto di accettare il contratto di licenza. Accetta lo stesso e fai clic su Continua.

Step 4- È necessario creare un account amministratore che verrà utilizzato per accedere al software TeamCity. Immettere i dettagli richiesti e fare clic sul pulsante "Crea account".

Ora sarai connesso a TeamCity.

Lo strumento di costruzione

Lo strumento Build è uno strumento che garantisce che il programma sia costruito in un modo particolare. Lo strumento normalmente eseguirà un elenco di attività necessarie affinché il programma possa essere creato in modo corretto. Dal momento che nel nostro esempio, esamineremo un file.Net program , vedremo MSBuildcome strumento di costruzione. Lo strumento MSBuild esamina un file di compilazione che contiene un elenco di attività utilizzate per compilare il progetto. Diamo un'occhiata a un tipico file Build per un progetto di configurazione web.

Di seguito sono riportate le sezioni chiave del file Build, che devono essere considerate.

Impostazioni IIS

Le seguenti impostazioni vengono utilizzate per determinare qual è il numero di porta, qual è il percorso sul server Web e quale tipo di autenticazione è richiesto quando l'applicazione viene eseguita. Queste sono impostazioni importanti, che verranno modificate tramite il comando MSBuild quando apprenderemo come verrà eseguita la distribuzione più avanti nel tutorial.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPor>
<DevelopmentServerPort>61581</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:61581/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>

ItemGroup

Viene utilizzato per indicare al server di compilazione quali sono tutti i file binari dipendenti necessari per eseguire questo progetto.

<ItemGroup>
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />

<ItemGroup>
   <Compile Include = "App_Start\BundleConfig.cs" />
   <Compile Include = "App_Start\FilterConfig.cs" />

.Net Framework Version

Il TargetFrameworkVersionindica qual è la versione di .Net che deve essere presente affinché il progetto funzioni. Questo è assolutamente necessario perché se il server di compilazione non lo dispone, la compilazione fallirà.

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

Ambiente di distribuzione - Amazon

Ai fini di questo tutorial, garantiremo che il nostro server di integrazione continua abbia la capacità di distribuire la nostra applicazione su Amazon. Per questo, dobbiamo assicurarci che siano presenti i seguenti artefatti.

Server database

Eseguire i seguenti passaggi per assicurarsi che il server del database sia in Amazon per la distribuzione.

Step 1 - Vai alla console Amazon - https://aws.amazon.com/console/.

Accedi con le tue credenziali. Nota che puoi richiedere un ID gratuito sul sito Amazon, che ti consentirà di avere un livello gratuito che ti consente di utilizzare alcune delle risorse su Amazon gratuitamente.

Step 2 - Vai alla sezione RDS per creare il tuo database.

Step 3 - Fai clic su Istanze nella schermata successiva che si apre.

Step 4 - Fare clic su Launch DB opzione nella schermata successiva che viene visualizzata.

Step 5 - Scegli la scheda SQL Server, quindi scegli l'opzione Seleziona per SQL Server Express.

Step 6 - Assicurati di inserire i seguenti dettagli per confermare che stai utilizzando il livello gratuito di database disponibile da Amazon.

Step 7 - Fare clic sul pulsante Passaggio successivo una volta compilati tutti i campi.

Step 8 - Nella schermata successiva che viene visualizzata, accetta tutte le impostazioni predefinite e fai clic su Launch DB Instance.

Step 9- Ti verrà quindi presentata una schermata che dice che il DB è stato avviato con successo. Nella stessa pagina sarà presente un pulsante per visualizzare l'istanza database. Fare clic sul collegamento per visualizzare il fileDB Instance in fase di installazione.

Dopo un po 'di tempo, lo stato della schermata sopra cambierà per notificare che l'istanza database è stata creata correttamente.

Server web

Il prossimo passo è creare il tuo server web su Amazon, che ospiterà l'applicazione web. Questo può essere fatto seguendo i passaggi successivi per averlo a posto.

Step 1 - Vai alla console Amazon - https://aws.amazon.com/console/.

Accedi con le tue credenziali. Nota che puoi richiedere unfree id on the Amazon site, che ti consentirà di avere un livello gratuito che ti consentirà di utilizzare alcune delle risorse su Amazon gratuitamente.

Step 2 - Vai al EC2 section per creare il tuo server web.

Step 3 - Nella schermata successiva, fai clic su Avvia istanza.

Step 4 - Fare clic su Windows - Microsoft Windows Server 2010 R2 Base.

Step 5 - Scegli il file t2.microopzione, che fa parte del livello gratuito. ClicNext: Configure Instance Details.

Step 6 - Accetta le impostazioni predefinite nella schermata successiva che viene visualizzata, quindi scegli l'opzione Next: Add Storage.

Step 7 - Accetta le impostazioni predefinite nella schermata successiva e scegli l'opzione Next: Tag Instance.

Step 8 - Accetta le impostazioni predefinite nella schermata successiva e scegli l'opzione di Next: Configure Security Group.

Step 9 - Accetta le impostazioni predefinite nella schermata successiva e scegli l'opzione di Review and Launch.

Step 10 - Fare clic su Avvia nella schermata successiva che viene visualizzata.

Step 11- Nella schermata successiva che viene visualizzata, ti verrà chiesto di creare una coppia di chiavi. Questo verrà utilizzato per accedere al server in un secondo momento. Basta creare la coppia di chiavi e fare clicLaunch Instance.

L'istanza verrà ora configurata in Amazon.

Ci sono possibilità che le cose vadano storte in un progetto. Praticando efficacemente CI, scopri cosa succede ad ogni passo lungo il percorso, piuttosto che in seguito, quando il progetto è nel ciclo di sviluppo. CI ti aiuta a identificare e mitigare i rischi quando si verificano, rendendo più facile valutare e riferire sullo stato di salute del progetto sulla base di prove concrete.

Questa sezione si concentrerà sui rischi che possono essere evitati utilizzando l'integrazione continua.

In qualsiasi progetto, ci sono molti rischi che devono essere gestiti. Eliminando i rischi nelle prime fasi del ciclo di vita dello sviluppo, ci sono minori possibilità che questi rischi si trasformino in problemi in seguito, quando il sistema diventa effettivamente operativo.

Rischio 1 - Mancanza di software distribuibile

“It works on my machine but does not work on another”- Questa è probabilmente una delle frasi più comuni riscontrate in qualsiasi organizzazione di software. A causa del numero di modifiche apportate quotidianamente alle build del software, a volte c'è poca fiducia sul fatto che la build del software funzioni effettivamente o meno. Questa preoccupazione ha i seguenti tre effetti collaterali.

• Poca o nessuna fiducia nella possibilità di costruire il software.

• Lunghe fasi di integrazione prima della consegna del software internamente (es. Team di test) o esternamente (es. Cliente), durante le quali non viene fatto nient'altro.

• Incapacità di produrre e riprodurre build testabili.

Soluzione

Eliminazione dello stretto accoppiamento tra IDE e processi di compilazione. Utilizzare una macchina separata esclusivamente per l'integrazione del software. Assicurati che tutto ciò di cui hai bisogno per creare il software sia contenuto nel repository di controllo della versione. Infine, crea un sistema di integrazione continua.

Il server Continuous Integration può controllare le modifiche nel repository di controllo della versione ed eseguire lo script di compilazione del progetto quando rileva una modifica al repository. La capacità del sistema di integrazione continua può essere aumentata per includere la compilazione di eseguire test, eseguire ispezioni e distribuire il software negli ambienti di sviluppo e test; in questo modo hai sempre un software funzionante.

“Inability to synchronize with the database”- A volte gli sviluppatori non sono in grado di ricreare rapidamente il database durante lo sviluppo e quindi trovano difficile apportare modifiche. Spesso ciò è dovuto a una separazione tra il team del database e il team di sviluppo. Ogni squadra sarà concentrata sulle proprie responsabilità e avrà poca collaborazione tra di loro. Questa preoccupazione ha i seguenti tre effetti collaterali:

• Paura di apportare modifiche o refactoring del database o del codice sorgente.

• Difficoltà nel popolare il database con diversi set di dati di test.

• Difficoltà nel mantenere gli ambienti di sviluppo e test (ad es. Sviluppo, Integrazione, QA e Test).

Soluzione

La soluzione al problema precedente è garantire che il posizionamento di tutti gli artefatti del database nel repository di controllo della versione venga eseguito. Ciò significa tutto ciò che è necessario per ricreare lo schema e i dati del database: sono necessari script di creazione del database, script di manipolazione dei dati, stored procedure, trigger e qualsiasi altra risorsa del database.

Ricostruisci il database ei dati dal tuo script di compilazione, rilasciando e ricreando il tuo database e le tabelle. Successivamente, applica le stored procedure e i trigger e, infine, inserisci i dati di test.

Testa (e ispeziona) il tuo database. In genere, utilizzerai i test dei componenti per testare il database ei dati. In alcuni casi, dovrai scrivere test specifici del database.

Rischio 2 - Scoperta di difetti nelle ultime fasi del ciclo di vita

Poiché ci sono così tante modifiche che avvengono frequentemente da più sviluppatori al codice sorgente, ci sono sempre possibilità che un difetto possa essere introdotto nel codice che potrebbe essere rilevato solo in una fase successiva. In questi casi, ciò può causare un grande impatto perché più tardi il difetto viene rilevato nel software, più costoso diventa rimuovere il difetto.

Soluzione

Regression Testing- Questo è l'aspetto più importante di qualsiasi ciclo di sviluppo software, test e test di nuovo. In caso di modifiche importanti al codice del software, è assolutamente obbligatorio assicurarsi che tutti i test vengano eseguiti. E questo può essere automatizzato con l'aiuto del server Continuous Integration.

Test Coverage- Non ha senso eseguire il test se i casi di test non coprono l'intera funzionalità del codice. È importante assicurarsi che i test case creati per testare l'applicazione siano completi e che tutti i percorsi del codice siano testati.

Ad esempio, se si dispone di una schermata di accesso che deve essere testata, non è possibile disporre di uno scenario di test con lo scenario di un accesso riuscito. È necessario disporre di un test case negativo in cui un utente immette una diversa combinazione di nomi utente e password e quindi è necessario vedere cosa succede in tali scenari.

Rischio 3 - Mancanza di visibilità del progetto

I meccanismi di comunicazione manuale richiedono molto coordinamento per garantire la diffusione delle informazioni sul progetto alle persone giuste in modo tempestivo. Appoggiarsi allo sviluppatore accanto a te e fargli sapere che l'ultima build è sul Drive condiviso è piuttosto efficace, ma non si adatta molto bene.

E se ci sono altri sviluppatori che hanno bisogno di queste informazioni e sono in pausa o altrimenti non disponibili? Se un server non funziona, come vieni avvisato? Alcuni credono di poter mitigare questo rischio inviando manualmente un'e-mail. Tuttavia, ciò non può garantire che le informazioni vengano comunicate alle persone giuste al momento giusto perché potresti accidentalmente escludere le parti interessate e alcuni potrebbero non avere accesso alla loro posta elettronica in quel momento.

Soluzione

La soluzione a questo problema è di nuovo il server Continuous Integration. Tutti i server CI hanno la possibilità di avere email automatiche da attivare ogni volta che le build falliscono. Con questa notifica automatica a tutte le principali parti interessate, è inoltre garantito che tutti siano a bordo di quello che è lo stato attuale del software.

Rischio 4 - Software di bassa qualità

Ci sono difetti e poi ci sono potenziali difetti. Si possono presentare potenziali difetti quando il software non è ben progettato o se non segue gli standard del progetto o è complesso da mantenere. A volte le persone si riferiscono a questo come a odori di codice o di progettazione: "un sintomo che qualcosa potrebbe essere sbagliato".

Alcuni credono che il software di qualità inferiore sia solo un costo del progetto differito (dopo la consegna). Può essere un costo del progetto differito, ma porta anche a molti altri problemi prima di consegnare il software agli utenti. Codice eccessivamente complesso, codice che non segue l'architettura e codice duplicato: tutti di solito portano a difetti nel software. Trovare questi odori di codice e di progettazione prima che si manifestino in difetti può far risparmiare tempo e denaro e può portare a software di qualità superiore.

Soluzione

Ci sono componenti software per eseguire un controllo di qualità del codice che può essere integrato con il software CI. Questo può essere eseguito dopo che il codice è stato creato per garantire che il codice sia effettivamente conforme alle linee guida di codifica appropriate.

I sistemi di controllo della versione, noti anche come controllo del codice sorgente, sistemi di gestione del codice sorgente o sistemi di controllo di revisione, sono un meccanismo per mantenere più versioni dei file, in modo che quando si modifica un file è ancora possibile accedere alle revisioni precedenti.

Il primo popolare sistema di controllo della versione era uno strumento UNIX proprietario chiamato SCCS(Source Code Control System) che risale agli anni '70. Questo è stato sostituito daRCS, il sistema di controllo delle revisioni e versioni successive CVS, Sistema di versioni simultanee.

Ora il sistema di controllo della versione più popolare utilizzato è Subversion e Git. Diamo prima un'occhiata al motivo per cui abbiamo bisogno di utilizzare un sistema di controllo delle versioni e successivamente diamo un'occhiata a inserire il nostro codice sorgenteGit source code repository system.

Scopo del sistema di controllo della versione

Uno dei motivi per cui usiamo il termine controllo della versione rispetto al controllo del codice sorgente è che il controllo della versione non è solo per il codice sorgente. Ogni singolo artefatto relativo alla creazione del software dovrebbe essere sotto il controllo della versione.

Developers should use it for source code - Per impostazione predefinita, tutto il codice sorgente deve essere memorizzato nel sistema di controllo delle versioni

Related artefacts- Ogni sistema avrebbe artefatti correlati al codice sorgente come script di database, script di compilazione e distribuzione, documentazione, librerie e file di configurazione per l'applicazione, il compilatore e la raccolta di strumenti e così via. Tutti questi completano l'intero processo di sviluppo e distribuzione e devono anche essere archiviati nel sistema di controllo delle versioni.

Archiviando tutte le informazioni per l'applicazione nel controllo del codice sorgente, diventa più semplice ricreare gli ambienti di test e produzione in cui viene eseguita l'applicazione. Ciò dovrebbe includere le informazioni di configurazione per lo stack software dell'applicazione e i sistemi operativi che compongono l'ambiente, i file di zona DNS, la configurazione del firewall e così via.

Come minimo, hai bisogno di tutto il necessario per ricreare i file binari dell'applicazione e gli ambienti in cui vengono eseguiti. L'obiettivo è quello di avere tutto ciò che può eventualmente cambiare in qualsiasi momento della vita del progetto memorizzato in modo controllato. Ciò consente di recuperare un'istantanea esatta dello stato dell'intero sistema, dall'ambiente di sviluppo all'ambiente di produzione, in qualsiasi punto della cronologia del progetto.

È anche utile mantenere i file di configurazione per gli ambienti di sviluppo del team di sviluppo nel controllo della versione poiché rende facile per tutti i membri del team utilizzare le stesse impostazioni. Gli analisti dovrebbero archiviare i documenti dei requisiti. I tester dovrebbero mantenere i propri script e procedure di test nel controllo della versione. I project manager dovrebbero salvare i loro piani di rilascio, grafici di avanzamento e registri dei rischi qui.

In breve, ogni membro del team dovrebbe archiviare qualsiasi documento o file relativo al progetto nel controllo della versione.

Lavorare con Git per il sistema di controllo delle versioni del codice sorgente

Questa sezione si concentrerà ora su come Git può essere utilizzato come sistema di controllo delle versioni. Si concentrerà su come caricare il codice nel sistema di controllo delle versioni e gestirne le modifiche.

La nostra applicazione demo

Ai fini di questo intero tutorial esamineremo un semplice file Web ASP.Netapplicazione che verrà utilizzata per l'intero processo di integrazione continua. Non è necessario concentrarsi sugli interi dettagli del codice per questo esercizio, solo avere una panoramica di ciò che fa il progetto è sufficiente per comprendere l'intero processo di integrazione continua. Questa applicazione .Net è stata creata utilizzando l'estensioneVisual Studio Integrated Development Environment.

Lo screenshot seguente è la struttura della soluzione nell'ambiente di Visual Studio. È un'applicazione Web molto semplice che ha il codice principale inDemo.aspx file.

Il codice nel file Demo.aspx è mostrato nel seguente programma:

<html xmlns = "http://www.w3.org/1999/xhtml">
   <head runat = "server">
      <title>TutorialsPoint</title>
   </head>
   
   <body>
      <form id = "form1" runat="server">
         <div><%Response.Write("Continuous Integration"); %></div>
      </form>
   </body>
   
</html>

Il codice è molto semplice e invia semplicemente la stringa "Integrazione continua" al browser.

Quando esegui il progetto in Google Chrome, l'output sarà come mostrato nello screenshot seguente.

Spostamento del codice sorgente in Git

Mostreremo come spostare il codice sorgente su Git dall'interfaccia della riga di comando, in modo che la conoscenza di come Git possa essere utilizzato sia più chiara per l'utente finale.

Step 1 - Inizializza il file Git Repository. Vai al prompt dei comandi, vai alla cartella del tuo progetto ed esegui il comandogit init. Questo comando aggiungerà i file Git necessari alla cartella del progetto, in modo che possa essere riconosciuto da Git quando deve essere caricato nel repository.

Step 2- Aggiunta dei file che devono essere aggiunti al repository Git. Questo può essere fatto emettendo ilgit add command. L'opzione punto indica a Git che tutti i file nella cartella del progetto devono essere aggiunti al repository Git.

Step 3- Il passaggio finale consiste nel salvare i file di progetto nel repository Git. Questo passaggio è necessario per garantire che tutti i file facciano ora parte di Git. Il comando da impartire è riportato nella seguente schermata. Il–m option è fornire un commento al caricamento dei file.

La tua soluzione è ora disponibile in Git.

Di seguito sono riportate alcune delle principali caratteristiche o pratiche per l'integrazione continua.

• Maintain a single source repository- Tutto il codice sorgente è mantenuto in un unico repository. Ciò evita che il codice sorgente venga disperso in più posizioni. Strumenti comeSubversion and Git sono gli strumenti più popolari per mantenere il codice sorgente.

• Automate the build- La creazione del software deve essere eseguita in modo tale da poter essere automatizzata. Se sono necessari più passaggi, lo strumento di compilazione deve essere in grado di farlo. Per .Net, MSBuild è lo strumento di compilazione predefinito e per le applicazioni basate su Java hai strumenti comeMaven and Grunt.

• Make your build self-testing- La build dovrebbe essere testabile. Subito dopo la compilazione, è necessario eseguire casi di test per garantire che sia possibile eseguire il test per le varie funzionalità del software.

• Every commit should build on an integration machine- La macchina di integrazione è il server di build e dovrebbe essere garantito che la build venga eseguita su questa macchina. Ciò significa che tutti i componenti dipendenti dovrebbero esistere sul server Continuous Integration.

• Keep the build fast- La costruzione dovrebbe avvenire in pochi minuti. La compilazione non dovrebbe richiedere ore perché ciò significhi che i passaggi di compilazione non sono configurati correttamente.

• Test in a clone of the production environment- L'ambiente di costruzione dovrebbe essere simile per natura all'ambiente di produzione. Se sono presenti notevoli differenze tra questi ambienti, è possibile che la compilazione non riesca in produzione anche se passa al server di compilazione.

• Everyone can see what is happening - L'intero processo di creazione, test e distribuzione dovrebbe essere visibile a tutti.

• Automate deployment- L'integrazione continua porta alla distribuzione continua. È assolutamente necessario garantire che la build sia facile da distribuire in un ambiente di staging o di produzione.

Di seguito è riportato l'elenco dei requisiti più significativi per l'integrazione continua.

• Check-In Regularly- La pratica più importante per il corretto funzionamento dell'integrazione continua è costituita dai frequenti check-in nel trunk o nella linea principale del repository del codice sorgente. Il check-in del codice dovrebbe avvenire almeno un paio di volte al giorno. Fare regolarmente il check-in porta molti altri vantaggi. Rende le modifiche più piccole e quindi meno probabilità di rompere la build. Significa che la versione più recente del software a cui ripristinare è nota quando viene commesso un errore in una build successiva.

  Aiuta anche ad essere più disciplinato nel refactoring del codice e ad attenersi a piccoli cambiamenti che preservano il comportamento. Aiuta a garantire che le modifiche che alterano molti file abbiano meno probabilità di entrare in conflitto con il lavoro di altre persone. Consente agli sviluppatori di essere più esplorativi, provando idee e scartandole tornando all'ultima versione impegnata.

• Create a Comprehensive Automated Test Suite- Se non si dispone di una suite completa di test automatizzati, una build passata significa solo che l'applicazione può essere compilata e assemblata. Sebbene per alcuni team questo sia un grande passo, è essenziale disporre di un certo livello di test automatizzati per fornire la certezza che l'applicazione funzioni effettivamente.

  Normalmente, ci sono 3 tipi di test condotti in Continuous Integration, vale a dire unit tests, component tests, e acceptance tests.

  Gli unit test vengono scritti per testare il comportamento di piccole parti dell'applicazione in isolamento. Di solito possono essere eseguiti senza avviare l'intera applicazione. Non raggiungono il database (se la tua applicazione ne ha uno), il filesystem o la rete. Non richiedono che l'applicazione venga eseguita in un ambiente simile alla produzione. I test unitari dovrebbero essere eseguiti molto velocemente: l'intera suite, anche per un'applicazione di grandi dimensioni, dovrebbe essere in grado di essere eseguita in meno di dieci minuti.

  I test dei componenti verificano il comportamento di diversi componenti dell'applicazione. Come gli unit test, non richiedono sempre l'avvio dell'intera applicazione. Tuttavia, possono colpire il database, il filesystem o altri sistemi (che potrebbero essere bloccati). I test dei componenti in genere richiedono più tempo per essere eseguiti.

• Keep the Build and Test Process Short - Se la compilazione del codice e l'esecuzione degli unit test impiegano troppo tempo, si verificheranno i seguenti problemi.

  • Le persone smetteranno di eseguire una compilazione completa ed eseguiranno i test prima del check-in. Inizierai a ottenere più build fallimentari.

  • Il processo di integrazione continua richiederà così tanto tempo che nel momento in cui sarà possibile eseguire nuovamente la compilazione sarebbero stati eseguiti più commit, quindi non saprai quale check-in ha interrotto la compilazione.

  • Le persone effettueranno il check-in meno spesso perché devono sedersi per anni in attesa che il software venga creato e che i test vengano eseguiti.

• Don’t Check-In on a Broken Build- Il più grande errore dell'integrazione continua è il check-in su una build non funzionante. Se la build si interrompe, gli sviluppatori responsabili stanno aspettando di risolverlo. Identificano la causa della rottura il prima possibile e la risolvono. Se adottiamo questa strategia, saremo sempre nella posizione migliore per capire cosa ha causato la rottura e ripararla immediatamente.

  Se uno dei nostri colleghi ha effettuato un check-in e di conseguenza ha rotto la build, per avere le migliori possibilità di risolverlo, avrà bisogno di una chiara analisi del problema. Quando questa regola viene infranta, inevitabilmente ci vuole molto più tempo per correggere la build. Le persone si abituano a vedere la build danneggiata e molto rapidamente ti trovi in ​​una situazione in cui la build rimane sempre danneggiata.

• Always Run All Commit Tests Locally Before Committing- Assicurarsi sempre che i test progettati per l'applicazione vengano eseguiti prima su una macchina locale prima di eseguirli sul server CI. Questo per garantire che vengano scritti i casi di test corretti e se si verifica un errore nel processo CI, è a causa dei risultati del test non riusciti.

• Take Responsibility for All Breakages that Result from Your Changes- Se si esegue il commit di una modifica e tutti i test scritti vengono superati, ma altri si interrompono, la build è comunque danneggiata. Di solito questo significa che hai introdotto un bug di regressione nell'applicazione. È tua responsabilità, poiché hai apportato la modifica, correggere tutti i test che non vengono superati a seguito delle modifiche. Nel contesto della CI questo sembra ovvio, ma in realtà non è una pratica comune in molti progetti.

Sono disponibili numerosi strumenti di compilazione per una varietà di linguaggi di programmazione. Alcuni degli strumenti di compilazione più popolari includonoAnt for Java e MSBuild for .NET. L'utilizzo di uno strumento di scripting progettato specificamente per la creazione di software, invece di un set personalizzato di script shell o batch, è il modo più efficace per sviluppare una soluzione di compilazione coerente e ripetibile.

Allora perché abbiamo bisogno di un processo di compilazione per iniziare. Per i principianti, per un server di integrazione continua, il processo di compilazione dovrebbe essere facile da lavorare e dovrebbe essere semplice da implementare.

Facciamo un semplice esempio di come può apparire un file di build per .Net -

<?xml version = "1.0" encoding = "utf-8"?>
<project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
   <Target Name = "Build">
      <Message Text = "Building Project" />
      <MSBuild Projects = "project.csproj" Targets = "Build/>"
   </Target>
</project>

I seguenti aspetti devono essere annotati sul codice di cui sopra:

• Un target viene specificato con un nome di Build. In cui, un obiettivo è una raccolta di passaggi logici che devono essere eseguiti in un processo di compilazione. Puoi avere più destinazioni e avere dipendenze tra le destinazioni.

• Nel nostro target, manteniamo un messaggio di opzione che verrà mostrato all'avvio del processo di compilazione.

• Il MSBuild task viene utilizzato per specificare quale progetto .Net deve essere costruito.

L'esempio sopra è un caso di un file di build molto semplice. In Continuous Integration, è garantito che questo file sia mantenuto aggiornato per garantire che l'intero processo di compilazione sia fluido.

Costruire una soluzione in .Net

Lo strumento di compilazione predefinito per .Net è MSBuild ed è fornito con il framework .Net. A seconda del framework del sistema, sarà disponibile la versione di MSbuild pertinente. Ad esempio, se hai il framework .Net installato nella posizione predefinita, troverai ilMSBuild.exe file nella seguente posizione:

C:\Windows\Microsoft.NET\Framework\v4.0.30319

Vediamo come possiamo realizzare il nostro progetto di esempio. Supponiamo che il nostro progetto di esempio si trovi in ​​una cartella chiamataC:\Demo\Simple.

Per poter utilizzare MSBuild per creare la soluzione precedente, è necessario aprire il prompt dei comandi e utilizzare l'opzione MSBuild come mostrato nel programma seguente.

msbuild C:\Demo\Simple\Simple.csproj

Nell'esempio sopra, csprojè il file di progetto specifico di .Net. Il file csproj contiene tutte le informazioni rilevanti per garantire che le informazioni richieste siano presenti affinché il software possa essere creato correttamente. Di seguito è riportato lo screenshot dell'output del comando MSBuild.

Non è necessario preoccuparsi degli avvisi di output fintanto che la compilazione ha avuto esito positivo e non sono stati rilevati errori.

Ora esaminiamo alcuni aspetti del file MSBuild per vedere cosa significano. Questi aspetti sono importanti da conoscere da un ciclo di integrazione continua.

Gli script di compilazione vengono utilizzati per creare la soluzione che farà parte dell'intero ciclo di integrazione continua. Diamo un'occhiata allo script di compilazione generale creato come parte di Visual Studio in.Netper la nostra soluzione campione. Lo script di compilazione è piuttosto grande, anche per una soluzione semplice, quindi ne esamineremo le parti più importanti. Per impostazione predefinita, lo script di compilazione verrà archiviato in un file con lo stesso nome della soluzione principale in Visual Studio. Quindi nel nostro caso, se apri il fileSimple.csproj, vedrai tutte le impostazioni che verranno utilizzate per creare la soluzione.

• Dipendenza dalla versione di MSBuild utilizzata: le seguenti impostazioni useranno i file di MSBuild installati nel server CI.

<VisualStudioVersion Condition = "'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> <VSToolsPath Condition = "'$(VSToolsPath)' == ''"> 
   $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)
</VSToolsPath>

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

<Import Project = "$(MSBuildBinPath)\Microsoft.CSharp.targets" /> <Import Project = "$(VSToolsPath)\WebApplications\
   Microsoft.WebApplication.targets" Condition = "'$(VSToolsPath)' ! = ''" /> <Import Project = "$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\
   WebApplications\Microsoft.WebApplication.targets" Condition = "false" />

• Quali file sono necessari per creare correttamente la soluzione: il file ItemGrouptag conterrà tutti i file .Net necessari che sono richiesti per la corretta compilazione del progetto. Questi file dovranno risiedere di conseguenza sul server di compilazione.

<ItemGroup>
   <Reference Include = "Microsoft.CSharp" />
   <Reference Include = "System.Web.DynamicData" />
   <Reference Include = "System.Web.Entity" />
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />
   <Reference Include = "System" />
   <Reference Include = "System.Data" />
   <Reference Include = "System.Core" />
   <Reference Include = "System.Data.DataSetExtensions" />
   <Reference Include = "System.Web.Extensions" />
   <Reference Include = "System.Xml.Linq" />
   <Reference Include = "System.Drawing" />
   <Reference Include = "System.Web" />
   <Reference Include = "System.Xml" />
   <Reference Include = "System.Configuration" />
   <Reference Include = "System.Web.Services" />
   <Reference Include = "System.EnterpriseServices"/>
</ItemGroup>

• Quali sono le impostazioni del server Web da utilizzare - Quando visitiamo il nostro argomento di distribuzione continua, vedrai come MSBuild verrà utilizzato per sovrascrivere queste impostazioni e distribuirle al nostro server preferito.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl></IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>

Il passaggio successivo importante è garantire che la soluzione si basi sul server di compilazione. La prima parte è un passaggio manuale, perché prima di utilizzare lo strumento di integrazione continua, dobbiamo prima assicurarci che la compilazione venga eseguita sul server di compilazione nello stesso modo di quanto è stato fatto sulla macchina client. Per fare ciò, dobbiamo implementare i seguenti passaggi:

Step 1- Copiare l'intero file della soluzione sul server. Avevamo creato un server di istanze Amazon che sarebbe stato utilizzato come nostro server di compilazione. Quindi, fai una copia manuale sul server dell'intero file.Net soluzione sul server.

Step 2- Assicurati che il framework sia presente sul server. Se hai compilato la tua applicazione in .Net framework 4.0 sulla tua macchina client, devi assicurarti che sia installata anche sulla macchina server. Quindi vai alla posizioneC:\Windows\Microsoft.NET\Framework sul tuo server e assicurati che sia presente il framework desiderato.

Step 3 - Ora eseguiamo MSBuild sul server e vediamo cosa succede.

Ok, sembra che abbiamo riscontrato un errore. C'è una lezione importante sull'integrazione continua ed è che devi assicurarti che Build funzioni sul server di build. Per questo è necessario assicurarsi che tutto il software prerequisito sia installato sul server di compilazione.

Per .Net, dobbiamo installare un componente chiamato Visual Studio Redistributable package. Questo pacchetto contiene tutti i file necessari che sono richiesti per un file.Netapplicazione da costruire su un server. Quindi eseguiamo i seguenti passaggi di installazione sul server di compilazione.

Step 4 - Fare doppio clic sul file eseguibile per avviare l'installazione.

Step 5 - Nel passaggio successivo, accetta i Termini di licenza e fai clic su Installa.

Step 6 - Ora, quando si esegue MSBuild, è necessario assicurarsi di includere un parametro aggiuntivo quando si chiama MSBuild che è: p:VisualStudioversion = 12.0. Ciò garantisce che MSBuild faccia riferimento ai file scaricati nel passaggio precedente.

Ora possiamo vedere che la soluzione è stata costruita correttamente e sappiamo anche che il nostro progetto di base viene compilato correttamente sul server.

Il prossimo aspetto chiave è garantire che il nostro codice di base sia archiviato nel nostro server di gestione del repository di codice sorgente che è Git. Per fare ciò, dobbiamo seguire questi passaggi.

Step 1- Inizializza il repository in modo che possa essere caricato su Git. Questo viene fatto con ilgitcomando init. Quindi devi andare nella cartella del tuo progetto ed emettere il filegit init comando.

Step 2- Il passaggio successivo è chiamato file di staging in Git. Questo prepara tutti i file nella cartella del progetto, che devono essere aggiunti a Git. Lo fai con ilgit addcomando come mostrato nello screenshot seguente. Il '.' la notazione è usata per dire che tutti i file nella directory e sottodirectory devono essere inclusi nel commit.

Step 3 - Il passaggio finale è eseguire il commit dei file nel repository Git, in modo che ora sia un repository Git a tutti gli effetti.

Ora che abbiamo il nostro codice sorgente nel repository Git e tutto il nostro codice iniziale funziona sul server di compilazione, è il momento di creare un progetto nel nostro server Continuous Integration. Questo può essere fatto tramite i seguenti passaggi:

Step 1- Accedi al software TeamCity. Vai all'URL sul tuo server Continuous Integration -http://localhost:8080/login.html.

Immettere le credenziali di amministratore e accedere al server.

Step 2- Una volta effettuato l'accesso, ti verrà presentata la schermata principale. ClicCreate Project per iniziare un nuovo progetto.

Step 3- Assegna un nome al progetto e fai clic su Crea per avviare il progetto. Nel nostro caso, diamo il nome "Demo" al nostro progetto, come mostrato nello screenshot seguente.

Step 4- Il passo successivo è menzionare il repository Git che verrà utilizzato nel nostro progetto. Ricorda che in un ambiente di integrazione continua, il server CI deve prelevare il codice dal repository abilitato per Git. Abbiamo già abilitato la nostra cartella del progetto per essere un repository abilitato per Git nel passaggio precedente. In TeamCity, devi creare una radice VCS. Per questo, fare clic suVCS Roots nella schermata principale del progetto.

Step 5 - Nella schermata successiva, fare clic su Create VCS root come mostrato nello screenshot seguente.

Step 6 - Nella schermata successiva che viene visualizzata, eseguire i seguenti passaggi:

• Indica il tipo di VCS come Git.

• Assegna un nome alla radice VCS, può essere un nome descrittivo. Abbiamo dato il nome comeApp.

• Assegna l'URL di recupero come C:\Demo\Simple - Questo è out git repository abilitato.

• Se scorri lo schermo verso il basso, otterrai un pulsante Verifica connessione. Fai clic per assicurarti di poterti connettere correttamente al repository abilitato per Git.

Step 7 - Fai clic su Crea e ora vedrai il tuo repository registrato come mostrato nell'immagine seguente.

Step 8- Il passaggio successivo consiste nel creare una configurazione di build che verrà utilizzata per creare il progetto. Vai alla schermata del tuo progetto inTeamCity → General Settings. Fare clic su Crea configurazione build.

Step 9- Nella schermata seguente, assegna un nome alla configurazione build. Nel nostro caso lo abbiamo chiamato comeDemoBuild e quindi fare clic su Crea.

Step 10 - Nella schermata successiva che viene visualizzata, ti verrà chiesto di scegliere il file VCS repositorycreato nei passaggi precedenti. Quindi scegli il nome‘App’ e fare clic su Allega.

Step 11- Ora nella schermata successiva che si apre, dobbiamo configurare i passaggi di creazione. Quindi fai clic su "configure build steps manually'collegamento ipertestuale.

Step 12 - Nella prossima schermata di build, dobbiamo inserire i seguenti dettagli -

• Scegli il tipo di Runner come MSBuild.

• Assegnare un nome opzionale al nome del passaggio.

• Dare il nome del file che deve essere creato. Quando specifichiamo MSbuild nelle sezioni precedenti, normalmente vediamo che diamo la possibilità diSimple.csproj. La stessa cosa è necessaria per essere specificata qui.

• Scegli la versione di MSBuild come "Microsoft Build Tools 2013".

• Scegli il MSBuild ToolsVersion come 12.0.

• Scorri la pagina verso il basso per salvare le impostazioni.

Step 13 - Nella schermata successiva, fai clic su Esegui.

Ora vedrai la build della tua applicazione in corso.

Dovresti ottenere una schermata di successo, il che è un buon segno che la tua soluzione sta costruendo correttamente.

Puoi anche andare al tuo registro di build per vedere tutti i passaggi che sono stati coperti dal server Continuous Integration, come mostrato nello screenshot seguente.

Ora che abbiamo il nostro codice di base in Git e un collegamento al server Continuous Integration, è finalmente giunto il momento di vedere il primo passo dell'integrazione continua in azione. Questo viene fatto definendo le attività nel server Continuous Integration come i trigger, il che rende l'intero Processo di Continuous Integration il più fluido possibile. Apportiamo una modifica al nostro codice in Visual Studio.

Step 1 - Vai al Demo.aspx pagina in Visual Studio e apportare una modifica al titolo della pagina.

Step 2 - Se interroghiamo il nostro repository Git tramite git status si vedrà infatti che il Demo.aspx il file è stato modificato.

Ora dobbiamo assicurarci che ogni modifica nel nostro codice attivi una build nel nostro server di integrazione continua. Per questo dobbiamo fare le seguenti modifiche.

Step 3 - Vai alla dashboard del tuo progetto e fai clic sulla sezione dei trigger e fai clic su Add new trigger.

Step 4 - Nella schermata successiva che viene visualizzata, scegli VCS trigger, che verrà utilizzato per creare un trigger in modo che quando viene effettuato un check-in nel repository, verrà attivata una build.

Step 5 - Fare clic su Show Advanced Options e assicurati che le opzioni mostrate nella seguente schermata siano selezionate.

Step 6- Fare clic su Salva. Ora vedrai il trigger registrato correttamente come mostrato nello screenshot seguente.

Step 7- Ora è il momento di controllare il nostro codice nel repository Git e vedere cosa succede. Quindi andiamo al nostro prompt dei comandi e rilasciamo il filegit add comando per mettere in scena i nostri file modificati.

Step 8 - Ora emetti il ​​file git commit comando e inserirà le modifiche nel repository Git.

Step 9 - Se ora vai alla schermata Panoramica dei progetti, vedrai che una nuova build sarebbe stata attivata ed eseguita.

Se vedi il file Change log Tab, vedrai il file git comment che ha attivato la compilazione.

Proviamolo ancora una volta. Apportiamo un'altra modifica al fileDemo.aspxfile. Eseguiamo un filegit add comando e a git commit comando con il seguente messaggio di commit.

Ora vedrai una build attivata automaticamente nella dashboard del progetto in TeamCity.

La build mostrerà un messaggio di successo.

Ora vedrai il messaggio di "Secondo commit" che è stato utilizzato quando la modifica è stata salvata in git repository.

Abbiamo ora completato con successo la prima parte del processo di integrazione continua.

Una notifica di errore di compilazione è un evento che viene attivato ogni volta che una compilazione non riesce. La notifica viene inviata a tutte le persone chiave ogni volta che una build non riesce. La prima cosa importante da fare in questo caso è assicurarsi che il tempo venga speso per la compilazione non riuscita per garantire che la compilazione sia passata. I seguenti passaggi vengono utilizzati per garantire che le notifiche di build siano messe in atto in TeamCity.

Di seguito sono riportati i passaggi per impostare le notifiche e-mail in TeamCity.

Step 1- In TeamCity, vai alla dashboard del tuo progetto, fai clic su Amministrazione nell'angolo in alto a destra. Vedrai quindi il fileEmail Notifiercollegamento sul lato sinistro. Fare clic su questo collegamento per visualizzare le impostazioni generali per l'email.

Step 2 - Il prossimo passo è inserire i dettagli di un valido SMTP Server. Gmail fornisce una funzione SMTP gratuita, che può essere utilizzata da chiunque. Quindi possiamo inserire quei dettagli nella schermata successiva che appare come mostrato nello screenshot seguente.

• Host SMTP: smtp.gmail.com
• N. porta SMTP - 465
• Invia messaggi di posta elettronica da e accesso SMTP: dovrebbe essere un ID Gmail valido
• Password SMTP: password valida per quell'ID Gmail
• Connessione sicura: inseriscilo come SSL

Step 3 - Fare clic su Test Connectionsolo per garantire che le impostazioni funzionino correttamente. Quindi fare clic suSave per salvare le impostazioni.

Step 4- Il passaggio successivo è abilitare le notifiche di build per un utente. La prima attività è creare un utente che riceverà queste notifiche di build. Vai alla dashboard del tuo progetto e scegli il fileUsers Option.

Step 5- Crea un nuovo utente. Immettere il nome utente e la password richiesti. Quindi fare clic sul pulsante Crea utente, che si troverà nella parte inferiore dello schermo.

Step 6 - Ora accedi al sistema TeamCity con questo nuovo ID utente e password.

Step 7- Dopo aver effettuato l'accesso, ti verranno presentate le impostazioni generali dell'utente. Nella sezione Email Notifier, fai clic su Modifica.

Step 8 - Nella schermata successiva che viene visualizzata, fare clic su Add new rule.

Step 9 - In Aggiungi nuova regola, scegli le seguenti due opzioni e fai clic su Salva.

• Build da progetti selezionati: scegli il progetto Demo.

• Abilita la casella di controllo "Build fail".

Abilitando queste due opzioni, ora ogni volta che una build fallisce per il progetto Demo, verrà inviata una notifica e-mail all'utente: demouser.

Step 10- Ora attiviamo una build sbagliata per vederlo in azione. In Visual Studio, vai aldemo.aspx.cs file e aggiungi una riga di codice errata.

Step 11 - Ora fai il check-in del codice da Git eseguendo un file git add e git commit.

Ora nella dashboard del progetto, la build verrà automaticamente attivata e vedrai che la build non sarebbe riuscita come mostrato nello screenshot seguente.

Se accedi all'ID Gmail del file demouser, vedrai effettivamente una notifica di errore di compilazione come mostrato nello screenshot seguente.

Uno degli aspetti chiave dell'integrazione continua è sempre vedere come si stanno comportando le build, raccogliere metriche importanti, documentare tali risultati e generare feedback continuo attraverso build continue.

Quali sono i vantaggi di disporre di queste metriche?

• Not Committing Code Enough- Se gli sviluppatori non eseguono il commit del codice in un repository di controllo della versione frequentemente, il motivo potrebbe essere una build di integrazione lenta. Per iniziare a ridurre la durata della compilazione, eseguire un'analisi di alto livello dell'ambiente di compilazione dell'integrazione per determinare i colli di bottiglia.

  Successivamente, analizza i risultati e determina il miglioramento più appropriato, quindi prova ad apportare modifiche al processo di compilazione per ridurne la durata. Infine, rivaluta la durata della costruzione per determinare se sono necessari ulteriori miglioramenti.

• Improve Test Performance- Anche in un sistema CI ben funzionante, gran parte del tempo di compilazione dell'integrazione sarà occupato dall'esecuzione di test automatizzati. La valutazione e il miglioramento delle prestazioni di questi test possono ridurre notevolmente la durata della compilazione.

• Infrastructure Issues- Potresti scoprire che le build di integrazione sono lente a causa dell'infrastruttura di sistema. Forse le prestazioni di rete sono lente o è presente una connessione di rete privata virtuale a prestazioni lente.

  Anche sistemi geograficamente dispersi e hardware o software inaffidabili possono causare problemi di prestazioni. Esamina e migliora le risorse dell'infrastruttura per ridurre la durata della compilazione.

Metrica

Di seguito sono riportate alcune delle metriche disponibili in un server Continuous Integration.

Diamo un'occhiata a ciò che TeamCity ha da offrire:

Una delle forme più semplici di metriche è ciò che è disponibile nella dashboard del progetto. L'elemento chiave qui è notare la durata di ogni build. Se la durata di ogni build inizia ad aumentare in modo sproporzionato rispetto al codice in fase di compilazione, questo potrebbe essere un problema. Quindi, questo è un feedback che può essere ricevuto e le cause potrebbero essere che il server CI ha poche risorse e forse la capacità del server deve essere aumentata.

TeamCity ha la possibilità di vedere se il server CI ha effettivamente problemi con l'infrastruttura. Neladmin dashboard in TeamCity, si può fare clic su Disk Usage per vedere quanto spazio su disco viene consumato da ogni build.

Se sono necessari ulteriori dettagli, TeamCity ha l'estensione diagnostics button, che può fornire ulteriori informazioni su CPU and Memory utilizzato dal server CI.

Visualizzazione dettagliata delle metriche di costruzione

Se si desidera vedere una vista dettagliata delle build di un particolare progetto nel tempo, questa è disponibile come parte delle build del progetto. Nella schermata di costruzione del progetto, vai alla schermata delle statistiche, questo fornirà varie statistiche e grafici su come si sta comportando la costruzione.

Una delle caratteristiche chiave dell'integrazione continua è garantire che il on-going testingcontiene tutto il codice che viene costruito dal server CI. Dopo che una build è stata eseguita dal server CI, è necessario assicurarsi che i casi di test siano in atto per ottenere il codice richiesto testato. Ogni server CI ha la capacità di eseguire casi di unit test come parte diCI suite. In.Net, l'unità di test è una funzionalità incorporata in .Net framework e la stessa cosa può essere incorporata anche nel server CI.

Questo capitolo vedrà come definire un test case in .Nete poi lascia che il nostro server TeamCity esegua questo test case dopo che la build è stata completata. Per questo, dobbiamo prima assicurarci di avere uno unit test definito per il nostro progetto di esempio.

Per fare ciò, dobbiamo seguire i passaggi successivi con la massima attenzione.

Step 1- Aggiungiamo una nuova classe alla nostra soluzione, che verrà utilizzata nel nostro Unit Test. Questa classe avrà una variabile di nome, che conterrà la stringa "Integrazione continua". Questa stringa verrà visualizzata nella pagina web. Fare clic con il tasto destro del mouse sul progetto semplice e scegliere l'opzione di menuAdd → Class.

Step 2 - Dai un nome alla classe come Tutorial.cs e fare clic sul pulsante Aggiungi nella parte inferiore dello schermo.

Step 3- Apri il file Tutorial.cs e aggiungi il codice seguente. Questo codice crea solo una stringa chiamataNamee nel costruttore assegna il nome a un valore stringa come Continuous Integration.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      public Tutorial() {
         Name = "Continuous Integration";
      }
   }
}

Step 4 - Facciamo la modifica al nostro Demo.aspx.csfile per utilizzare questa nuova classe. Aggiorna il codice in questo file con il codice seguente. Quindi questo codice ora creerà una nuova istanza della classe creata sopra.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      protected void Page_Load(object sender, EventArgs e) {
         tp.Name = "Continuous Integration";
      }
   }
}

Step 5 - Nel nostro demo.aspx file, ora facciamo riferimento al file tp.Name variabile, che è stata creata in aspx.cs file.

<%@ Page Language = "C#" AutoEventWireup = "true" 
   CodeBehind = "Demo.aspx.cs" Inherits = "Simple.Demo" %>
<!DOCTYPE html>
<html xmlns = "http://www.w3.org/1999/xhtml">
   
   <head runat = "server">
      <title>TutorialsPoint1</title>
   </head>
   
   <body>
      <form id = "form1" runat = "server">
         <div>
            <% = tp.Name%>)
         </div>
      </form>
   </body>
   
</html>

Solo per assicurarti che il nostro codice funzioni correttamente con queste modifiche, puoi eseguire il codice in Visual Studio. Una volta completata la compilazione, dovresti ottenere il seguente output.

Step 6- Ora è il momento di aggiungere i nostri test unitari al progetto. Fare clic con il tasto destro suSolution e scegli l'opzione di menu Add → New Project.

Step 7 - Vai a Test e sul lato destro, scegli Unit Test Project. Dai un nome comeDemoTest e quindi fare clic su OK.

Step 8 - Nel tuo Demo Test project, è necessario aggiungere un riferimento al progetto Simple e al necessario testing assemblies. Fare clic con il tasto destro sul progetto e scegliere l'opzione di menuAdd Reference.

Step 9 - Nella schermata successiva che viene visualizzata, vai su Progetti, scegli Simple Reference e fare clic su OK.

Step 10 - Fare clic su Add Reference di nuovo, vai su Assiemi e digita Webnella casella di ricerca. Quindi aggiungi un riferimento diSystem.Web.

Step 11 - Nel Unit Test file, aggiungi il codice seguente. Questo codice garantirà che la classe Tutorial abbia una variabile di nome stringa. Asserirà inoltre il fatto che il nome dovrebbe essere uguale a un valore di "integrazione continua". Questo sarà il nostro semplice test case.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Simple;

namespace DemoTest {
   [TestClass]
   public class UnitTest1 {
      [TestMethod]
      public void TestMethod1() {
         Tutorial tp = new Tutorial();
         Assert.AreEqual(tp.Name, "Continuous Integration");
      }
   }
}

Step 12- Ora eseguiamo il nostro test in Visual Studio per assicurarci che funzioni. In Visual Studio, scegli l'opzione di menuTest → Run → All Tests.

Dopo aver eseguito il test, vedrai il test eseguito correttamente sul lato sinistro di Visual Studio.

Abilitazione del test continuo all'interno di TeamCity - Ora che tutti i casi di test sono a posto, è il momento di integrarli nel nostro server Team City.

Step 13- Per questo, dobbiamo creare una fase di compilazione nella nostra configurazione del progetto. Vai alla home del tuo progetto e fai clic su Modifica impostazioni di configurazione.

step 14 - Quindi vai a Build Step → MS Build e fai clic su Add build step come mostrato nello screenshot seguente.

Nella schermata successiva che viene visualizzata, aggiungi i seguenti valori:

• Scegli il tipo di corridore come test di Visual Studio.

• Immettere un nome facoltativo per la fase di prova.

• Scegli il tipo di motore di prova come VSTest.

• Scegli la versione Test Engine come VSTest2013.

• Nel nome dei file di prova, fornire il percorso come DemoTest\bin\Debug\DemoTest.dll - Ricordati che DemoTestè il nome del nostro progetto che contiene i nostri test unitari. IlDemoTest.dll verrà generato dal nostro primo passaggio di compilazione.

• Fare clic su Salva che sarà disponibile alla fine dello schermo.

Ora avrai 2 passaggi di costruzione per il tuo progetto. Il primo è il passaggio Build che creerà il codice dell'applicazione e il progetto di test. E il prossimo verrà utilizzato per eseguire i test case.

Step 15- Ora è il momento di archiviare tutto il codice in Git, in modo che l'intero processo di compilazione possa essere attivato. L'unica differenza è che questa volta devi eseguire il filegit add e git commit comando dal Demo parent folder come mostrato nello screenshot seguente.

Ora, quando la build viene attivata, vedrai un output iniziale che dirà che il test è stato superato.

Step 16 - Se fai clic sul risultato Test superato e vai alla scheda Test, ora vedrai che UnitTest1 è stato eseguito e che è stato superato.

L'ispezione continua è il processo di revisione automatica del codice dell'ispezione condotta per il codice prima dell'esecuzione dei test effettivi. Esistono sottili differenze tra l'ispezione e il test del software. Il test è dinamico ed esegue il software per testare la funzionalità. L'ispezione analizza il codice in base a una serie di regole predefinite.

Gli ispettori (o strumenti di analisi statica e dinamica) sono diretti da standard identificati a cui i team dovrebbero aderire (di solito codifica o metriche di progettazione). Esempi di obiettivi di ispezione includono standard di "grammatica" di codifica, aderenza alla stratificazione architettonica, duplicazione del codice e molti altri.

L'ispezione continua riduce il tempo tra una scoperta e una correzione. Sono disponibili numerosi strumenti di ispezione continua. Per questo esempio, useremoNCover 3.xche ha un'integrazione con TeamCity. Vediamo come possiamo eseguire l'ispezione continua e cosa può fare per noi.

Scarica e installa NCover

NCover è un prodotto separato che deve essere scaricato e installato. Per scaricare NCover, fare clic sul seguente collegamento e scaricare il programma di installazione a 32 bit -http://www.ncover.com/info/download.

Eseguire il programma di installazione scaricato e quindi fare clic su Avanti dopo aver avviato il programma di installazione.

Accetta il contratto di licenza e fai clic su Avanti.

Accetta i componenti predefiniti e fai clic su Avanti.

Fare clic sul pulsante Installa per avviare l'installazione.

Fare clic sul pulsante Fine per completare l'installazione.

Avvia l'installazione di NCover per la prima volta andando su C:\Program Files (x86)\NCover\ NCover.Explorer.exe. Dovrai solo installare una chiave di prova per la prima volta, il che è un processo semplice.

Configura il progetto in TeamCity per utilizzare NCover

Step 1 - Vai alla schermata principale del tuo progetto e fai clic su Modifica impostazioni di configurazione.

Step 2 - Vai a Build Steps e fai clic su Edit per il file TestStep. L'ispezione continua deve essere eseguita insieme ai test unitari definiti.

Step 3 - Nella sezione .Net Coverage, fare clic su .Net Coverage Tool. Quindi scegli le seguenti impostazioni.

• Scegli lo strumento .Net Coverage come NCover (3.x)
• Piattaforma come x86
• Versione come v4.0
• Percorso per NCover come C: \ Program Files (x86) \ NCover
• Lascia le altre impostazioni così come sono

Step 4 - Fare clic su Salva.

Step 5 - Ora vai alla schermata principale del tuo progetto e fai clic su Esegui.

Step 6- Una volta eseguita la build, fare clic sul Test superato. Ora vedrai una schermata di copertura del codice e vedrai molti indicatori di metrica.

Step 7 - È ora possibile fare clic sulla scheda Copertura del codice per ottenere maggiori informazioni sull'analisi del codice.

Step 8 - Fare clic su fullcoveragereport.html. Si riceverà ora un rapporto completo e completo sull'ispezione effettuata per il.Net code.

L'integrazione continua del database è il processo di ricostruzione del database e dei dati di test ogni volta che viene applicata una modifica al repository di controllo della versione di un progetto.

In Database Integration, generalmente tutti gli artefatti relativi all'integrazione del database -

• Dovrebbe risiedere in un sistema di controllo della versione.
• Può essere testato per il rigore e ispezionato per la conformità alle politiche.
• Può essere generato utilizzando i tuoi script di build.

Le attività che possono essere coinvolte nell'integrazione continua del database possono essere una delle seguenti:

Drop a Database - Rilascia il database e rimuovi i dati associati, in modo da poter creare un nuovo database con lo stesso nome

Create a new Database - Crea un nuovo database utilizzando Data Definition Language (DDL).

Insert the Initial Data - Inserire tutti i dati iniziali (ad esempio, tabelle di ricerca) che il sistema dovrebbe contenere al momento della consegna.

Migrate Database and Data - Migrare lo schema del database e i dati su base periodica (se si sta creando un sistema basato su un database esistente).

Modify Column Attributes - Modifica gli attributi ei vincoli delle colonne della tabella in base ai requisiti e al refactoring.

Modify Test Data - Modificare i dati di test secondo necessità per più ambienti.

Quindi, nel nostro esempio di database continuo, eseguiremo i seguenti passaggi:

• Creeremo un database MS SQL Server e una tabella corrispondente.

• Creeremo uno script da SQL Server Management Studio. Questo script di database verrà utilizzato per impostare la nostra tabella nel database.

• Scriveremo un codice nel nostro progetto ASP.Net per accedere a questo database.

• Creeremo un passaggio nel nostro progetto in TeamCity per eseguire questo script.

• Verificheremo il nostro script in Git.

Passaggi per farlo nel database AWS che è stato creato in una sezione precedente.

Step 1- Creare un database MS SQL Server e una tabella corrispondente. Apriamo SQL Server Management Studio e creiamo un semplice database e una tabella. Fare clic con il pulsante destro del mouse sui database e fare clic suNew Database.

Step 2 - Chiamalo come Demodb e fare clic su OK

Step 3 - Nel nuovo database, fare clic con il pulsante destro del mouse e creare una nuova tabella.

Step 4 - Puoi aggiungere le colonne desiderate alla tabella.

Step 5 - Salvare la tabella e denominarla come Demotb.

Step 6 - Ora fai clic con il pulsante destro del mouse sulla tabella e scegli l'opzione di menu Script Table as → Drop and Create to → File.

Step 7 - Salva il file nella cartella del progetto demo come Sample.sql.

Questo è l'aspetto dello script del database. Prima eliminerebbe una tabella esistente, se presente, quindi ricrea la tabella.

USE [Demodb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******

DROP TABLE [dbo].[Demotb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Demotb](
   [TutorialName] [nvarchar](max) NULL,
   [TutorialID] [smallint] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

Step 8 - Ora cambiamo rapidamente il nostro ASP.Net code per fare riferimento al nuovo database.

Step 9 - Nel Tutorial.cs file nel tuo Demo project, aggiungi le seguenti righe di codice. Queste righe di codice si collegheranno al database, prenderanno la versione del server e memorizzeranno il nome della versione nella variabile Name. Possiamo visualizzare questa variabile Nome nel nostro fileDemo.aspx.cs file tramite un file Response.write comando.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      
      public Tutorial() {
         string connectionString = "Data Source = WIN-50GP30FGO75;
         Initial Catalog = Demodb;
         Integrated Security = true;";
         
         using (SqlConnection connection = new SqlConnection()) {
            connection.ConnectionString = connectionString;
            connection.Open();
            Name = connection.ServerVersion;
            connection.Close();
         }
      }
   }
}

Step 10 - Aggiungi il codice seguente al file Demo.aspx.cs per assicurarsi che visualizzi la versione di SQL Server.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      
      protected void Page_Load(object sender, EventArgs e){
         Response.Write(tp.Name);
      }
   }
}

Ora se eseguiamo il codice, otterrai il seguente output nel browser.

Step 11- Ora aggiungiamo il nostro passaggio in TeamCity che richiamerà lo script del database. Vai alla dashboard del tuo progetto e fai clicEdit Configuration Settings.

Step 12 - Vai a Build Steps e fai clic Add build step.

Scegliere le seguenti opzioni (notare che il client MS SQL Server deve essere installato sul server CI).

• Il tipo di corridore dovrebbe essere la riga di comando.

• Assegna un nome passaggio opzionale.

• Run dovrebbe essere eseguibile con parametri.

• L'eseguibile del comando dovrebbe essere C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe

• I parametri del comando dovrebbero essere -S WIN-50GP30FGO75 -i Sample.sql. Dove –S fornisce il nome dell'istanza di SQL Server.

Step 13 - Fare clic su Salva.

Ora ciò che deve essere assicurato è l'ordine di costruzione. Devi assicurarti che l'ordine di costruzione sia il seguente.

Step 14 - Puoi modificare l'ordine di compilazione scegliendo l'opzione per riordinare i passaggi di compilazione.

• La configurazione del database dovrebbe essere la prima, quindi verrà utilizzata per ricreare il database da zero.

• La prossima è la build della tua applicazione.

• Finalmente la tua configurazione di prova.

Step 15 - Ora esegui il file git add e git commit comando in modo che il file Sample.sqlfile viene archiviato in Git. Questo attiverà automaticamente una build. E questa build dovrebbe passare.

Ora hai un ciclo di compilazione completo con un aspetto di integrazione continua del database anche nel tuo ciclo. Nella sezione successiva, esaminiamo ulteriormente questo aspetto e esaminiamo la distribuzione continua.

Ora che lo hai fatto con un SQL Server locale, possiamo ripetere gli stessi passaggi per un file AWS MS SQLServer che è stato creato in una delle sezioni precedenti. Per connettersi a un Microsoft SQL Server, è necessario connettersi tramite la seguente convenzione.

Step 16- Per prima cosa vedi qual è il nome assegnato alla tua istanza di database in AWS. Quando accedi ad AWS, vai alla sezione RDS nella sezione database.

Step 17 - Fare clic su Istanze database nella schermata successiva che viene visualizzata.

step 18- Fare clic sul database e prendere nota dell'endpoint. Nello screenshot seguente, èdemodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433

Step 19 - Ora per connettersi al database da SQL Server Management Studio, è necessario specificare la connessione come demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com,1433 (Notare la virgola utilizzata tra il nome dell'istanza e il numero di porta).

Lo screenshot seguente mostra una connessione riuscita al database.

Quindi puoi ripetere tutti gli stessi passaggi. IlSqlcmd command sarà il seguente -

Questo stesso comando può essere sostituito nella fase di creazione del database in TeamCity. Quando esegui il filesqlcmd command, la tabella verrà creata automaticamente nel database SQL Server in AWS.

Build automatizzate e build ripetibili. Test automatizzati e test ripetibili. Categorie di test e frequenze di test. Ispezioni continue. Integrazione continua del database. Questa serie di attività nella creazione di un ambiente CI efficace consente principalmente un vantaggio chiave: il rilascio di software funzionante in qualsiasi momento, in qualsiasi ambiente.

Nei nostri capitoli precedenti, abbiamo realizzato tutti i seguenti segmenti:

• Creato il nostro codice.
• Garantito un corretto build in TeamCity.
• Creato un processo di integrazione del database.
• Test condotti con successo.

Ora non resta che eseguire una distribuzione automatizzata, in modo che l'intero processo sia completo.

Per una distribuzione automatizzata nel nostro caso, dobbiamo seguire questi passaggi:

• Nel nostro server di distribuzione, assicurati che IIS sia installato.

• Assicurati che l'utente IIS abbia accesso al nostro database.

• Crea un profilo di pubblicazione che verrà utilizzato per pubblicare il sito una volta creato.

• Assicurati di modificare il nostro comando MSBuild per eseguire una distribuzione automatica.

• Automatizza TeamCity per eseguire una pubblicazione automatica.

• Fai un git commit per assicurarti che tutti i tuoi file siano in Git.

Step 1- Configurare un server IIS locale. Se si dispone di un server IIS locale o remoto, è possibile eseguire la seguente configurazione per distribuire la nostra applicazione. È sempre una buona pratica vedere se una distribuzione può essere eseguita manualmente prima che venga eseguita in modo automatico.

Step 2 - Su un server Windows 2012, vai a Server Manager e fai clic su Aggiungi ruoli e funzionalità.

Step 3 - Fare clic su Avanti nella schermata successiva che viene visualizzata.

Step 4 - Scegli l'installazione basata su ruoli o basata su funzionalità nella schermata successiva e fai clic su Avanti.

Step 5 - Seleziona il server predefinito e fai clic su Avanti.

Step 6 - Scegli il ruolo del server Web e fai clic su Avanti.

Step 7 - Nella schermata successiva che viene visualizzata, fare clic su Avanti.

Step 8 - Fare nuovamente clic su Avanti nella schermata successiva che appare.

Step 9 - Nella schermata successiva che si apre, fare clic su Avanti.

Step 10 - Nella schermata finale, puoi fare clic sul pulsante Installa per installare IIS.

Dopo aver installato IIS, è possibile aprirlo aprendo Internet Information Services.

Step 11 - Fai clic su Pool di applicazioni, vedrai un pool con il nome di DefaultAppPool. Questo deve avere accesso a SQL Server nel passaggio successivo.

Step 12 - Se dobbiamo connettere un'applicazione ASP.Net a un'applicazione MS SQL Server, dobbiamo dare accesso al pool di applicazioni predefinito all'istanza di SQL Server, in modo che possa connettersi al nostro Demodb Banca dati.

Step 13- Apri SQL Server Management Studio. Vai su Login, fai clic con il tasto destro e scegli l'opzione di menuNew Login.

Nella schermata successiva, aggiorna i seguenti parametri e fai clic su OK.

• Nome di accesso come IIS APPPOOL \ DefaultAppPool.
• Database predefinito: dovrebbe essere il nostro database, che è demodb.

Step 14 - Creazione di un file Publish Profile. Il profilo di pubblicazione viene utilizzato in Visual Studio per creare un pacchetto di distribuzione che può quindi essere utilizzato con MS Build e in qualsiasi server CI di conseguenza. Per fare ciò, da Visual Studio, fai clic con il pulsante destro del mouse sul progetto e fai clic sull'opzione di menu di Pubblica

Step 15 - Nella schermata successiva che viene visualizzata, scegli di creare un nuovo profilo di pubblicazione, dagli un nome - DemoDeployment. Quindi fare clic sul pulsante Avanti.

Nella schermata successiva che viene visualizzata, aggiungi i seguenti valori:

• Scegli il metodo di pubblicazione come Web Deploy.
• Inserisci il server come localhost.
• Immettere il nome del sito come Sito Web predefinito / Demo.
• Inserisci l'URL di destinazione come http://localhost/Demo

Quindi fare clic sul pulsante Avanti.

Step 16 - Nella schermata successiva, fare clic su Avanti.

Step 17 - Nella schermata finale visualizzata, fai clic sul pulsante Pubblica.

Ora se vai al C:\Demo\Simple\Properties\PublishProfiles posizione del tuo progetto, vedrai un nuovo file publish profile xml filecreato. Questo file del profilo di pubblicazione avrà tutti i dettagli necessari per pubblicare l'applicazione sul server IIS locale.

Step 18- Ora personalizziamo il nostro comando MSBuild e usiamo il profilo di pubblicazione sopra e vediamo cosa succede. Nel nostro comando MSBuild, specifichiamo i seguenti parametri:

• Deploy on Build is true: questo attiverà una distribuzione automatica una volta completata una build corretta.

• Stiamo quindi menzionando di utilizzare il profilo di pubblicazione che è stato utilizzato nel passaggio precedente.

• La versione di Visual Studio deve essere menzionata solo per la capacità di distribuzione di MSBuild su qual è la versione di Visual Studio in uso.

Quando esegui il comando precedente, MSBuild attiverà un processo di compilazione e distribuzione. Quello che noterai è che lo sta distribuendo al nostroDefault Website nel nostro server IIS.

Ora se navighiamo nel sito - http://localhost/Demo/Demo.aspx vedremo il seguente output, il che significa che MSBuild ha eseguito correttamente la distribuzione sul nostro sito web.

Step 19 - Automatizzazione tramite TeamCity - Ora è il momento di aggiungere un'attività al nostro server TeamCity per utilizzare automaticamente MSBuild per distribuire la nostra applicazione, in base ai passaggi sopra menzionati.

Step 20 - Vai alla dashboard del tuo progetto e fai clic Edit Configuration Settings.

Step 21 - Vai a Build Steps e fai clic su Add a Build Step.

Scegli le seguenti opzioni:

• Il tipo di corridore dovrebbe essere MSBuild

• Assegna un nome al passaggio opzionale

• Immettere il percorso di compilazione come Simple / Simple.csproj

• Mantieni la versione di MSBuild come Microsoft Build Tools 2013

• Mantieni la versione MSBuild Tools come 12.0

• Inserisci la riga di comando come / p: DeployOnBuild = true / p: PublishProfile = DemoDeployement / p: VisualStudioVersion = 12.0

Step 22 - Fare clic su Salva.

Assicurati che nei passaggi di compilazione, il passaggio di distribuzione sia l'ultimo passaggio della catena.

Step 23 - Adesso facciamo una finale git commit, per garantire che tutti i file siano in Git e possano essere utilizzati da TeamCity.

Congratulazioni, hai impostato con successo un ciclo di integrazione continua completo per la tua applicazione, che può essere eseguito in qualsiasi momento.

Facciamo una revisione finale delle migliori pratiche di integrazione continua sulla base di tutte le lezioni che abbiamo imparato finora -

• Maintain a code repository- Questo è il passaggio più semplice. In tutti i nostri esempi, tutto è mantenuto in un repository Git, dalla base del codice ai profili di pubblicazione, agli script del database. È sempre necessario assicurarsi che tutto sia conservato nel repository del codice.

• Automate the build- Abbiamo visto come utilizzare MSBuild per automatizzare una build insieme all'utilizzo di un profilo di pubblicazione. Anche questo è un passaggio chiave nel processo di integrazione continua.

• Make the build self-testing - Assicurati di poter testare la build mantenendo i casi di test di unità in posizione e questi casi di test dovrebbero essere in modo tale da poter essere eseguiti dal server Continuous Integration.

• Everyone commits to the baseline every day- Questo è un principio chiave dell'integrazione continua. Non ha senso restare fino alla fine dell'intero processo per vedere chi rompe la build.

• Every commit (to baseline) should be built- Ogni commit fatto per l'applicazione, deve essere costruito con successo. Se la compilazione non riesce per qualsiasi motivo, è necessario modificare il codice per garantire che la compilazione venga eseguita.

• Keep the build fast- Se la compilazione è lenta, indica un problema nell'intero processo di integrazione continua. Assicurati che le build siano sempre limitate a una durata, preferibilmente non dovrebbero mai andare oltre i 10 minuti.

• Everyone can see the results of the latest build- La dashboard di TeamCity offre a tutti una visione di tutte le build, che sono state superate o non riuscite. Questo fornisce una buona visione a tutte le persone che sono coinvolte nel processo di integrazione continua.