Partager via

Présentation d’Azure DevOps

  • Article

Le service unique qui était Visual Studio Team Services (VSTS) devient désormais notre nouvel ensemble d’Azure DevOps Services. Tout au long de notre documentation, des sites web et des produits, vous commencerez à remarquer de nouvelles icônes et noms pour Azure DevOps, tous nos services au sein d’Azure DevOps.

  • Azure Pipelines pour générer, tester et déployer en continu sur n’importe quelle plateforme et cloud.
  • Azure Boards pour une gestion de travail puissante.
  • Artefacts Azure pour les flux de package Maven, npm et NuGet.
  • Azure Repos pour des dépôts Git privés hébergés dans le cloud illimités.
  • Plans de test Azure pour les tests planifiés et exploratoires.

Avec le lancement d’Azure Pipelines, nous avons introduit une nouvelle application sur la Place de marché GitHub, actualisé un certain nombre d’expériences pour vous aider à commencer et offre des minutes CI/CD illimitées et 10 travaux parallèles pour les projets code source ouvert.

Pour plus d’informations, consultez la liste des fonctionnalités ci-dessous.

Fonctionnalités

Azure Pipelines :

Place de marché :

Administration :

Étapes suivantes

Remarque

Ces fonctionnalités seront déployées au cours des deux prochains jours.

Découvrez les nouvelles fonctionnalités ci-dessous et accédez à Azure DevOps Services pour les essayer vous-même.

Accéder à Azure DevOps Services

Azure Pipelines

Ajouter Azure Pipelines à partir de la Place de marché GitHub

Une nouvelle application Azure Pipelines dans la Place de marché GitHub développe l’intégration aux référentiels GitHub et simplifie les achats de travaux parallèles.

Auparavant, vous pouviez activer l’intégration continue avec les référentiels GitHub via l’authentification OAuth. À l’aide d’OAuth, Azure Pipelines utilise l’identité GitHub d’une personne pour récupérer du code et mettre à jour l’état de build sur GitHub. Toutefois, étant donné que les membres de votre équipe peuvent changer au fil du temps, il peut être moins souhaitable d’utiliser l’identité et les autorisations GitHub d’une personne. En installant l’application Azure Pipelines, vous pouvez autoriser l’application à effectuer des actions à la place.

En outre, lorsque vous utilisez l’application, les résultats de build sont mis à disposition dans la nouvelle fonctionnalité Vérifications de GitHub avec une vue détaillée des résultats de génération, de test et de couverture du code.

Pour commencer, installez l’application à partir de la Place de marché GitHub dans votre compte ou organisation GitHub. Vous pouvez également acheter des travaux parallèles supplémentaires avec un compte de paiement GitHub existant au lieu d’un compte Azure distinct. La tarification est la même de la même façon.

Application Azure Pipelines dans la Place de marché GitHub

Créer des projets code source ouvert avec Azure Pipelines gratuitement

Azure Pipelines fournit des pipelines hébergés dans le cloud pour Linux, macOS et Windows avec des minutes illimitées et 10 travaux parallèles gratuits pour code source ouvert.

Pour plus d’informations, consultez la documentation sur les dépôts publics de build et les travaux parallèles.

Configurer des builds à l’aide de YAML

Important

Pour utiliser cette fonctionnalité, vous devez activer la fonctionnalité De préversion des pipelines YAML build sur votre organisation.

Les pipelines de build BASÉS sur YAML sont désormais largement disponibles. Automatisez votre pipeline d’intégration continue à l’aide d’un fichier YAML archivé dans le référentiel en même temps que le reste de votre code. Il est facile de commencer avec une build à un seul travail. À mesure que vos besoins augmentent, effectuez facilement un scale-out à l’aide de plusieurs travaux , modèles externes et exécution de matrice.

Créer des pipelines de build YAML à l’aide de l’Assistant

Important

Pour utiliser cette fonctionnalité, vous devez activer la fonctionnalité d’aperçu de la nouvelle expérience de création de pipeline YAML sur votre profil ou organisation.

Un nouvel Assistant simplifie ce processus de création de pipelines de build basés sur YAML avec GitHub et Azure Repos. Une fois que vous avez choisi un référentiel à générer, un pipeline est automatiquement créé s’il contient un fichier YAML. Sinon, Azure Pipelines analyse votre référentiel et recommande un modèle YAML pour la création de votre projet. Cliquez simplement sur Enregistrer et exécuter pour créer une demande de tirage (pull request) pour le YAML suggéré et exécutez la première build. Les déclencheurs d’intégration continue et de demande de tirage sont activés automatiquement.

Assistant Nouveau pipeline

Gérer les pipelines de build à l’aide de la nouvelle page Builds

Important

Pour utiliser cette fonctionnalité, vous devez activer la fonctionnalité Nouvelle version d’évaluation du hub de builds sur votre profil ou organisation.

Nous apportons plusieurs améliorations et déployons une nouvelle version de la page Builds . Cette nouvelle version combine le répertoire de tous vos pipelines de build et la liste des builds actuelles afin que vous puissiez rapidement parcourir les builds de votre projet pour voir son état. Il inclut également une préversion de l’analytique de test pour le pipeline sélectionné.

Page Nouvelles builds

Reconstruire les builds de demande de tirage GitHub

Lorsque vous envoyez une demande de tirage à votre dépôt GitHub, la build de demande de tirage peut échouer en raison d’un échec intermittent, tel qu’un registre de packages indisponible ou un test flaky. Dans ces cas, vous souhaitez exécuter la build une fois de plus. Actuellement, cela vous oblige à envoyer une autre mise à jour artificielle à la demande de tirage. À présent, dans la nouvelle page Builds, vous pouvez simplement sélectionner la build ayant échoué et mettre en file d’attente une autre.

Ce mouvement de reconstruction sera disponible uniquement pour que les builds de demande de tirage commencent par. Nous examinons la mise à disposition d’une fonctionnalité similaire pour toutes les builds ayant échoué.

URL du badge d’état de la nouvelle build

Les badges de build incorporés dans la page d’accueil d’un référentiel sont un moyen courant d’afficher l’intégrité du référentiel. Nous avons ajouté de nouvelles URL pour vous aider à construire des badges de build. Les nouvelles URL permettent aux utilisateurs de publier un état par branche et peuvent amener les utilisateurs à la dernière build de la branche sélectionnée. Vous pouvez obtenir markdown pour la nouvelle URL du badge d’état en sélectionnant l’action de menu Badge État dans la nouvelle page Builds. Pour la compatibilité descendante, nous continuerons à respecter les URL de badge de build plus anciennes.

Tirer parti d’outils encore plus sur les agents Linux hébergés par Microsoft

Dans cette mise à jour, plusieurs outils de génération, de test et de déploiement ont été ajoutés aux agents Linux hébergés par Microsoft, ce qui supprime la nécessité de les installer vous-même lors d’une build ou d’une version.

  • Erlang/OTP
  • Firefox
  • Haskell
  • Heroku CLI
  • ImageMagick
  • Mercurial
  • Microsoft Outils clients SQL Server
  • MySQL Server
  • FantômeJS
  • Polliniser
  • PyPy2 et PyPy3
  • rebar
  • rsync
  • ShellCheck
  • Sphinx
  • Terraform
  • Xvfb

Suivre les validations GitHub et les problèmes associés dans les versions

Connaître les modifications qui sont déployées avec une version est importante pour suivre les améliorations apportées à l’application. Vous pouvez maintenant obtenir la liste des validations effectuées dans les dépôts GitHub et les problèmes GitHub associés qui sont déployés avec une version.

Validations pour une version

Gérer les e-mails de génération et de fin de déploiement mieux à l’aide d’une mise en forme améliorée

Les e-mails de saisie semi-automatique de build et de déploiement ont été mis à jour pour être plus filtrables par les règles de messagerie. Maintenant, la ligne d’objet inclut des informations plus pertinentes en un clin d’œil, le corps contient plus de détails et leur style a été actualisé avec la dernière marque.

Les éléments du nouveau format sont les suivants :

  • [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
  • [Deployment result] [pipeline name] > [release name] : [stage name]

Voici quelques exemples :

  • [Build succeeded] IdentityService.CI - MyRepo:master - MyProject - d3b90b80
  • [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

Suivez la nouvelle terminologie unifiée d’Azure Pipelines

Tout au long des builds et versions, différents termes ont été utilisés historiquement pour des concepts similaires. Dans d’autres cas, les significations des termes étaient vagues. Par exemple, en indiquant la différence entre un pool d’agents et une file d’attente d’agent.

La terminologie a été unifiée dans Azure Pipelines pour clarifier ses concepts. Vous verrez maintenant les termes unifiés suivants :

Terme précédent Terme unifié Signification
Agent hébergé Agent hébergé par Microsoft Agent de build/mise en production qui s’exécute sur une infrastructure hébergée dans le cloud gérée par Microsoft.
Agent privé Agent autohébergé Agent de build/mise en production qui s’exécute sur un ordinateur fourni et géré par vous.
Pool d’agents Pool d’agents Ensemble d’agents au niveau de l’organisation qui peut exécuter des builds ou des versions.
File d’attente de l’agent Pool d’agents Ensemble de machines d’agent au niveau du projet capables d’exécuter des builds ou des versions. Il est lié à un pool d’agents au niveau de l’organisation.
Définition de build Pipeline de build Ensemble de étapes de génération de bout en bout pour une application.
Build Build Instance d’un pipeline de build qui est en cours d’exécution ou qui a été exécuté.
Phase Travail Série de tâches qui s’exécutent séquentiellement ou en parallèle sur un agent. Un pipeline de build ou de mise en production peut contenir un travail ou un graphique de plusieurs travaux.
Définition de mise en production Pipeline de mise en production Ensemble de étapes de mise en production de bout en bout pour qu’une application soit déployée à travers différentes étapes.
Version release Version release Instance d’un pipeline de mise en production qui s’exécute ou a été exécutée.
Environment Étape Entité logique et indépendante qui représente l’emplacement où vous souhaitez déployer une version générée à partir d’un pipeline de mise en production.
Travail/pipeline simultané Travail parallèle Un travail parallèle vous permet d’exécuter un travail de génération ou de mise en production unique à la fois dans votre organisation. Avec d’autres travaux parallèles disponibles, vous pouvez exécuter en même temps davantage de travaux de génération et de mise en production.
Point de terminaison de service Connexion du service Groupe de paramètres, tels que les informations d’identification, utilisés pour se connecter à des services externes pour exécuter des tâches dans une build ou une version.

Pour plus d’informations, consultez la documentation Concepts .

Place de marché

Tirer parti des dernières catégories d’extensions

En tant que contributeur d’extension, vous remarquerez que les catégories d’extensions ont été alignées pour correspondre aux services Azure DevOps renommés dans la Place de marché. Bien que les catégories précédentes aient été automatiquement mappées aux nouvelles, nous vous recommandons de passer aux nouvelles catégories en mettant à jour le manifeste de votre extension. Pour plus d’informations, consultez la documentation du manifeste .

Administration

Changer d’organisation existante pour utiliser la nouvelle URL de nom de domaine

Bien que nous ayons déplacé vers le nouveau dev.azure.com nom de domaine comme URL pour les nouvelles organisations, vous pourrez continuer à accéder à votre organisation à l’aide du visualstudio.com domaine, comme d’habitude. Si vous souhaitez modifier votre URL pour qu’elle soit basée dev.azure.com, un administrateur de l’organisation (administrateur de collection de projets) peut le modifier à partir de la page des paramètres de l’organisation. Bien que l’adoption du nouveau nom de domaine ne redirige pas chaque requête, toute demande vers l’URL racine de l’organisation et les liens de nombreux e-mails et liens basés sur le web changeront.

Paramètre d’URL de l’organisation

Nous allons passer progressivement à la nouvelle URL en fonction des commentaires des clients. Il démarre comme opt-in, puis plus tard, nous allons le rendre la valeur par défaut pour les organisations. Nous n’avons pas encore défini une chronologie pour déplacer délibérément les organisations hors du visualstudio.com domaine.

Important

Pour vous assurer que votre organisation fonctionne avec toutes les restrictions de pare-feu ou d’adresse IP existantes, assurez-vous que les noms de domaine et adresses IP appropriés sont autorisés. Pour plus d’informations, consultez la section Q&A de cet agent.

Ajouter des utilisateurs des parties prenantes pour économiser sur les coûts de licence Azure Pipelines

Important

Pour utiliser cette fonctionnalité, vous devez disposer de l’accès gratuit aux pipelines pour les parties prenantes en préversion activé sur votre organisation.

Bonne nouvelle ! Si vous utilisez uniquement le service Azure Pipelines, vous n’avez plus besoin de payer pour les utilisateurs via des licences de base. Toutes les fonctionnalités d’Azure Pipelines sont disponibles gratuitement pour tous les utilisateurs. Lorsque vous ajoutez d’autres utilisateurs à votre projet, laissez-les rester en tant que parties prenantes gratuitement, et ils pourront créer, afficher, mettre à jour et approuver des pipelines, à condition qu’ils disposent des autorisations appropriées. Voici quelques remarques supplémentaires sur cette modification de licence :

  • Vous payez uniquement pour des travaux parallèles supplémentaires dans Azure Pipelines. Les utilisateurs sont illimités.
  • Tous les accès aux fonctionnalités d’Azure Pipelines sont toujours régis par le biais d’un modèle de sécurité et d’autorisations.
  • Si vous utilisez d’autres services Azure DevOps, vous devez toujours payer une licence par utilisateur pour ces services après les limites gratuites.
  • Dans les organisations existantes, les parties prenantes n’obtiennent pas l’avantage Azure Pipelines gratuit par défaut. Votre administrateur d’organisation (administrateur de collection de projets) doit activer explicitement cette fonctionnalité en préversion. L’activation de cette fonctionnalité en préversion modifie le comportement de ce que les parties prenantes peuvent faire. Actuellement, ils ne peuvent pas gérer les builds ou versions. Toutefois, une fois la fonctionnalité en préversion activée, il n’existe aucune différence entre les utilisateurs de base et les parties prenantes dans Azure Pipelines. C’est pour cette raison que le choix d’autoriser les parties prenantes à être traités comme des utilisateurs Azure Pipelines gratuits est laissé à votre administrateur.

Pour plus d’informations, consultez la documentation fournir aux parties prenantes l’accès aux modifications des pipelines de build et de mise en production.

Comment fournir des commentaires

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Utilisez le menu commentaires pour signaler un problème ou fournir une suggestion.

Faire une suggestion

Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.

Merci,

Jeremy Epling