---

Septembre 2016

Volume 31, numéro 9

Cet article a fait l'objet d'une traduction automatique.

Mobile DevOps - La source fiable : le rôle des référentiels dans DevOps

Par Kraig Brockschmidt | Septembre 2016

Le premier article de cette série, « à partir du Code client : Exploration des opérations de développement Mobile » (msdn.com/magazine/mt767694), introduite le DevOps Microsoft de pile pour les applications mobiles et services back-end. Il décrit les étapes du pipeline de version entière, illustré Figure 1. Un pipeline de versions, placer de manière succincte, est comment le code qui est allouée à un référentiel source obtient transformé en services et applications de prêts et puis remis à des périphériques clients et serveurs accessibles par le client. Un pipeline de versions, fondamentalement, est simplement une liste des étapes nécessaires faire une version. En effet, la pratique de DevOps commence par avoir été clair sur les étapes et les processus impliqués dans une version. À partir de là, il est relativement facile de façon incrémentielle automatiser des processus à l’aide d’outils de la pile Microsoft DevOps.

Figure 1 le référentiel de contrôle de code Source est l’entrée du Pipeline de versions

Comme indiqué dans le premier article, vous devez toujours comprendre comment effectuer chaque étape d’un pipeline de versions manuellement. De nombreux projets d’application prise en main des processus manuels, telles que des builds de manuel, pour obtenir des commentaires des testeurs aussi tôt que possible. Savoir comment le faire manuellement fournit également une stratégie de secours au cas où une partie d’un pipeline de version automatisés tombe en panne.

Toutefois, les processus manuels sont coûteux à l’échelle, sujet aux erreurs humaines, souvent fastidieuse et menacée chaque étape de la concurrence à l’attention de vos employés avec leurs autres tâches. Automation, soit un ordinateur d’effectuer ces tâches, fournit une bien meilleure mise à l’échelle, la fiabilité, la prévisibilité et l’audit, ce qui signifie une qualité supérieure à moindre coût. Automation libère également vos employés pour les tâches que vous avez vraiment besoin attention humaine.

Dans cet article, j’explorerai un aspect essentiel du pipeline de versions, qui est probablement prise pour acquise : contrôle de code source. Code source d’un projet est l’entrée du pipeline de versions, comme indiqué dans Figure 1, et la plupart des développeurs accepter aujourd'hui du code de gestion dans un système de contrôle de code source comme bien entendu. Mais il vous aide à mieux comprendre l’ensemble des opérations de développement si vous pouvez voir clairement que le contrôle de source de rôle essentiel joue dans ce contexte.

Les raisons de contrôle de code Source

La première étape dans l’automatisation d’un pipeline de version consiste à gérer votre code dans un référentiel de contrôle source quelconque. Là encore, le code source est l’entrée du pipeline de versions et l’étape suivante, la Build, est que convertit ce code dans les artefacts qui sont ensuite intégrés dans le reste du pipeline. Pour automatiser le processus de génération, avec une intégration continue en particulier, les systèmes tels que Visual Studio Team Services (Services d’équipe en abrégé) doivent être en mesure de détecter lorsque des modifications sont apportées à ce référentiel. Par conséquent, il n’est pas suffisante pour gérer votre code source simplement dans un dossier arbitraire sur votre disque dur.

Remarque : Si vous ne disposez pas d’un compte Microsoft gratuit, en créer un en suivant les instructions fournies dans bit.ly/29xK3Oo. Encore mieux, consultez le programme Essentials de développement Visual Studio (bit.ly/29xKCYq), qui vous donne un compte de Services de l’équipe avec un accès facile aux autres services, y compris les 25 $ de crédit Azure pendant 12 mois.

Je vais parler de génération et d’intégration continue dans l’article suivant de la série. Ici je souhaite me concentrer plus particulièrement sur le contrôle de code source, commençant par une brève présentation des pourquoi le contrôle de code source existe en premier lieu et le rôle général dans DevOps dans son ensemble. Mon fait pour faire remarquer que quelque chose que peut ne jamais avoir pensé à avant : Contrôle de code source est fondamentalement un formulaire d’automation.

Cette instruction peut vous surprendre, car la plupart des développeurs envisager dès aujourd'hui le contrôle de code source une donnée. Mais ce n’était pas toujours le cas. Sans doute que vous avez travaillé sur des projets sans contrôle de code source à un moment donné dans votre carrière, surtout lorsque vous ont été tout d’abord mise en route. Dans ces projets, il est probable qu’était simplement un dossier sur votre disque dur local contenant tout votre code, qui est ce que vous obtenez lorsque vous créez un nouveau projet d’application local dans Visual Studio. À partir de là, vous avez peut-être exécuté une build locale afin de produire des fichiers exécutables et telles nécessaires pour distribution, que vous pouvez ensuite téléchargé manuellement sur un serveur Web public ou éventuellement partagé avec d’autres utilisateurs sur des supports physiques.

En bref, contrôle de code source n’est absolument nécessaire pour produire une application de prêts et de ses services back-end. Mais uniquement une copie locale de votre code source possède un nombre de problèmes et risques, que qui j’imagine que vous avez rencontré directement :

• Si votre disque dur tombe en panne, vous risquez de perdre tout.
• Une seule copie du code source ne conserve un historique des modifications, rend très difficile de revenir à un état antérieur de travail du projet.
• Plusieurs personnes travaillent sur le code peuvent facilement remplacer d’autres modifications, ou introduire de modifications avec rupture, sans que quiconque connaissant.

Il est certainement possible d’atténuer ces risques manuellement, dans une certaine mesure. Des sauvegardes régulières, par exemple, vous aider à se prémunir contre la perte de code et de fournir un certain degré d’historique. Toutefois, la nature nongranular du projet de l’ensemble des sauvegardes rend très difficile de restaurer uniquement les parties du projet tout en conservant les autres modifications. Il est également possible pour les personnes de l’équipe d’effectuer des copies personnelles du code pour éviter les conflits, mais il est ensuite exceptionnellement fastidieux à intégrer ces copies dans un état de fonctionnement. Membres de l’équipe peuvent également communiquer des modifications avec rupture à d’autres personnes par courrier électronique direct ou autres échanges, mais cela devient lourdes à effectuer sur une base cohérente.

Bien sûr, en tant que développeurs nous généralement éviter ces charges aussi souvent que possible. Au lieu de cela, nous trouvons manières créatives pour automatiser ces tâches, ce qui est exactement le contrôle de code source est.

À un niveau élevé, contrôle de code source, les produits suivants :

• Maintenir un référentiel partagé de tout code de projet sur un serveur, avec une sorte de mécanisme de sauvegarde automatique.
• Enregistrement des modifications sur une base par fichier, afin de voir l’historique complet d’un fichier donné, ainsi que des modifications de plusieurs fichiers qui ont été validées dans le référentiel en tant que groupe. Cela facilite pour associer des échecs de génération et de tester les régressions des changements spécifiques et pour restaurer des fichiers individuels ou des groupes de fichiers à un état antérieur, non seulement l’état de la dernière sauvegarde.
• Le stockage du code dans un endroit où un système de génération peut détecter les modifications apportées au référentiel et déclencher automatiquement une build, ce qui signifie l’exécution d’un test d’intégration immédiate (intégration continue) avec ces modifications.
• Gestion remplace et entre en conflit entre plusieurs utilisateurs, en demandant aux développeurs de verrouiller les fichiers pour un accès exclusif pendant qu’ils travaillent sur les ou disposer d’outils qui peuvent automatiquement fusionner les modifications et détecter des conflits.
• Envoi de notifications automatiques pour les développeurs intéressés lorsque certains fichiers changent, ou lorsque les conflits de fusion nécessitent une résolution manuelle.

En bref, contrôle de code source automatise une grande partie des processus fastidieux impliquées dans la maintenance d’un référentiel fiable et contrôlable de code d’un projet. Il est essentiel pour la gestion de code de projet pour les développeurs uniques et les équipes de traducteurs et constitue la base d’un pipeline de versions automatisée.

Options de contrôle de code source

Étant donné la nécessité de moyens de contrôle de code source, il n’est pas surprenant que différents systèmes ont évolué au fil des années. Dans ce cas, cependant, j’aborderai les deux, que vous pouvez héberger directement dans les Services de l’équipe : GIT et contrôle de Version Team Foundation (TFVC). Hébergement d’un référentiel signifie qu’il a directement stockés et gérés au sein de votre compte de Services de l’équipe. Le système de génération Team Services peut également dessiner dans Git, GitHub et la sous-version référentiels externes, ainsi, dont je parlerai dans l’article suivant de la série.

Quel système de contrôle source que vous choisissez pour un projet est vraiment une question de préférence, l’expérience de vos considérations d’équipe et le coût de développement. GitHub, par exemple, est gratuit pour les référentiels public, mais a un coût pour les privés (consultez github.com/pricing). Public référentiels GitHub sont ouverts à tous les utilisateurs par défaut, c’est pourquoi Ouvrir projets source sont typiquement hébergés sur GitHub. La plupart des jeux de documentation travailler sur chez Microsoft, par exemple, sont stockés, y compris l’ensemble de documentation de Microsoft Azure (github.com/Azure/azure-content) et de la documentation pour Visual Studio Tools for Apache Cordova (github.com/Microsoft/cordova-docs). J’utilise également GitHub pour divers projets d’exemples individuels, comme l’exemple Altostratus (github.com/kraigb/Altostratus) qui apparaît dans le Magazine MSDN année dernière (bit.ly/29mKHiC). De même, j’ai choisi GitHub du projet MyDriving (github.com/Azure-Samples/MyDriving) car il a été conçu pour être open source à partir du début. (Pour plus d’informations sur MyDriving globale, consultez aka.ms/iotsampleapp.)

Team Services, en revanche, est orienté vers les référentiels privés (Git ou TFVC) par défaut, ce qui signifie que lorsque vous créez un référentiel, vous seul avez accès. Pour donner accès à d’autres personnes, vous devez les ajouter en particulier en tant que membres de l’équipe (voir bit.ly/29QDHql). L’avantage est que vous pouvez héberger des référentiels privés illimités dans votre compte Team Services gratuitement pour les abonnés MSDN autant que vous voulez, et les coûts uniquement active lorsque vous avez plus de cinq utilisateurs sans les abonnements MSDN. Pour ces raisons, j’utilise les Services d’équipe pour les projets personnels, tels que les applications que j’ai dans les magasins d’applications et pour le code que je souhaite partager avec des personnes spécifiques uniquement.

La principale différence fonctionnelle entre Git et TFVC réside dans leurs modèles de contrôle source respectifs. Vous trouverez une comparaison complète dans la documentation dans la rubrique « Choisir le contrôle de version appropriée pour votre projet » (bit.ly/29oZKTZ), mais laissez-moi résumer.

TFVC, illustré dans Figure 2, est centralisée, ce qui signifie que les fichiers résident dans un référentiel unique, centralisé et en lecture seule, pour laquelle l’administrateur est chargé de sauvegardes. Pour fonctionner avec TFVC, généralement pour conserver une copie en lecture seule locale de la dernière version des fichiers à partir du référentiel (appelée espace de travail), à partir de laquelle vous pouvez exécuter des builds et tester l’application. Pour apporter des modifications, vous retirez un ou plusieurs fichiers, ce qui vous donne un accès exclusif jusqu'à ce que ces fichiers sont archivés vers l’arrière dans (qui est, intégré dans le référentiel). TFVC fusionne ensuite les modifications dans le référentiel. Si plusieurs développeurs extraient le même fichier simultanément (qui est autorisé), TFVC détecte les conflits de fusion sur archivage et informe les développeurs si la résolution manuelle est nécessaire.

Figure 2 les relations de contrôle de Version base de Team Foundation

GIT est distribué, ce qui signifie que bien que le référentiel principal réside sur l’ordinateur hôte, vous « clonez » l’intégralité du référentiel (historique des modifications et tous), travaillez localement puis validez les modifications apportées dans le clone comme illustré dans Figure 3 (voir aussi git-SCM.com pour plus d’informations sur les flux de travail Git). Lorsque vous êtes prêt à intégrer les modifications avec du tout le monde travail, vous envoyez « requêtes d’extraction » à partir de votre clone dans le masque. Dans ce modèle, chaque clone est effectivement une sauvegarde du référentiel.

Figure 3 les relations de base Git

Notez que Git et TFVC utilisent certains mots similaires comme « extraction » pour décrire complètement différents processus, ce qui peut prêter à confusion. Il est préférable de simplement travailler avec chacun d’eux par lui-même et n’attend pas de transfert des connaissances entre les deux.

Mécanisme de demande d’extraction de GIT est en mesure de détecter les modifications peuvent être fusionnées automatiquement et une résolution manuelle est nécessaire. Bien sûr, dans les référentiels publiques telles que GitHub, vous ne souhaitez pas nécessairement tout le monde et tout le monde de pouvoir fusionner des requêtes d’extraction. En règle générale, seules certaines personnes seront autorisé à fusionner des requêtes d’extraction, qui se comportent ensuite comme opérateurs de contrôle de l’intégrité du référentiel dans son ensemble.

Par exemple, un coup de œil en haut du référentiel MyDriving à github.com/Azure-Samples/MyDriving et vous verrez la demande d’extraction (voir Figure 4). En cliquant sur que présente actuellement ouvert les demandes en attente de modération par les utilisateurs autorisés de fusion. Vous pouvez également consulter l’historique complet des requêtes d’extraction en cliquant sur l’onglet fermé dans la liste.

Liste des requêtes d’extraction figure 4 sur GitHub du projet MyDriving

TFVC et Git prise en charge ce que l'on appelle le branchement, ce qui signifie essentiellement que la création d’une autre couche entre le référentiel principal ou central et des clones ou des copies. Ainsi, les sous-groupes de développeurs (et les testeurs) pour effectuer un travail considérable dans cette branche sans affecter le référentiel principal. Une branche également gère son propre historique des modifications et, dans le cas de Git, gère ses propres requêtes d’extraction à partir de chaque clone. Uniquement lorsque cette équipe est prête à intégrer le travail dans la branche avec le maître de qu’ils envoient une requête d’extraction dans le masque. Pour plus d’informations, consultez « Utilisation branches pour isoler les risques dans TFVC » (bit.ly/29ndlQz) et « Créer le travail dans les branches » (bit.ly/29VVmgY) dans la documentation.

Communication et audit

Dans Git et TFVC et dans la source de systèmes de contrôle en général, les archivages, extraire des requêtes et ainsi de suite ont tous un mécanisme de commentaire associé. Voilà comment vous communiquez les modifications apportées à tout le monde autre travaille sur le projet, et comment les équipes peuvent discuter de ces modifications. Ces systèmes généralement fournissent également des notifications et des discussions sur les questions plus vastes (comme les bogues ouverts), des éléments de travail et ainsi de suite.

Sur GitHub, par exemple, vous incluez des commentaires à chaque code de validation à votre clone et apportez ensuite des commentaires supplémentaires lors de l’envoi d’une requête d’extraction. Les responsables de la vérification et la fusion de cette demande peuvent alors laisser des commentaires ou questions au sein de la requête d’extraction, surtout si elles rechercher des problèmes potentiels avec le nouveau code. Vous pouvez voir plusieurs exemples si vous cliquez dans la liste de demandes d’extraction fermé dans le référentiel MyDriving mentionné précédemment. De même, cliquez sur l’onglet problèmes sur la page d’accueil pour afficher plus de discussions. Comme pour les notifications, celles-ci sont gérées via vos paramètres personnels dans la section Notifications.

Services de l’équipe, pour sa part, a un système entier pour le suivi des éléments de travail, bogues et ainsi de suite, vous pouvez consulter dans la section Outils Agile de la documentation des Services de l’équipe (bit.ly/29tvKIE). Au sein d’un référentiel de code (si Git ou TFVC), il existe un contrôle de commentaire omniprésent, comme indiqué dans Figure 5, qui permet aux membres équipe rédiger des notes sur les ensembles de modifications des fichiers individuels (groupes de modifications), et ainsi de suite.

Figure 5 l’interface utilisateur pour un ensemble de modifications dans Visual Studio Team Services, montrant le bouton commentaire

Ces commentaires, ainsi que des détails spécifiques sur les modifications apportées à quels fichiers, tout passe dans l’historique du référentiel ou journal des modifications. Ayant une étendue détaillée de l’historique de qui a apporté les modifications à un moment donné, ainsi que toute discussion survenu ces modifications, est un des avantages principaux de l’utilisation d’un système de contrôle de code source. L’historique rend l’intégralité du référentiel pouvant être dans le temps. Si vous rencontrez des problèmes inattendus plus tard dans le pipeline de version, tels que les régressions sont révélées par unité, intégration ou test de l’interface utilisateur, il est facile de revenir en arrière et afficher les modifications spécifiques dans un fichier particulier qui a provoqué cette régression.

Vous que processus « simple » est en fait très important qui concerne les opérations de développement dans son ensemble. Rappelez-vous que dans le premier article de cette série que j’ai parlé DevOps comme validation continue des performances pour une application et les services, où « performances » incluent l’expérience du client et le coût de production. La possibilité de découvrir des défauts dès que possible dans le pipeline de version vous aide à afin de réduire les coûts. Le temps nécessaire pour identifier où, exactement est tout aussi important, un défaut existe réellement, plus rapide ! En effet, vous avez probablement eu l’expérience de passer le nombre de jours frustrant pour rechercher un bogue dans un projet, pour découvrir que le correctif a pris toutes les 10 secondes. Dans ce cas, la quasi-totalité le coût provenance simplement rechercher le bogue.

Il s’agit d’un point très important si vous ou un utilisateur de votre équipe les objets à l’aide du contrôle de code source, plutôt que simplement « avance » en conservant votre code sur un partage réseau simple. Le peu de vos investissements en adoptant un système de contrôle source paie rentabilisera de lui-même sur la durée de vie du projet, en particulier lorsque associés à des générations automatisées, l’intégration continue et les tests automatisés, comme vous le verrez dans les futures articles. Intégration continue signifie que chaque modification de code déclenche une génération automatique et qu’il exécute les tests automatisés, donc si cette modification de code empêche tout type de défaillance (build ou test), vous savez à ce sujet dans les minutes.

Les projets d’équipe et plusieurs référentiels

Pour créer un pipeline de versions automatisée pour votre application et les services au sein des Services de l’équipe ou de Team Foundation Server (TFS), vous commencez avec ce que l'on appelle un projet d’équipe. Un projet d’équipe est le conteneur pour tout ce que vous dans Team Services, y compris la planification, le suivi, collaboration via les salles de réunion, des éléments de travail génère, intégration continue, gestion des tests, gestion des versions et des référentiels de contrôle source. Je dis « référentiel » ici, car un projet d’équipe peut héberger directement plusieurs référentiels, et le système de génération Team Services peut également extraire des référentiels Git, GitHub et la sous-version externes. (De même, TFS peut dessiner à partir d’un référentiel hébergé dans les Services de l’équipe et vice versa).

Notez qu’un projet d’équipe ne doit pas être confondu avec un projet Visual Studio ou une solution ; Vous pouvez avoir autant de solutions de Visual Studio, ainsi que tout autre code à partir de n’importe quel autre système de développement, dans le même projet d’équipe. Pour cette raison, j’aime considérer un projet d’équipe comme une zone de Trésor DevOps, cela me permet d’éviter toute confusion entre les termes et me rappelle tous les outils DevOps qu’il peut gérer !

Pour créer un projet d’équipe, connectez-vous au portail de Services de l’équipe, puis cliquez sur Nouveau sous projets et équipes récents. La nouvelle commande affiche une boîte de dialogue dans laquelle vous sélectionnez Git ou TFVC que le modèle de contrôle de source pour l’espace de stockage par défaut du projet. Il s’agit simplement par commodité. Si vous sélectionnez TFVC, vous pouvez créer des référentiels Git ultérieurement, comme vous le verrez bientôt ; Si vous sélectionnez Git, vous pouvez ajouter un référentiel TFVC ultérieurement avec plusieurs référentiels Git. Et si vous préférez utiliser un hôte externe comme GitHub, vous n’utilisez pas du tout le référentiel par défaut et ce choix est sans importance. Par exemple, lors de configurer un projet d’équipe pour MyDriving, j’ai sélectionné Git pour le référentiel par défaut, mais tout est là est un fichier Lisezmoi par défaut de fichiers, car le projet réel est hébergé entièrement sur GitHub.

Pour montrer comment un seul projet d’équipe peut gérer plusieurs référentiels, j’ai créé un exemple de projet dans mon propre compte Team Services et des TFVC sélectionné. Onglet de Code de ce projet s’affiche initialement comme indiqué dans Figure 6. En cliquant sur le contrôle avec contour affiche la liste des référentiels existants dans le projet d’équipe, ainsi que les commandes de référentiels de gérer et le nouveau référentiel. La nouvelle commande, une boîte de dialogue où vous ne sélectionnez pas entre Git et TFVC. Étant donné que j’ai créé le projet d’équipe avec TFVC, Impossible de créer un autre référentiel TFVC (seule est autorisée), mais je peux créer n’importe quel nombre de référentiels Git supplémentaires, comme indiqué dans Figure 7.

Figure 6 l’onglet Code pour un nouveau projet à l’aide du contrôle de Version Team Foundation

Figure 7 projet d’équipe avec plusieurs référentiels Git et référentiel de contrôle de Version un Team Foundation

La commande de référentiels gérer vous amène à l’équipe Services du panneau dans lequel vous pouvez voir tous les référentiels (et les branches Git) à la fois ; renommer ou les supprimer ; et de gérer les autorisations d’accès. Pour tous les détails autour des utilisateurs, groupes et autorisations — trop pour couvrir ici, reportez-vous à la documentation pour « Autorisations et les groupes dans les Services de l’équipe » (bit.ly/29nxvpd) dans les sections de « TFVC » et le « Référentiel Git ». Il suffit de dire que vous pouvez exercer un contrôle précis sur les autorisations pour chacun de vos membres d’équipe. Bien sûr, si vous utilisez un système de contrôle de source externe, comme GitHub, vous allez gérer les autorisations sur ce site à la place. Toutefois, notez que les autorisations pour l’équipe du projet dans son ensemble et non des référentiels, sont gérés via l’onglet sécurité indiqué dans cette interface utilisateur. Vous trouverez également ces informations dans la même page de documentation indiquée plus haut (bit.ly/29nxvpd).

Remplissage d’un référentiel de Services d’équipe avec le Code

Une fois que vous avez créé un référentiel, la question est comment obtenir votre code dans celui-ci. Team Services vous offre divers moyens, comme Visual Studio, donc pour fermer cet article je vais exécuter brièvement ces options.

Pour un référentiel TVFC, vous pouvez télécharger des fichiers dans le référentiel ou créer de nouveaux fichiers directement via le portail de Services de l’équipe. Recherchez tout d’abord l’onglet Code dans le projet d’équipe, puis cliquez sur le... en regard de l’espace de stockage et sélectionnez + Ajouter des fichiers, comme indiqué dans Figure 8. Ceci fait apparaître une boîte de dialogue (non illustrée) par le biais duquel vous pouvez créer des fichiers et les modifier directement dans le portail ou créer une liste des fichiers à télécharger. Dans ce cas vous permet également d’inclure un commentaire d’archivage.

Figure 8 Visual Studio Team Services commande pour ajouter des fichiers à un référentiel de contrôle de Version Team Foundation

L’autre méthode pour ajouter du code à un référentiel TFVC consiste via l’Explorateur de solutions Visual Studio. Il s’agit d’un moyen très pratique pour prendre une solution locale et transférer tout le code dans le contrôle de code source. Simplement avec le bouton droit de la solution et sélectionnez Ajouter la Solution au contrôle de code Source, comme indiqué dans Figure 9. Cela fera apparaître une boîte de dialogue dans laquelle vous pouvez sélectionner le projet d’équipe appropriée dans votre compte de Services d’équipe ou sur un ordinateur spécifique de TFS. Pour vous connecter à un serveur, vous devrez peut-être faire au départ, utilisez Team Explorer dans Visual Studio (l’onglet présenté au bas de Figure 9). Pour plus d’informations, consultez la rubrique « Travail dans Team Explorer » dans la documentation de Visual Studio (bit.ly/29oGp5j).

Figure 9 Ajout d’une Solution au contrôle de code Source dans Visual Studio

Pour les référentiels Git, Team Services vous invite automatiquement avec un large éventail d’options lorsque vous créez le référentiel ou y accéder dans l’onglet Code, une interface utilisateur qui parle suffisamment de lui-même. Vous pouvez également créer un référentiel Git dans Visual Studio et puis publiez-le dans un référentiel Team Services. Je ne vais pas dans ce processus en détail ici, car il est bien documenté dans la rubrique « Partager votre Code avec Git et Visual Studio » (bit.ly/29VDYJg). Court, cependant, consiste à cliquer sur le bouton Publish dans le coin inférieur droit de la barre d’état de Visual Studio, elle affiche l’onglet Publier de Team Explorer comme indiqué dans Figure 10. Ici, vous pouvez sélectionner le compte de Services de l’équipe à utiliser. Un détail important consiste à cliquer sur le texte de petite taille avancé pour sélectionner un projet d’équipe comme indiqué. Comme vous pouvez également voir, la même interface utilisateur vous donne un accès facile à publier code dans GitHub et d’autres référentiels externes, et.

Figure 10 la publication de l’interface utilisateur dans Visual Studio

À l'horizon

Un référentiel de contrôle de code source en place, vous êtes maintenant prêt à passer à l’étape suivante de l’automatisation de votre pipeline de versions en configurant des builds et l’intégration continue. C’est ce que je vais aborder dans mon prochain article, où vous découvrirez comment une définition de build donnée au sein de Visual Studio Team Services peut tirer d’un des référentiels de contrôle de code source que j’ai abordés ici. En outre, un projet d’équipe permettre gérer les n’importe quel nombre de ces définitions de build, ce qui signifie que le projet d’équipe peut coordonner les builds à partir de n’importe quel nombre de référentiels pour produire les artefacts nécessaires pour le reste du pipeline de versions ou de pipelines, comme le cas, pourra.

---

Kraig Brockschmidt fonctionne en tant que contenu développeur senior chez Microsoft et se concentre sur les opérations de développement pour les applications mobiles.  Il est l’auteur de « Programmation Windows Store Apps avec HTML, CSS et JavaScript » (deux éditions) à partir de Microsoft Press et des blogs sur kraigbrockschmidt.com.

Merci aux experts techniques suivants d'avoir relu cet article : Donovan Brown et Gordon Hogenson