presenta – #wpc15it1 Build vNext, cosa cambia nella continuous integration di TFS/VSTS (PKA VSO) Gian Maria Ricci – Microsoft Visual Studio ALM MVP

Agenda Punto 1  Punto 1.1  Punto 1.2 Punto 2 Punto 3 –

Introduzione – #wpc15it3

Un po’ di storia TFS 2005 / 2008 – MSBUILD  Barriera di ingresso più alta  Wizard solamente iniziale  Semplice da editare e riprodurre su macchine DEV  Semplice da estendere TFS 2010 / 2013 – Workflow Foundation  Wizard in Visual Studio per gestire la build  Difficile da editare e da riprodurre su macchine dev  Difficile da estendere con Workflow, nel 2013 i template base introducono la possibilità di chiamare scripts TFS 2015 – Build vNext  Editor e wizard completamente web  Agent task open source  Multipiattaforma  ….. More, more and more – #wpc15it4

E la vecchia build? Architettura di build  Viene ancora manutenuta sotto il nome di XAML Build  Ancora pienamente supportata per TFS 2015  Non avrà più nuove funzionalità  È destinata a scomparire lentamente e non è il caso di investirci più risorse Build esistenti  Ha poco senso «tradurle» subito alla nuova versione  Provare la vNext sulle nuove build per familiarizzare  Capire quali limitazioni sono ancora presenti nella build vNext rispetto alla build XAML – #wpc15it5

Cosa manca in Build vNext? Gated check-in build per progetti basati su TFVC Workspace mapping ancora limitato Differenti retention policy, che contengono anche qualche limitazione Priorità quando si accoda una nuova build (assenza di priorità sulle build) – #wpc15it6

Architettura Come la build vNext migliora l’architettura della Continuous integration – #wpc15it7

Agent vNext vs XAML Agent XAML Agent  Installazione della iso di TFS sulla macchina di controller/agent  Un solo controller per macchina (fisica / virtuale)  Un controller si connette solamente ad una Project Collection  Più agent per macchina, ma tutti connessi ad un unico controller Agent vNext  Semplice file zip con uno script da lanciare per l’installazione  Controller integrato in TFS  Agenti multipli per macchina – #wpc15it8

Agent vNext le novità Riproducibilità build  5 minute install su macchine dev per replicare una build  Nulla viene realmente installato, è solamente un exe che viene lanciato Multipiattaforma  presente anche per macchine linux / Macintosh  open source (  Basato su Node.js e Npm Manutenzione  Semplice interfaccia web per listare pool ed agent attivi / disattivi  Aggiornamento automatico Debuggabilità  Semplice processo exe che può essere lanciato manualmente  Quasi inutile perché l’estendibilità viene ora preferita tramite script – #wpc15it9

Build vNext architettura Controller centralizzato  Non esiste più il build controller  È compreso nel core di TFS / VSTS (pka VSO) Pool di agenti  Per suddividere / aggregare gli agenti si usa il concetto di pool  Ogni pool ha le sue autorizzazioni  Un agent può appartenere ad un sola pool Comunicazione  Il controller non deve contattare l’agent direttamente  Un agent può risiedere in una rete privata, unica condizione è che sia in grado di contattare VSTS (TFS) Gestione «capability»  Auto detection di capability standard (ex, java, vs,.net sdk, etc)  Possibilità di aggiungere capability manualmente – #wpc15it10

Build vNext è task based Workflow lineare  Non esiste più un workflow  Il flusso è lineare e composto da una serie di «task»  I task sono open source ( agent-tasks) agent-tasks  Il server è più un «orchestratore» che una vera e propria architettura di build Editor Web  Tutta la build viene gestita da browser, Visual Studio non è più richiesto  Esperienza di editing e personalizzazione molto migliorata  Estendibilità tramite script molto semplificata  History della build per audit Nuove funzionalità  Build template  Clone build  Build Draft – #wpc15it11

Novità Cosa abbiamo in più da build vNext – #wpc15it12

Editor web  Tutto ciò che riguarda la build è ora Web-based  Creare e modificare definizioni di build  Accodare nuove richieste di build  Gestione dei pool e delle configurazioni di agent  Monitoraggio dei risultati delle build  Non è più richiesto Visual Studio / Team Explorer – #wpc15it13

Draft  Save as a Draft  La build viene salvata ma come draft  È possibile lavorare e pubblicare successivamente la build  Si può schedulare un draft per visualizzare il risultato – #wpc15it14

Build History Audit / history  Storia delle modifiche fatte alla build  Possibilità di generare un diff tra le versioni – #wpc15it15

Multi configuration Il numero delle build può essere «moltiplicato» per alcuni fattori  Si specifica le variabili per la «moltiplicazione»  Vengono calcolate le possibili combinazioni tra i valori delle variabili per la build  Viene eseguita la build per ogni configurazione trovata – #wpc15it16

Template È possibile salvare una build come template  In questo modo si può partire con una build già preconfigurata piu attinente alle vostre esigenze  Il template è solamente una maniera per iniziare da una build preconfigurata  Non esiste connessione tra il template e le build create con quel template – #wpc15it17

Artifacts È ora possibile specificare un task per l’upload degli artefatti  Rende esplicito decidere cosa pubblicare  Può essere disabilitato / abilitato alla bisogna Gli artefatti possono essere visualizzati/scaricati da web con l’artifacts explorer – #wpc15it18

Esecuzione La running console mostra in near real time gli output dei task – #wpc15it19

Execution Durante e dopo l’esecuzione è possibile visualizzare i log per ogni specifico task – #wpc15it20

Status Badge Ogni build può generare una url che mostra un badge per indicare visivamente lo stato di una build – #wpc15it21

Branching policies (Git) È possibile impostare per ogni branch una build che verifica le pull requests Si può richiedere il blocco della merge se la build fallisce. – #wpc15it22

Deploy Esistono task dedicati per automatizzare deployment Si può ottenere cosi facilmente un continuous deployment – #wpc15it23

Release management Le nuove build vNext possono essere usate con il vecchio Release Management (vNext) e con il nuovo Release Management (preview) Esistono delle azioni (e dei template) per effettuare i deploy direttamente dalla build, senza passare per Release Management – #wpc15it24

Nuovo Test Explorer Nuovo hub per visualizzare il risultato dei test di una build Creazione di bug a partire da un test run  Link del test result con un Work Item  Inserimento dei dati del test fallito nel work item Migliore visualizzazione del risultato dei test delle build. – #wpc15it25

Create work item on failure Maggiore flessibilità nella creazione di un work item in caso di fallimento build.  Decidere il tipo di work item  Assegnarlo a chi ha richiesto / causato il trigger della build  Inserire alcuni campi custom precompilati nel work item – #wpc15it26

Differenze Quello che dobbiamo sapere se già usiamo la build XAML – #wpc15it27

Triggers Continuous integration  Non è possibile specificare la durata del batch changes Scheduled builds  Potete aggiungere delle build schedulate alla continuous integration  È possibile aggiungere più di un singolo scheduling  Per Git ogni scheduling può decidere quali branch compilare – #wpc15it28

Retention policies Mancanze  Non è più possibile specificare un numero di build ma un numero di giorni  È possibile specificare il numero massimo di giorni Aggiunte  Si può aggiungere più di una retention policy per le singole branch in Git – #wpc15it29

Workspace mapping (TFVC) Mancanze  Non è possibile specificare un workspace esistente come mapping  Bisogna mappare le cartelle Aggiunte  Si può specificare esattamente i percorsi da monitorare per i trigger – #wpc15it30

Funzionalità inaspettate Build di repository Git hostati non su TFS o VSTS Build per repository subversion Continuous integration per GitHub Gran parte del codice ora open source ( ) – #wpc15it31

Estendibilità Semplici script powershell / bash inclusi nel source control Interazione con la build tramite output formattato ( tasks/blob/master/docs/authoring/commands.md) tasks/blob/master/docs/authoring/commands.md Possibilità di scrivere task personalizzati che possono essere uploadati nel server Si utilizza una utility a riga di comando cross platform chiamata t-cli distribuita con npm (node.js). – #wpc15it32

Costi  Visual Studio Team Services  Host agent con 240 minuti di build gratuiti  Ogni host agent aggiuntivo costa 40$ mese  Un agent installabile su propria infrastruttura gratuito  Ogni agent aggiuntivo su propria infrastruttura 15$ mese  TFS On premises  Numero di agent illimitati nella propria infrastruttura – #wpc15it33

–

Q & A Domande e Risposte – #wpc15it35

Contatti OverNet Education OverNet Education Tel – #wpc15it36