Concepts clés pour les nouveaux utilisateurs d’Azure Pipelines

Azure DevOps Services

Découvrez les concepts et composants clés qui composent Azure Pipelines. Comprendre les termes de base et les parties d’un pipeline peuvent vous aider à générer, tester et déployer plus efficacement votre code.

vue d’ensemble des concepts clés

graphique de concepts clés

• Un déclencheur indique à un pipeline de s’exécuter.
• Un pipeline se compose d’une ou plusieurs phases. Un pipeline peut être déployé sur un ou plusieurs environnements .
• Une phase est une manière d’organiser des travaux dans un pipeline et chaque phase peut inclure un ou plusieurs travaux.
• Chaque travail s’exécute sur un seul agent. Un travail peut également être sans agent.
• Chaque agent exécute un travail qui contient une ou plusieurs étapes .
• Une étape peut être une tâche ou script et est le plus petit bloc de construction d’un pipeline.
• Une tâche est un script prépackagené qui effectue une action, telle que l’appel d’une API REST ou la publication d’un artefact de build.
• Un artefact est une collection de fichiers ou de packages publiés par une exécution.

Termes relatifs à Azure Pipelines

Agent

Quand votre build ou déploiement s’exécute, le système démarre un ou plusieurs travaux. Un agent calcule l’infrastructure avec des logiciels d’agent installés qui exécutent un travail à la fois. Par exemple, votre travail peut s’exécuter sur un agent Ubuntu hébergé par Microsoft.

Pour plus d’informations détaillées sur les différents types d’agents et leur utilisation, consultez Agents Azure Pipelines.

Approbations

Le terme Approbations se réfère à un ensemble de validations nécessaires à l’exécution d’un déploiement. L’approbation manuelle est une vérification courante effectuée pour contrôler les déploiements dans les environnements de production. Lorsque les vérifications sont configurées sur un environnement, une exécution de pipeline s’interrompt jusqu’à ce que toutes les vérifications soient effectuées avec succès.

Artefact

Un artefact est une collection de fichiers ou de packages publiés par une exécution. Les artefacts sont mis à la disposition des tâches suivantes, telles que la distribution ou le déploiement. Pour plus d’informations, consultez Artefacts dans Azure Pipelines.

Livraison continue

La livraison continue (CD) est un processus par lequel le code est généré, testé et déployé sur une ou plusieurs phases de test et de production. Le déploiement et le test en plusieurs étapes améliorent la qualité. Les systèmes d’intégration continue produisent des artefacts déployables, qui incluent l’infrastructure et les applications. Les pipelines de mise en production automatisés consomment ces artefacts pour publier de nouvelles versions et des correctifs sur des systèmes existants. Des systèmes de monitoring et d’alerte s’exécutent constamment, améliorant la visibilité sur l’ensemble du processus CD. Ce processus garantit que les erreurs sont souvent détectées et à un stade précoce.

Intégration continue

L’intégration continue (CI) est la pratique utilisée par les équipes de développement pour simplifier les tests et la génération de code. CI permet d’intercepter les bogues ou les problèmes au début du cycle de développement, ce qui les rend plus faciles et plus rapides à corriger. Les tests et builds automatisés sont exécutés dans le cadre du processus CI. Le processus peut s’exécuter selon une planification définie, chaque fois que le code est envoyé (push) ou les deux. Les éléments appelés artefacts sont produits à partir de systèmes CI. Ils sont utilisés par les pipelines de livraison continue pour orchestrer des déploiements automatiques.

Déploiement

Un déploiement de pipeline standard consiste à exécuter les tâches associées à une étape. Le déploiement peut inclure l’exécution de tests automatisés, le déploiement d’artefacts de build et toutes les autres actions spécifiées pour cette étape.

Pour les pipelines YAML, un déploiement se réfère à un travail de déploiement. Un travail de déploiement est une collection d’étapes qui sont exécutées séquentiellement sur un environnement. Vous pouvez utiliser des stratégies telles que le déploiement en une exécution, propagé et basé sur le contrôle de validité pour les travaux de déploiement.

Groupe de déploiement

Un groupe de déploiement est un ensemble de machines cibles de déploiement sur lesquelles des agents sont installés. Un groupe de déploiement n’est qu’un autre regroupement d’agents, comme un pool d’agents . Vous pouvez définir les cibles de déploiement dans un pipeline pour un travail à l’aide d’un groupe de déploiement. En savoir plus sur l’approvisionnement des agents pour les groupes de déploiement .

Environnement

Un environnement est une collection de ressources où vous déployez votre application. Un environnement peut contenir une ou plusieurs machines virtuelles, conteneurs, applications web ou tout service. Les pipelines sont déployés dans un ou plusieurs environnements une fois qu’une build est terminée et que les tests sont exécutés.

Travail

Une phase inclut un ou plusieurs travaux. Chaque travail s’exécute sur un agent. Un travail représente une limite d’exécution d’un ensemble d’étapes. Toutes les étapes sont exécutées ensemble sur le même agent. Les tâches sont les plus utiles lorsque vous souhaitez exécuter une série d’étapes dans différents environnements. Par exemple, vous pouvez créer deux configurations : x86 et x64. Dans ce cas, vous avez une étape et deux tâches. Un travail serait pour x86 et l’autre travail serait pour x64.

Les travaux sans agent s’exécutent dans Azure DevOps et Azure DevOps Server sans utiliser d’agent. Un nombre limité de tâches prennent en charge les tâches sans agent.

Canalisation

Un pipeline définit le processus d’intégration et de déploiement continus pour votre application. Il se compose d’une ou plusieurs phases. Il peut être considéré comme un flux de travail qui définit la façon dont vos étapes de test, de génération et de déploiement sont exécutées.

Pour les pipelines classiques, un pipeline peut également être appelé définition.

Libérer

Pour les pipelines classiques, une version est un ensemble versionné d’artefacts spécifiés dans un pipeline. La version inclut un instantané de toutes les informations requises pour effectuer toutes les tâches et actions dans le pipeline de mise en production, telles que les étapes, les tâches, les stratégies telles que les déclencheurs et les approbateurs et les options de déploiement. Vous pouvez créer une version manuellement, avec un déclencheur de déploiement ou avec l’API REST.

Pour les pipelines YAML, les phases de build et de mise en production sont dans un même pipeline multiphase.

Courir

Il s’agit d’une exécution d’un pipeline. Elle collecte les journaux associés à l’exécution des étapes et les résultats des tests en cours d’exécution. Pendant une exécution, Azure Pipelines traite d’abord le pipeline, puis envoie l’exécution à un ou plusieurs agents. Chaque agent exécute des travaux. Apprenez-en davantage sur la séquence d’exécution de pipeline.

Pour les pipelines classiques, une build représente une exécution d’un pipeline.

Script

Un script exécute du code en tant qu’étape dans votre pipeline à l’aide de la ligne de commande, de PowerShell ou de Bash. Vous pouvez écrire des scripts multiplateformes pour macOS, Linux et Windows. Contrairement à une tâche , un script est un code personnalisé spécifique à votre pipeline.

Étape

Une étape est une limite logique dans le pipeline. Il peut être utilisé pour marquer la séparation des préoccupations (par exemple, Build, QA et production). Chaque étape contient un ou plusieurs travaux. Lorsque vous définissez plusieurs étapes dans un pipeline, par défaut, elles s’exécutent l’une après l’autre. Vous pouvez spécifier les conditions dans lesquelles une phase s’exécute. Lorsque vous pensez à savoir si vous avez besoin d’une étape, demandez-vous :

• Les groupes distincts gèrent-ils différentes parties de ce pipeline ? Par exemple, vous pouvez avoir un gestionnaire de tests qui gère les travaux liés aux tests et à un autre gestionnaire qui gère les travaux liés au déploiement de production. Dans ce cas, il est judicieux d’avoir des étapes distinctes pour les tests et la production.
• Existe-t-il un ensemble d’approbations connectées à un travail ou à un ensemble spécifique de travaux ? Si c’est le cas, vous pouvez utiliser des étapes pour décomposer vos travaux en groupes logiques qui nécessitent des approbations.
• L’exécution de certains travaux peut-elle prendre beaucoup de temps ? Si un travail dans votre pipeline a un temps d’exécution long, il est judicieux de placer ce travail à sa propre étape.

Étape

Une étape est le plus petit bloc de construction d’un pipeline. Par exemple, un pipeline peut être constitué d’étapes de génération et de test. Une étape peut être un script ou une tâche. Une tâche est simplement un script précréé proposé comme commodité pour vous. Pour afficher les tâches disponibles, consultez la référence tâches de compilation et de déploiement. Pour plus d’informations sur la création de tâches personnalisées, consultez Créer une tâche personnalisée.

Tâche

Une tâche est le bloc de construction pour définir l’automatisation dans un pipeline. Une tâche est une procédure ou un script empaqueté précédemment abstrait avec un ensemble d’entrées.

Déclencheur

Un déclencheur est un composant qui est configuré pour indiquer au pipeline quand s’exécuter. Vous pouvez configurer un pipeline pour qu’il s’exécute sur un push vers un référentiel, à des moments planifiés ou à l’achèvement d’une autre build. Toutes ces actions sont appelées déclencheurs. Pour plus d’informations, consultez Déclencheurs de build et Déclencheurs de mise en production.

Bibliothèque

La bibliothèque inclut des fichiers sécurisés et des groupes de variables . les fichiers sécurisés permettent de stocker des fichiers et de les partager entre les pipelines. Par exemple, vous pouvez référencer le même fichier pour différents pipelines. Dans ce cas, vous pouvez enregistrer le fichier dans bibliothèque et l’utiliser quand vous en avez besoin. Les groupes de variables stockent des valeurs et des secrets que vous avez éventuellement l'intention de transférer à un pipeline YAML ou de mettre à la disposition de plusieurs pipelines.

À propos des auteurs

• Dave Jarvis a contribué au graphique de présentation des concepts clés.