Concepts clés pour les nouveaux utilisateurs Azure Pipelines

Azure DevOps Services

En savoir plus sur les principaux concepts et composants qui composent Azure Pipelines. Une bonne compréhension des termes de base et des éléments d’un pipeline peut vous aider à créer, tester et déployer votre code de manière plus efficace.

Vue d’ensemble des 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 s’exécuter sans agent.
• Chaque agent exécute un travail qui comporte une ou plusieurs étapes.
• Une étape peut être une tâche ou un script. Il s’agit du plus petit composant d’un pipeline.
• Une tâche est un script prédéfini qui effectue une action, comme 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 est une infrastructure informatique avec un logiciel agent installé, qui exécute un travail à la fois. Par exemple, votre travail peut s’exécuter sur un agent Ubuntu hébergé par Microsoft.

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

Approbations

Les approbations définissent 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 des contrôles sont configurés dans un environnement, l’exécution d’un pipeline s’interrompt jusqu’à ce qu’ils aient tous été effectués 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 comme la distribution ou le déploiement. Pour plus d’informations, consultez Artefacts dans Azure Pipelines.

Livraison continue

La livraison continue (CD, continuous delivery) est un processus par lequel le code est généré, testé et déployé dans une ou plusieurs phases de test et de production. Le déploiement et les tests en plusieurs phases favorisent la qualité. Les systèmes d’intégration continue produisent des artefacts déployables, notamment 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 détectées souvent et de manière anticipée.

Intégration continue

L’intégration continue (CI) est la pratique adoptée par les équipes de développement pour simplifier les tests et la génération de code. L’intégration continue permet de détecter les bogues ou les problèmes au début du cycle de développement et ainsi de les corriger plus facilement et plus rapidement. Des tests et des générations 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 du code est envoyé (push), ou les deux. Des éléments appelés artefacts sont produits à partir de systèmes CI. Ils sont utilisés par les pipelines de mise en production en livraison continue pour piloter des déploiements automatiques.

Déploiement

Un déploiement de pipeline classique est l’action d’exécuter les tâches d’une phase. Le déploiement peut inclure l’exécution de tests automatisés, le déploiement d’artefacts de build et toute autre action spécifiée pour cette phase.

Pour les pipelines YAML, un déploiement se réfère à un travail de déploiement. Un travail de déploiement est un ensemble d’étapes exécutées de manière séquentielle 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 est simplement un regroupement d’agents à l’instar d’un pool d’agents. Vous pouvez définir les cibles de déploiement dans un pipeline pour un travail avec un groupe de déploiement. Apprenez-en davantage sur le provisionnement des agents pour les groupes de déploiement.

Environnement

Un environnement est un collection de ressources dans laquelle vous déployez votre application. Un environnement peut contenir une ou plusieurs machines virtuelles, des conteneurs, des applications Web ou tout autre service. Les pipelines se déploient sur un ou plusieurs environnements après l’achèvement d’une build et l’exécution des tests.

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 travaux sont particulièrement utiles quand vous souhaitez exécuter une série d’étapes dans différents environnements. Par exemple, vous voudrez peut-être générer deux configurations : x86 et x64. Dans ce cas, vous aurez une phase et deux travaux : un travail pour x86 et l’autre pour x64.

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

Pipeline

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 workflow qui définit la manière d’exécuter vos étapes de test, de génération et de déploiement.

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. Elle inclut une capture instantanée de toutes les informations nécessaires pour effectuer toutes les tâches et actions dans le pipeline de mise en production comme des phases, des tâches, des stratégies (déclencheurs et approbateurs, par exemple) et des options de déploiement. Vous pouvez créer une mise en production 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.

Exécuter

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 de votre pipeline avec une ligne de commande, PowerShell ou 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 phase est une limite logique dans le pipeline. Il peut être utilisé pour marquer la séparation de préoccupations (par exemple, génération, AQ et production). Chaque index contient un ou plusieurs travaux. Quand vous définissez plusieurs phases dans un pipeline, elles s’exécutent l’une après l’autre par défaut. Vous pouvez spécifier les conditions d’exécution d’une phase. Lorsque vous pensez à savoir si vous avez besoin d’une phase, demandez-vous :

• Différentes parties de ce pipeline sont-elles gérées par des groupes distincts ? Par exemple, vous pouvez avoir un gestionnaire de test qui gère les travaux liés aux tests et un autre gestionnaire qui gère les travaux liés au déploiement en production. Dans ce cas, il est judicieux d’avoir des phases distinctes pour les tests et la production.
• Existe-t-il un ensemble d’approbations liées à un travail ou à un ensemble de travaux spécifique ? Si c’est le cas, vous pouvez utiliser des phases pour diviser vos travaux en groupes logiques nécessitant des approbations.
• L’exécution de certains travaux peut-elle prendre beaucoup de temps ? Si l’un des travaux dans votre pipeline présente un long temps d’exécution, il est judicieux de le placer dans sa propre phase.

Étape

Une étape est le plus petit composant d’un pipeline. Par exemple, un pipeline peut comporter des étapes de build et de test. Une étape peut être un script ou une tâche. Une tâche est simplement un script précréé qui vous est proposé pour vous faciliter la vie. Pour voir les tâches disponibles, consultez les informations de référence sur les tâches de build et de mise en production. 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 composant permettant de définir une 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 quand un élément est poussé (push) sur un dépôt, à 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. Vous pouvez, par exemple, vouloir référencer le même fichier pour plusieurs pipelines. Dans ce cas, vous pouvez enregistrer le fichier dans la bibliothèque et l’utiliser quand vous en avez besoin. Les groupes de variables stockent des valeurs et des secrets potentiellement destinés à être transférés à un pipeline YAML ou mis à la disposition de plusieurs pipelines.

À propos des auteurs

• Dave Jarvis a contribué au graphisme sur la vue d’ensemble des concepts clés.