---

Settembre 2016

Volume 31 Numero 9

Il presente articolo è stato tradotto automaticamente.

DevOps per le app per dispositivi mobili - Source of Truth: il ruolo dei repository in DevOps

Da Kraig Brockschmidt | Settembre 2016

Il primo articolo di questa serie, "dal codice al cliente: Esplorazione per dispositivi mobili DevOps"(msdn.com/magazine/mt767694), introdotta DevOps Microsoft dello stack per le applicazioni per dispositivi mobili e servizi back-end. Descritto le fasi della pipeline di rilascio intero, illustrato nella Figura 1. Una pipeline di rilascio, inserire sinteticamente, è come Ottiene trasformato in servizi e App pronti, codice che viene eseguito il commit in un repository di origine e quindi distribuito ai dispositivi di cliente e cliente accessibile server. Una pipeline di rilascio, essenzialmente, è semplicemente un elenco dei passaggi necessari stabilire un rilascio. In effetti, la pratica dei reparti di inizia con viene chiaramente la procedura esatta e i processi coinvolti in una versione. Da qui è relativamente facile eseguire in modo incrementale automatizzare i processi utilizzando strumenti nello stack DevOps Microsoft.

Figura 1 repository del controllo del codice sorgente è l'Input per la Pipeline di rilascio

Come illustrato nel primo articolo, è sempre necessario comprendere come eseguire questa operazione manualmente ogni passaggio in una pipeline di rilascio. Molti progetti di app Introduzione ai processi manuali, ad esempio manuale, per ottenere suggerimenti dai tester quanto prima possibile. Essere in grado di eseguire tutte le operazioni manualmente fornisce inoltre un fallback nel caso in cui una parte di una pipeline di rilascio automatizzati suddivide.

Tuttavia, i processi manuali sono costosi da scalare, soggetto a errori umani, spesso noioso e mettere a rischio di competizione per l'attenzione dei dipendenti con tutte le altre attività di ogni passaggio. Automazione, utilizzare un computer di eseguire tali attività, ovvero fornisce decisamente migliore scalabilità, affidabilità, la prevedibilità e controllo, ovvero una qualità più elevata a un costo inferiore. Automazione consente inoltre di liberare i dipendenti per le attività che necessita di intervento umano.

In questo articolo verrà esaminato un aspetto molto importante della pipeline di rilascio, che è probabilmente già occupato per scontati: controllo del codice sorgente. Codice sorgente del progetto costituisce l'input per la pipeline di rilascio, come descritto in Figura 1, e maggior parte degli sviluppatori accettare oggi stesso la gestione di codice in un sistema di controllo del codice sorgente come d'ufficio. Ma aiuta a comprendere meglio l'intera DevOps se è possibile visualizzare chiaramente che il controllo del codice sorgente ruolo essenziale svolto in tale contesto.

I motivi per cui controllo del codice sorgente

Automazione di una pipeline di rilascio il primo passaggio consiste nel gestire il codice in un repository di controllo del codice sorgente di qualche tipo. Anche in questo caso, il codice sorgente è l'input per la pipeline di rilascio e la fase successiva, compilazione, è ciò che converte il codice negli elementi che vengono quindi inseriti nel resto della pipeline. Per automatizzare il processo di compilazione, con l'integrazione continua in particolare, sistemi, ad esempio Visual Studio Team Services (servizi Team breve) devono essere in grado di rilevare quando vengono apportate modifiche al repository. Non è pertanto sufficiente gestire il codice sorgente semplicemente alcune cartella arbitraria sul disco rigido.

Nota: Se si dispone già di un account gratuito Team Services, crearne uno seguendo le istruzioni fornite in bit.ly/29xK3Oo. Ancora meglio, estrarre il programma di Visual Studio Dev Essentials (bit.ly/29xKCYq), che offre un account di servizi di Team e accedere facilmente a molti altri servizi, incluso il credito Azure 25 dollari per 12 mesi.

Parlerò in compilazione e l'integrazione continua nel prossimo articolo della serie. Di seguito si desidera concentrarsi in particolare nel controllo del codice sorgente, a partire da una breve revisione del motivo per cui è presente in primo luogo controllo del codice sorgente e il ruolo generale che viene riprodotto in DevOps nel suo complesso. Per questo motivo è evidenziare qualcosa che non può mai pensato sulla prima: Controllo del codice sorgente è fondamentalmente una forma di automazione.

Questa istruzione sembrare strano, ma, poiché gli sviluppatori oggi considera controllo del codice sorgente un determinato. Ma che non è sempre il caso. Probabilità sono utilizzati di progetti senza controllo del codice sorgente a un certo punto professionale, specialmente quando sono stati prima introduzione. In tali progetti, è probabile che fosse disponibile una cartella sul disco rigido locale contenente tutto il codice che si ottiene quando si crea un nuovo progetto di applicazione locale in Visual Studio. Da quel punto, si potrebbe avere eseguito una compilazione locale per generare i file eseguibili e ad necessari per la distribuzione, che è stato caricato manualmente in un server Web pubblico o forse condiviso con altri utenti su un supporto fisico.

In breve, controllo del codice sorgente è in alcun modo necessaria per creare un'applicazione pronta e i relativi servizi back-end. Ma solo una singola copia locale del codice sorgente con un numero di problemi e rischi, che ognuno dei quali immagino che hai scoperto direttamente:

• Se si arresta nel disco rigido, si potrebbero perdere tutti gli elementi.
• Una singola copia del codice sorgente non mantiene la cronologia modifiche, rendendo difficile ripristinare un precedente stato funzionante del progetto.
• Più persone lavorano il codice possono facilmente sovrascrivere le modifiche di altri o introdurre modifiche di rilievo, senza che la conoscenza.

È certamente possibile limitare tali rischi manualmente, in una certa misura. Backup regolari, ad esempio, consente di evitare la perdita di codice e fornire un certo grado di cronologia. Tuttavia, la natura nongranular dell'intero progetto backup rende molto difficile ripristinare solo le parti del progetto mentre intatte le altre modifiche. È inoltre possibile per gli utenti in un team di creare copie personale del codice per evitare conflitti, ma è particolarmente difficile da integrare tali copie insieme in uno stato funzionante. I membri del team possono anche comunicare modifiche di rilievo ad altri utenti tramite posta elettronica diretta o altri messaggi, ma diventa difficile eseguire in modo continuativo.

Naturalmente, come gli sviluppatori è in genere evitare tali oneri spesso è possibile. Al contrario, abbiamo trovato modo creativo per automatizzare queste attività, che è esattamente il controllo del codice sorgente è possibile.

In generale, controllo del codice sorgente indica quanto segue:

• Gestione di un repository condiviso di tutto il codice di progetto in un server, con un tipo di meccanismo di backup automatico.
• La registrazione delle modifiche in base al file, in modo da visualizzare l'intera cronologia per qualsiasi file specificato, nonché le modifiche in più file sottoposte a commit nel repository come gruppo. Questo rende semplice per associare gli errori di compilazione e test di regressione con modifiche specifiche e per ripristinare singoli file o gruppi di file a uno stato precedente, non solo lo stato dell'ultimo backup.
• Archiviare il codice in una posizione in cui un sistema di compilazione può rilevare le modifiche apportate al repository e automaticamente attivata una compilazione, ovvero eseguire un test di integrazione immediata (integrazione continuata) con tali modifiche.
• Gestione sovrascrivono quelli in conflitto tra più utenti, richiedendo agli sviluppatori di bloccare i file per l'accesso esclusivo mentre si lavora su di essi oppure mediante gli strumenti che è possono unire le modifiche e rilevare i conflitti automaticamente.
• L'invio di notifiche automatiche per gli sviluppatori interessati quando modificare determinati file o quando i conflitti di unione richiedono la risoluzione manuale.

In breve, controllo del codice sorgente automatizza gran parte dei processi noiosi mantenere un archivio affidabile e controllabile del codice del progetto. È essenziale per la gestione del codice di progetto per gli sviluppatori singoli e team e costituisce la base per una pipeline di rilascio automatizzati.

Opzioni di controllo codice sorgente

Non data la necessità di pervasiva di controllo del codice sorgente, è è una sorpresa che diversi sistemi si sono evolute nel corso degli anni. In questo caso, tuttavia, illustrerò i due che è possibile ospitare direttamente all'interno di servizi di Team: GIT e Team Foundation Version Control (TFVC). Hosting di un repository significa che è direttamente archiviati e gestiti all'interno dell'account di servizi di Team. Il sistema di compilazione Team Services è possibile creare anche da Git, GitHub e alla sottoversione repository esterni, nonché, quale parlerò nel prossimo articolo della serie.

Il sistema di controllo di origine desiderato per un progetto è una questione di preferenza, l'esperienza di considerazioni di team e i costi di sviluppo. GitHub, ad esempio, è disponibile per i repository pubblici, ma ha un costo per quelle private (vedere github.com/pricing). Repository GitHub pubblico sono aperte a tutti gli utenti per impostazione predefinita, motivo per cui aprire progetti di origine sono in genere ospitati in GitHub. Molti dei set di documenti di lavoro in Microsoft, ad esempio, vengono archiviati, tra cui l'intera raccolta di documentazione di Microsoft Azure (github.com/Azure/azure-content) e la documentazione di Visual Studio Tools per Apache Cordova (github.com/Microsoft/cordova-docs). Usare GitHub anche per un'ampia gamma di progetti di esempio singole, come nell'esempio di Altostratus (github.com/kraigb/Altostratus) visualizzato in MSDN Magazine ultimo anno (bit.ly/29mKHiC). Analogamente, si è scelto di GitHub per il progetto MyDriving (github.com/Azure-Samples/MyDriving) perché è stato utilizzato per aprire origine dall'inizio. (Per ulteriori informazioni su MyDriving generale, vedere aka.ms/iotsampleapp.)

Team Services, d'altra parte, è orientato verso archivi privati (Git o TFVC) per impostazione predefinita, il che significa che quando si crea un repository, sufficiente l'accesso. Per consentire l'accesso ad altri utenti, è necessario in particolare aggiungerli come membri del team (vedere bit.ly/29QDHql). Il vantaggio è che è possibile ospitare repository privati illimitati all'interno dell'account di servizi di Team gratuitamente per tutti gli abbonati MSDN come desiderato e i costi di avviare solo quando sono presenti più di cinque utenti senza gli abbonamenti MSDN. Per questi motivi, utilizzare servizi di Team per i progetti personali, ad esempio App ho negli app Store e per il codice si desidera condividere con solo a utenti specifici.

La principale differenza funzionale tra TFVC e Git si trova nei modelli origine rispettivo controllo. Un confronto completo sono disponibili nella documentazione di nell'argomento "Controllo della versione corretta per il progetto scegliendo" (bit.ly/29oZKTZ), ma mi consente di riepilogare.

TFVC, illustrato nella Figura 2, è centralizzata, il che significa che i file si trovano in un repository unico, centrale, di sola lettura, per cui l'amministratore è responsabile per i backup. Per funzionare con TFVC, è in genere mantenere una copia locale di sola lettura della versione più recente dei file dal repository (denominata un'area di lavoro), da cui è possibile eseguire le compilazioni e test dell'app. Per apportare modifiche, si estrae una o più file, che fornisce l'accesso esclusivo fino a quando tali file vengono controllati di nuovo (che è integrato nel repository). TFVC quindi unisce le modifiche nel repository. Se più sviluppatori estraggono lo stesso file contemporaneamente (che è consentito), TFVC rileva i conflitti di unione durante l'archiviazione e informa gli sviluppatori se è necessaria la risoluzione manuale.

Figura 2, le relazioni di controllo versione di base di Team Foundation

GIT è stata distribuita, pertanto anche se il repository principale si trova nell'host, è "clonare" l'intero repository (cronologia delle modifiche e tutti), svolgere il proprio lavoro localmente e quindi eseguire il commit modifiche completate per il clone come illustrato nella Figura 3 (vedere anche git-scm.com per informazioni dettagliate sui flussi di lavoro Git). Quando si è pronti per integrare le modifiche con qualsiasi altro lavoro, si invia "richieste pull" dal clone in master. In questo modello, ogni clone è effettivamente un backup del repository.

Figura 3, le relazioni di base Git

Si noti che sia Git che TFVC utilizzare alcune parole come "estrazione" simile per descrivere completamente diversi processi, che può confondere. È consigliabile utilizzare semplicemente ciascuno da se stesso e non prevede alcuna conoscenza di trasferimento tra i due.

Meccanismo di richiesta di pull del GIT è in grado di rilevare quando le modifiche possono essere unite automaticamente e quando è necessaria la risoluzione manuale. Naturalmente, in archivi pubblici come GitHub, non necessariamente desiderate tutti gli utenti e tutti gli utenti siano in grado di unire le richieste pull. In genere, solo determinati utenti disporranno dell'autorizzazione per unire le richieste pull, che si comporta come un custode per l'integrità del repository nel suo complesso.

Ad esempio, esaminare nella parte superiore del repository MyDriving in github.com/Azure-Samples/MyDriving si noterà che le richieste Pull (vedere Figura 4). Facendo clic su che viene aperto richieste in attesa per la moderazione da utenti con autorizzazioni di tipo merge. È anche possibile esaminare l'intera cronologia delle richieste di pull facendo clic sulla scheda chiusa nell'elenco.

Elenco delle richieste Pull figura 4 su GitHub per il progetto MyDriving

TFVC e Git supporto cosiddetta diramazione, che essenzialmente prevede la creazione di un altro livello tra il repository principale o centrale e gli altri cloni o copie. In questo modo i sottogruppi di (sviluppatori e tester) per le operazioni significative in quel ramo senza influire sul repository master. Un ramo inoltre mantiene la propria cronologia di modifica e, nel caso di Git, gestisce le proprie richieste pull da ogni clone. Solo quando il team è pronto per integrare il lavoro nel branch master di inviare una richiesta di pull in master. Per ulteriori informazioni, vedere "Utilizzo branch per isolare il rischio in TFVC" (bit.ly/29ndlQz) e "Creare lavoro in branch" (bit.ly/29VVmgY) nella documentazione.

Comunicazione e controllo

In Git e TFVC e nell'origine sistemi di controllo in genere, le archiviazioni, pull richieste e così via disponga di un meccanismo di commenti associato. Che viene illustrato come passare le modifiche apportate a tutti gli utenti else lavorando alla creazione del progetto e come i team possono discutere le modifiche. Questi sistemi forniscono in genere anche le notifiche e le discussioni più ampia dei problemi (come risolti), gli elementi di lavoro e così via.

Su GitHub, ad esempio, si includono commenti con ogni commit codice per il clone e quindi apportare commenti aggiuntivi quando si invia una richiesta di pull. I responsabili del controllo e che la richiesta di unione può lasciare commenti o domande all'interno della richiesta di pull, specialmente se essi trovare problemi potenziali con il nuovo codice. Se si fa clic nell'elenco delle richieste pull chiuso nel repository MyDriving menzionato in precedenza, è possibile visualizzare una vasta gamma di esempi. Analogamente, fare clic sulla scheda problemi nella home page per visualizzare altre discussioni. Per le notifiche, vengono gestite tramite le impostazioni personali nella sezione notifiche.

Servizi di team, da parte sua, dispone di un intero sistema per tenere traccia di elementi di lavoro, bug e così via, per ulteriori informazioni nella sezione della documentazione di servizi di Team Agile strumenti (bit.ly/29tvKIE). All'interno di un repository di codice (se Git o TFVC), è disponibile un controllo commenti diffuso, come illustrato nella Figura 5, che consente ai membri del team lasciare note su insiemi di modifiche (gruppi di modifiche), singoli file e così via.

Figura 5, l'interfaccia utente per un insieme di modifiche in Visual Studio Team dei servizi, con il pulsante commenti

Questi commenti, insieme a dettagli specifici delle modifiche apportate ai quali file, tutti inserito nella cronologia del repository o registro delle modifiche. La disponibilità di un vasto dettagliate della cronologia di chi ha apportato le modifiche all'ora, insieme a una discussione che si sono verificati quasi tali modifiche, è uno dei principali vantaggi dell'utilizzo di un sistema di controllo del codice sorgente. La cronologia rende l'intero repository controllabili nel tempo. Se presenterà un problema imprevisto in un secondo momento nella pipeline del rilascio, ad esempio regressioni individuati tramite unità, integrazione o di test dell'interfaccia utente, è facile tornare indietro e visualizzare le modifiche specifiche in un file specifico che ha causato la regressione.

Esecuzione di processo "semplice" è effettivamente molto importante in caso di DevOps nel suo complesso. Ricordare il primo articolo di questa serie che ho parlato DevOps come la convalida continua delle prestazioni per un'applicazione e i servizi, dove "performance" include sia l'esperienza dei clienti e i costi di produzione. Capacità di rilevare difetti più presto possibile nella versione pipeline consente di ridurre al minimo i costi. Altrettanto importante è il tempo necessario per individuare esattamente dove, sia effettivamente presente un difetto, rapidità meglio! In effetti, probabilmente sarà capitato l'esperienza di sprecare molti giorni frustranti per tenere traccia di un bug in un progetto, e scoprire che la correzione ha impiegato tutti di 10 secondi. In questi casi, quasi tutti i costi provengono semplicemente individuato il bug.

Questo è un aspetto molto importante se è o chiunque nel team di oggetti di controllo del codice sorgente, anziché semplicemente "winging", mantenendo il codice in alcuni condivisione di rete semplice. Il minimo di investimento apportate mediante l'adozione di un sistema di controllo del codice sorgente paga dividendi enorme per tutta la durata del progetto, soprattutto quando combinati con compilazioni automatizzate, integrazione continua e test automatizzati, come si vedrà in futuro gli articoli. Integrazione continuata significa che ogni modifica del codice attiva una compilazione automatica e viene eseguito i test automatizzati, pertanto se tale modifica codice impedisce qualsiasi tipo di errore (compilazione o test), si è consapevoli entro pochi minuti.

I progetti team e più repository

Per creare una pipeline di rilascio automatizzati per le app e i servizi all'interno di Team Foundation Server (TFS) o servizi di Team, iniziare con ciò che viene definito un progetto team. Un progetto team è il contenitore per tutto il Team Services, inclusi la pianificazione, elementi di lavoro, la collaborazione tramite chat team, le compilazioni, integrazione continua, la gestione dei test, gestione del rilascio e repository di controllo di origine. Dico "repository" qui perché un progetto team direttamente può ospitare più repository e il sistema di compilazione Team Services è possibile inoltre disegnare dal repository Git, GitHub e alla sottoversione esterni. (In modo analogo, TFS può disegnare da un repository ospitato in Team Services e viceversa).

Si noti che un progetto team non deve essere confuso con un progetto di Visual Studio o una soluzione; è possibile disporre di molte soluzioni di Visual Studio, insieme a qualsiasi altro codice da qualsiasi altro sistema di sviluppo, tutto all'interno dello stesso progetto team. Per questo motivo, mi piace pensare a un progetto team come casella tesoro DevOps — questo mi consente di evitare confusione tra i termini e mi viene ricordato di tutte le funzionalità DevOps può inoltre gestire!

Per creare un progetto team, accedere al portale di servizi di Team e fare clic su nuovo in progetti e team recenti. Il nuovo comando viene visualizzata una finestra di dialogo in cui si seleziona Git o TFVC come modello di controllo di origine per il repository predefinito del progetto. Si tratta semplicemente per comodità. Se si seleziona TFVC, è possibile creare repository Git in un secondo momento, come si vedrà a breve; Se si seleziona Git, è possibile aggiungere un repository TFVC in un secondo momento con più repository Git. E se si preferisce utilizzare un host esterno come GitHub, non verranno utilizzate in qualsiasi repository predefinito e questa scelta è irrilevante. Ad esempio, quando si configura un progetto team per MyDriving, Git è stato selezionato per l'archivio predefinito, ma tutto ciò che è presente è un file Leggimi file poiché il progetto real è ospitato interamente su GitHub.

Per mostrare come un singolo progetto team può gestire più repository, ho creato un progetto di esempio nel mio account di servizi di Team e TFVC selezionato. Scheda del codice del progetto viene visualizzato come illustrato nella Figura 6. Facendo clic sul controllo contorno Mostra l'elenco di repository esistente nel progetto Team, insieme al nuovo repository e i comandi di Gestione archivi. Il nuovo comando viene visualizzata una finestra di dialogo in cui nuovamente selezionare tra TFVC e Git. Poiché il progetto team è stato creato inizialmente con TFVC, non è possibile creare un altro repository TFVC (è consentito solo uno), ma è possibile creare un numero qualsiasi di altri repository Git, come illustrato nella Figura 7.

Figura 6 la scheda del codice per un nuovo progetto utilizzando Team Foundation Version Control

Figura 7 del progetto Team con più repository Git e Repository di controllo versione di un Team Foundation

Il comando di Gestione archivi andare al pannello di controllo servizi Team in cui è possibile visualizzare tutti i repository (e rami Git) in una sola volta; rinominare o eliminare. e gestire le autorizzazioni di accesso. Per tutti i dettagli per gli utenti, gruppi e autorizzazioni, troppo numerosi per essere trattati, consultare la documentazione per "Autorizzazioni e gruppi in servizi di Team" (bit.ly/29nxvpd) nelle sezioni "TFVC" e "repository Git". Basti si dire che è possibile esercitare un controllo molto dettagliato sulle autorizzazioni per tutti i membri del team. Naturalmente, se si utilizza un sistema di controllo di origine esterna come GitHub, si saranno gestire le autorizzazioni per tale sito. Si noti tuttavia che le autorizzazioni per il team di progetto nel suo complesso e non il repository, vengono gestite tramite la scheda protezione visualizzata nell'interfaccia utente. Sono inoltre disponibili i dettagli nella stessa pagina di documentazione indicata in precedenza (bit.ly/29nxvpd).

Popolamento di un Repository di servizi di Team con il codice

Dopo aver creato un repository, la mia domanda modo è possibile ottenere il codice al suo interno. Servizi Team offre vari modi, come avviene con Visual Studio, in modo per chiudere questo articolo ora, eseguo brevemente tramite queste opzioni.

Per un repository TVFC, è possibile innanzitutto caricare i file nel repository o creare nuovi file direttamente tramite il portale di servizi di Team. Selezionare innanzitutto la scheda del codice nel progetto team, quindi fare clic su di... accanto il repository e selezionare + Aggiungi file, come illustrato nella Figura 8. Verrà visualizzata una finestra di dialogo (non mostrata) attraverso il quale si può creare file e modificarli direttamente nel portale o creare un elenco di file da caricare. Nel secondo caso è inoltre possibile includere un commento di archiviazione.

Figura 8 comando Services Team di Visual Studio per aggiungere file a un Repository di controllo versione di Team Foundation

L'altro modo per aggiungere codice a un repository TFVC è tramite Esplora soluzioni di Visual Studio. Questo è un modo pratico per eseguire una soluzione locale e trasferire tutto il codice nel controllo del codice sorgente. È sufficiente fare doppio clic la soluzione e selezionare Aggiungi soluzione al controllo del codice sorgente, come illustrato nella Figura 9. Verrà visualizzata una finestra di dialogo in cui è possibile selezionare il progetto team appropriato all'interno dell'account di servizi di Team o su un computer TFS specifico. Per connettersi a un server che potrebbe essere necessario eseguire inizialmente, usare Team Explorer in Visual Studio (descritta nella parte inferiore della scheda Figura 9). Per informazioni dettagliate, vedere l'argomento "Lavoro in Team Explorer" nella documentazione di Visual Studio (bit.ly/29oGp5j).

Figura 9 aggiunta di una soluzione al controllo del codice sorgente in Visual Studio

Per i repository Git, Team Services richiederà automaticamente con una varietà di opzioni quando si crea il repository o spostarsi nella scheda del codice, un'interfaccia utente che parla sufficientemente per se stesso. In alternativa, è possibile creare un repository Git in Visual Studio e quindi pubblicarla in un repository in servizi di Team. Non analizzerò questo processo in dettaglio in questo caso, poiché è ben documentata nell'argomento "Condivisione del codice con Git e Visual Studio" (bit.ly/29VDYJg). Breve, tuttavia, è possibile fare clic sul pulsante pubblica in basso a destra della barra di stato di Visual Studio, il quale viene visualizzata la scheda pubblica di Team Explorer come illustrato nella Figura 10. Qui è possibile selezionare l'account di servizi di Team da utilizzare. Un dettaglio importante fa clic sul piccolo testo avanzato per selezionare un progetto team, come illustrato. Come può vedere inoltre la stessa interfaccia utente fornisce un percorso di facile per la pubblicazione di codice in GitHub e ad altri repository esterno, nonché.

Figura 10 la pubblicazione dell'interfaccia utente in Visual Studio

Sviluppi futuri

Con un repository di controllo di origine sul posto, si è ora pronti per eseguire il passaggio successivo l'automazione si basa la pipeline del rilascio mediante l'impostazione e l'integrazione continuata. Ovvero ne tratterò nel mio prossimo articolo, dove vengono visualizzate come possibile tracciare qualsiasi definizione di compilazione specificata all'interno di Visual Studio Team servizi da qualsiasi repository di origine controllo trattati. Un progetto team, inoltre, è possibile gestire un numero qualsiasi di tali definizioni di compilazione, vale a dire che coordina il progetto team build da un numero qualsiasi di repository per produrre il eventualmente gli elementi necessari per il resto della pipeline di rilascio o di pipeline.

---

Kraig Brockschmidt funziona come uno sviluppatore di contenuti senior per Microsoft ed è incentrato su DevOps per le applicazioni mobili.  È l'autore di "Applicazioni di programmazione Windows Store con HTML, CSS e JavaScript" (due edizioni) da Microsoft Press e blog su kraigbrockschmidt.com.

Grazie a seguenti esperti tecnici per la revisione dell'articolo: Donovan Brown e Gordon Hogenson