Construction d'application (Build)
Le TFS (Team Foundation Server) a introduit un nouveau système de construction (build) dans TFS 2015 appelé TFBuild. Ainsi, il offre les possibilités suivantes :
- Configuration de l'agent TFBuild, du bassin et des files d'attente
- Configuration d'un agent TFBuild à l'aide d'une installation sans assistance
- Création d'une définition de construction (build) d'intégration continue dans TFBuild
- Épingler un badge de construction (build) à la page d'accueil dans Team Portal
- Gestion des ressources de construction (build) à l'aide d'un accès basé sur les rôles
- Utiliser la stratégie de rétention des builds pour automatiser la suppression des constructions (builds)
- Utilisation des capacités utilisateur pour identifier un agent de construction (build) dans un bassin
- DLL de version dans la sortie d'une construction (build) avec le numéro de construction (build)
- Création d'une nouvelle tâche de génération à l'aide du cadre d'application d'extensibilité TFBuild
- Intégrer SonarQube à TFBuild pour gérer la dette technique
- Construire des référentiels de code GitHub avec TFBuild
Lorsque que vous êtes développeur, la compilation de code et l'exécution de tests unitaires vous donnent l'assurance que vos modifications de code n'ont pas eu d'impact sur la base de code existante. L'intégration de vos modifications de code dans le référentiel de contrôle de source permet aux autres utilisateurs de valider leurs modifications avec les vôtres. En tant que meilleure pratique, les équipes intègrent les modifications dans le référentiel partagé plusieurs fois par jour pour réduire le risque d'introduire des modifications de rupture ou pire, de s'écraser les unes les autres.
L'intégration continue (CI) est une pratique de développement obligeant les développeurs à intégrer le code dans un référentiel partagé plusieurs fois par jour. Chaque enregistrement est vérifié par une version automatisée, permettant aux équipes de détecter les problèmes à un stade précoce.
La construction (build) automatisé s'exécutant dans le cadre du processus CI est souvent appelé build CI. Il n'y a pas de définition claire de ce que la version CI doit faire, mais au minimum, elle est censée compiler le code et exécuter des tests unitaires. L'exécution de la version CI sur un espace de travail à distance non développeur permet d'identifier les dépendances pouvant autrement passer inaperçues dans le processus de publication. Ainsi, elle vous permet d'avoir un logiciel potentiellement déployable à tout moment.
L'image suivante illustre les trois générations de systèmes de construction (build) dans TFS :
| Génération | Nom | Configuration | Introduit dans |
|---|---|---|---|
| Première génération | MS Build | XML | TFS 2005 |
| Deuxème génération | XAML Build | WWF | TFS 2010 |
| Troisième génération | TFBuild | JSON | TFS 2015 |
Le TFS a traversé trois générations de systèmes de construction. Le tout premier était MSBuild utilisant XML pour la configuration ; le suivant était XAML utilisant WWF (Windows Workflow Foundation) pour la configuration, et maintenant, il y a TFBuild utilisant JSON pour la configuration. Le système de génération basé sur XAML continue d'être pris en charge dans TFS 2015. Aucun chemin de migration automatisé n'est disponible de la génération XAML vers TFBuild. Cela est généralement dû à la différence d'architecture entre les deux systèmes de construction.
Le nouveau système de construction (build) dans TFS s'appelle Team Foundation Build (TFBuild). Il s'agit d'un système d'exécution extensible basé sur des tâches avec une interface Web riche permettant la création, la mise en file d'attente et la surveillance des constructions (builds). \ Le TFBuild est entièrement multiplateforme avec les agents de construction sous-jacents capables de s'exécuter nativement sur les plateformes Windows et non Windows. Le TFBuild fournit une intégration prête à l'emploi avec le contrôle de version centralisé tel que TFVC et les contrôles de version distribués tels que Git et GitHub. Le TFBuild prend en charge la création d'applications .NET, Java, Android et iOS.
Le TFBuild est un orchestrateur de tâches vous permettant d'exécuter n'importe quel moteur de génération, tel que Ant, CMake, Gradle, Gulp, Grunt, Maven, MSBuild, Visual Studio, Xamarin, XCode,... Le TFBuild prend en charge l'intégration des éléments de travail, la publication des suppressions et la publication des résultats de l'exécution des tests dans le TFS étant indépendant du moteur de génération que vous choisissez. Les agents de génération sont xCopyable et ne nécessitent aucune installation. Les agents se mettent à jour automatiquement par nature ; il n'est pas nécessaire de mettre à jour chaque agent de votre infrastructure :
Le TFBuild offre une interface Web riche. Il ne nécessite pas Visual Studio pour créer ou modifier une définition de build. Du simple au complexe, toutes les définitions de build peuvent être facilement créées dans le portail Web. L'interface web est accessible depuis n'importe quel appareil et n'importe quelle plateforme :
Une définition de build est un ensemble de tâches. Une tâche est simplement une étape de construction. La définition de build peut être composée en faisant glisser et en déposant des tâches. Chaque tâche prend en charge les indicateurs Enabled ou Activé, Continue on error ou Continuer en cas d'erreur et Always run ou Toujours exécuter, ce qui facilite la gestion des définitions de build à mesure que la liste des tâches s'allonge :
Le système de génération prend en charge l'appel de scripts PowerShell, traitement par lot (batch), de ligne de commande et de script d'interpréteur de commande. Toutes les tâches prêtes à l'emploi sont open source. Si une tâche ne répond pas à vos besoins, vous pouvez la télécharger depuis GitHub à l'adresse https://github.com/Microsoft/vso-agent-tasks et la personnaliser. Si vous ne trouvez pas une tâche, vous pouvez facilement en créer une.
Les modifications apportées aux définitions de construction peuvent être enregistrées en tant que brouillons. Les définitions de build conservent un historique de toutes les modifications dans l'onglet History ou Historique. Une comparaison côte à côte des changements est également possible (en cliquant sur le bouton Diff). Les commentaires saisis lors de la modification de la définition de build s'affichent dans l'historique des modifications :
Plusieurs déclencheurs peuvent être définis pour la même construction (build), y compris des déclencheurs CI et plusieurs déclencheurs planifiés :
Les stratégies de rétention basées sur des règles prennent en charge la configuration de plusieurs règles. La rétention peut être spécifiée par «jours» ou «nombre» de construction (builds) :
