Utilizzando Microsoft TFS 2015 Update-3 per. NET( Build, Test e Deploy): TFS Tutorial

TFS è più ampiamente utilizzato per lo sviluppo.NET utilizzando Visual Studio. NET IDE. Con TFS 2015 Update 3, è possibile connettersi a qualsiasi repository Git di Team Foundation Server, utilizzando una chiave SSH.

Team Foundation Server (TFS) è un prodotto ALM di Microsoft che fornisce le funzionalità per uno sviluppo e test end-to-end utilizzando la gestione degli elementi di lavoro, la pianificazione del progetto (cascata o Scrum), il controllo della versione, Build / Release (Deploy) e le funzionalità di test.

NOTA: Questo tutorial TFS ha molte immagini in modo da consentire di caricare correttamente.

Leggere anche =>TFS per i progetti JAVA con Eclipse in DevOps

Introduzione

TFS è su misura per Microsoft Visual Studio ed Eclipse su tutte le piattaforme, tuttavia, può anche essere utilizzato come back-end per diversi IDE (ambienti di sviluppo integrati).

Ora daremo un’occhiata a come Team Foundation Server (TFS) verrà utilizzato per creare, testare e distribuire applicazioni Web.NET che è tradizionalmente il punto di forza dello strumento.

Prerequisito:

• Microsoft TFS 2015 Update 3
• Microsoft Visual Studio.NET 2015 (versione di prova di 30 giorni)
• SonarQube 6.4 o superiore
• Server Web IIS abilitato. Dal momento che sto usando una casella di Windows 7 puoi controllare questo tutorial su come abilitare IIS 7. Come installare Internet Information Services (IIS 7) su Windows 7 Ultimate
• Ci sono diversi video di YouTube su come abilitare IIS su Windows 2008 / 2012 / 2016.

In genere per eseguire i passaggi menzionati nel tutorial è necessario un server di compilazione, in cui verranno eseguite le compilazioni e macchine o ambienti di distribuzione in cui le applicazioni verranno distribuite su IIS, con agenti installati e in esecuzione. Si prega di fare riferimento al mio tutorial precedente per sapere come installare gli agenti.

Imposta un’applicazione C#

Supponendo che gli elementi di lavoro dell’ATTIVITÀ vengano creati in TFS e vengano assegnati agli sviluppatori per lavorare sullo stesso. Ho sempre notato che la tracciabilità è molto importante dal punto di vista del monitoraggio di qualsiasi lavoro attraverso il ciclo di vita del software.

Prima di aggiungere un’applicazione.NET al repository di controllo del codice sorgente TFS, verificare se esiste o meno un progetto di raccolta e team.

Una raccolta viene creata dall’amministratore TFS. Consiste in un gruppo di progetti di team in qualsiasi organizzazione di servizi, in cui vengono eseguiti progetti per più clienti. È possibile creare raccolte individuali per ogni progetto cliente in TFS.

Una volta creata una raccolta, è possibile creare più progetti di team al suo interno. Un singolo progetto di team è costituito da tutti gli elementi di lavoro, codice sorgente, artefatti di test, metriche per i report, ecc., Il progetto di squadra può esser creato usando vari modelli di processo insiti come Scrum, Agile, CMMI ecc.

• Ulteriori informazioni sulla creazione di collezioni possono essere trovate @ Manage team project collections in Team Foundation Server
• Qui, userò la raccolta predefinita che viene creata una volta installato TFS
• Per creare un progetto di squadra all’interno di una raccolta, segui i passaggi come mostrato di seguito.

Avvia l’interfaccia Web TFS utilizzando l’URL http://<ServerName>:port/tfs e puoi vedere il progetto creato.

Fare clic sul progetto e si arriva al Team Dashboard

(Nota: Fare clic su qualsiasi immagine per la vista ingrandita)

Ora abbiamo una collezione e un progetto di squadra creato. Lanciamo Visual Studio.NET e creare una nuova applicazione Web c# e condividere il progetto al repository di controllo del codice sorgente TFS. Questo è il primo passo verso la creazione di una pratica di integrazione continua (CI).

1) Avvio visivo Studio.NET e imposta TFS come repository di controllo del codice sorgente predefinito. Vai a Strumenti = > Opzioni = > Controllo del codice sorgente. Quindi fare clic su OK.

2) Vai a View => Team Explorer e connettersi al server TFS utilizzando l’icona

3) Creare un programma in C# ASP.NET Web project

4) Dato che si sta creando un’applicazione web, Selezionare i Moduli Web template

fare Clic su OK per creare il progetto.

5) Il progetto creato può essere visualizzato in Esplora soluzioni. .NET utilizza il concetto di.file sln o soluzione per contenere tutti i progetti. Una volta aperta la soluzione si apriranno anche tutti i progetti associati. Abbiamo bisogno di aggiungere la soluzione al repository di controllo del codice sorgente TFS

6) Modificare il file predefinito.aspx come mostrato, Salvarlo e quindi aggiungere l’intera soluzione al repository di controllo sorgente TFS

Seleziona la vista di progettazione e sarai in grado di vedere l’intera pagina

7) Aggiungi la soluzione al controllo del codice sorgente TFS. Fare clic destro sulla soluzione e selezionare ” Aggiungi la soluzione di Controllo del codice Sorgente’

8) Selezionare il Team di Progetto creato in precedenza e quindi fare clic su OK

9) La soluzione non è ancora il check-in per il TFS. Nel Team Explorer fare clic sul controllo del codice sorgente explorer e si può vedere la soluzione aggiunta per essere controllato in.

10) Modifiche al check-in. Vai a Team Explorer = > Modifiche in sospeso

Inserisci un commento e trascina un elemento di lavoro dell’ATTIVITÀ per garantire la tracciabilità. Fare clic sul pulsante Check – in.

11) Per testare il sito in locale, fare Clic sull’icona di Firefox in Visual Studio.NET. Ricordare non è ancora stato distribuito a IIS su qualsiasi tipo di ambiente.

Creazione della definizione di build con l’analisi del codice

Una definizione di build consiste in una serie di attività eseguite durante un processo di build automatizzato. Esempi di attività possono consistere nell’esecuzione di una build di Visual Studio, di una build di MS,nell’esecuzione di script PowerShell o Shell, ecc.

1) Per creare una definizione di build, accedi all’interfaccia Web TFS e vai alla SCHEDA Build. Fare clic su + per creare una definizione di build. Inizia con definizione VUOTA e quindi fare clic su Avanti.

Selezionare il Team di Progetto e fare clic su “Crea”

fare Clic su Modifica, che si trova accanto al Vuoto definizione

Salvare la definizione di compilazione come qualcosa di simile a ‘Principale di Costruire ”

Dal momento che Sonarqube sarà utilizzato per l’analisi del Codice quindi aggiungere il 2 Sonar passi ‘SonarQube Scanner per MSBuild Iniziare l’Analisi’ e il ‘SonarQube Scanner per MSBuild – End Compiti di analisi.

Aggiungere il passaggio Inizia analisi prima di qualsiasi compilazione di MS o Visual Studio. Questo passaggio recupera i dettagli dal server Sonarqube per configurare l’analisi.

Aggiungi la fase di analisi finale in seguito.

I passaggi aggiunti saranno i seguenti con il passaggio di compilazione MS in mezzo.

Inizia a definire i dettagli del server Sonarqube. Definire l’endpoint in cui vengono aggiunti i dettagli del server Sonarqube e dell’autenticazione. Fare clic su “Gestisci” per aggiungere i dettagli del server Sonarqube.

Clicca su ‘New Service Endpoint => Generic’

Ora torna alla schermata di definizione della build principale e seleziona endpoint che è stato appena creato.

Configurazione completata per iniziare l’analisi, appare come mostrato di seguito

Selezionare la soluzione. Nelle Impostazioni aggiuntive Avanzate => immettere quanto segue e salvare la definizione di build

/d:sonar.SCM.abilitato=true / d: sonar.SCM.provider = tfvc/d: sonar.tfvc.nome utente=niranjan / d: sonar.tfvc.password.secured = <password>

Analisi SonarQube – End. Terminare l’analisi e quindi caricare i risultati nel progetto SonarQube.

Aggiungi un passaggio per pubblicare gli artefatti sul server. Gli artefatti verranno memorizzati in una cartella di rilascio nel server e verranno utilizzati durante la distribuzione.

2) Installare l’agente sulla macchina di compilazione e distribuzione. È possibile fare riferimento al mio tutorial precedente per sapere come installare l’agente. Ora supponendo che l’agente sia installato, assicurarsi che l’agente sia in esecuzione o meno.

3) Assicurarsi che il plugin SonarQube SCM TFVC sia scaricato da qui. e copiato nella directory SonarQube installation \ extensions \ plugins. Questo plugin assicura che il codice sorgente sia preso dal repository di controllo del codice sorgente TFS e sia reso disponibile a SonarQube per l’analisi del codice.

4) Dopo aver scaricato e copiato il plugin, avviare il server sonar

5) Avviare una Build per verificare se i passaggi funzionano correttamente. Aprire la definizione di build e fare clic su ‘Queue Build’

Build riuscita. Tutti i passaggi sono andati bene.

Fai clic sul numero di build, in questo caso, è Build 217 e vai alla scheda Artefatti per guardare la cartella di rilascio creata a livello di server.

Nota: Nella sezione successiva il processo di rilascio mostra come qualsiasi modifica può essere riflessa durante il processo di distribuzione. A tal fine assicurarsi che gli artefatti del progetto vengano copiati tramite il passaggio COPIA nella fase Definizione compilazione dopo compilazione o copiare manualmente la directory artefatto del progetto in C:il nostro sito utilizza cookie tecnici e di terze parti. Questo deve essere fatto solo una volta.

Creazione di Release per la distribuzione

Nella sezione precedente, abbiamo visto la Build, seguita dall’analisi del codice usando SonarQube. Ora creeremo una versione per distribuire gli artefatti dalla cartella “drop” a IIS.

Con la creazione del Rilascio, l’intera Integrazione Continua e la Consegna continua sono automatizzate senza alcun intervento manuale.

Vai all’hub di rilascio e crea una definizione di rilascio.

Iniziare con definizione vuota e fare clic su OK.

Salvare la definizione di rilascio e rinominare l’ambiente predefinito in QA. Sulla base dei progetti, ambienti aggiuntivi come Staging Pre-Prod ecc. può anche essere aggiunto e la distribuzione sarebbe automatizzata per l’intero ambiente uno dopo l’altro.

Collegare la definizione di compilazione alla definizione di rilascio in modo che la distribuzione sia automatizzata. Fare clic su “Collegamento a una definizione di build”. Selezionare la definizione di build creata in precedenza.

Clicca sul Link

Attivare la Distribuzione Condizione per avviare la distribuzione subito dopo il Rilascio creazione

Inoltre, attivare il Trigger per la distribuzione dopo la build è successo. Nella definizione di rilascio, vai alla scheda Trigger e abilita “Distribuzione continua”, seleziona la definizione di build.

Successivamente salvare la definizione di rilascio.

Indietro nella scheda Ambienti della definizione di rilascio aggiungere le attività per distribuire gli artefatti al server IIS.

Aggiungi un’attività per copiare i file dalla cartella ‘drop’ creata durante il processo di compilazione in IIS wwwrootdirectory.

cartella di Origine – Sfoglia ” e selezionare il Webapplication1 progetto nella cartella di destinazione

cartella di Destinazione deve essere la cartella inetpub\wwwroot – C:\inetpub\wwwroot\WebApplication1

l’Esecuzione di Rilascio per la Distribuzione

Nel rilascio hub, creare una versione per avviare la distribuzione

Selezionare l’ultima build stabile e fare Clic su “Crea” per Iniziare la Distribuzione.

La distribuzione è riuscita nell’ambiente QA

Esegui inetmgr che è il gestore IIS, in cui è possibile gestire tutti i siti web / applicazioni installate in IIS. Individuare l’applicazione Web distribuita.

Per concludere una volta avviata la Build, la distribuzione verrà completata anche in tutti gli ambienti definiti, poiché la Versione è collegata alla definizione di build.

Conclusione

In questo tutorial TFS, ora abbiamo visto come la piattaforma Microsoft ALM può essere utilizzata per automatizzare la compilazione, il test e la distribuzione per le applicazioni.NET. TFS svolge un ruolo importante qui.

Quindi nel mondo di oggi, l’AUTOMAZIONE è la chiave per la consegna di successo e più veloce per rimanere al passo.