Pipelines : automatisation

Les deux types de pipelines

Une plateforme DevOps ne serait pas complète si elle n’offrait pas la possibilité d’automatiser la gestion du code source. Azure DevOps propose deux types de pipelines à cet effet : les pipelines de build et les pipelines de release. Mais avant d’explorer ce qu’Azure DevOps propose, étudions les notions théoriques sous-jacentes.

1. Pipeline de build

Mettre en place une approche DevOps, au-delà du mouvement philosophique, passe obligatoirement par une automatisation des tâches. En effet, le but est d’avoir la capacité de livrer les produits rapidement et d’obtenir un feedback de la part des utilisateurs, afin de pouvoir rapidement ajuster le tir au besoin.

En ce sens, il faut prévoir plusieurs outils afin d’automatiser. Il fut un temps dans l’informatique où le développeur avait la charge de livrer l’application sur les serveurs de production. À cet effet, il compilait l’application sur son ordinateur, produisait un fichier .zip contenant tous les binaires requis et le déployait manuellement sur le serveur de production.

Depuis, les IDE ont évolué et il est certes possible d’effectuer toutes les tâches précitées en quelques clics, mais cela présente tout de même des inconvénients majeurs :

Le processus repose sur une ou plusieurs...

Les pipelines avec Azure DevOps

Utiliser des pipelines de build et de release permet de se baser sur un environnement neutre. Certains outils nécessitent de mettre tout en place sur un serveur de façon pérenne, mais il est tout aussi possible de se servir de ressources « jetables », comme des conteneurs, afin de s’assurer de partir sur un environnement vierge de toute dépendance à chaque exécution. C’est d’ailleurs sur cette logique qu’Azure DevOps a implémenté les pipelines sur la plateforme, pour s’assurer que chaque exécution part d’un nouvel environnement.

Nous parlons ici des pipelines qui sont exécutés sur Azure DevOps, hébergés par Microsoft. La plateforme nous donne la possibilité d’avoir nos propres agents sur nos propres serveurs. Il sera alors de la responsabilité de l’utilisateur de s’assurer que l’exécution des pipelines ne laisse pas de reliquats et que des contraintes environnementales liées à la machine ne sont pas appliquées sur ce qui est produit.

Il va sans dire qu’Azure DevOps permet de gérer tout autant les pipelines de build que les pipelines de release. Cependant, historiquement, les deux options étaient séparées, avec un éditeur graphique dédié pour chacun. Depuis, Azure DevOps offre la possibilité de gérer ces pipelines à l’aide de code, ce qui permet de stocker leur script de définition directement dans le dépôt de code source.

Lorsque nous observons le menu Pipelines d’Azure DevOps, nous pouvons constater qu’il existe un élément Pipelines, mais également un autre élément appelé Releases (nous reviendrons sur les autres éléments).

En effet, Releases nous permet de gérer exclusivement, de façon graphique, les pipelines de release, alors que Pipelines offre un éditeur de code YAML complet, qui peut servir à la fois pour la release, mais aussi pour le build.

Cependant, avant de pouvoir mettre en œuvre un pipeline, il est nécessaire d’avoir du code source pouvant être compilé et exécuté.

La nouvelle politique de Microsoft concernant Azure DevOps est de proposer un agent...

Gestion des agents

Jusqu’à présent, nous avons exécuté nos tâches et nos pipelines sur les agents hébergés par Microsoft. Il existe néanmoins deux types d’agents distincts : ceux hébergés par Microsoft et ceux déployés sur nos propres serveurs (On Premise).

1. Agents hébergés par Microsoft

L’avantage principal d’utiliser les agents hébergés par Microsoft est qu’il n’y a pas de phase d’installation ni de configuration nécessaire.

a. Fonctionnement des agents hébergés par Microsoft

Cependant, ce confort vient avec des contraintes non négligeables :

Il faut demander des accès à l’ouverture de son compte.
Pour les projets privés, il n’y a qu’un seul agent disponible, proposant 1 800 minutes gratuites d’exécution. Si nous souhaitons aller plus loin (davantage d’agents ou une durée d’exécution plus longue), il est nécessaire de passer à un plan payant.
Les agents sont préconfigurés et la personnalisation, bien que possible, est limitée. De même, ils peuvent être plus longs à s’exécuter du fait du partage des ressources avec tous les autres utilisateurs de la plateforme.

Les agents de Microsoft fonctionnent comme des conteneurs Docker qui sont lancés à chaque exécution, puis supprimés à la fin du pipeline : à chaque lancement, un environnement vierge est alloué sur le système d’exploitation choisi à la configuration de l’agent.

Lorsque nous avons créé notre pipeline de build, nous avons défini la valeur de vmImage à ubuntu-latest, indiquant par cela que nous souhaitions que notre agent s’exécute sur le système d’exploitation Linux avec la préconfiguration par Microsoft. Avec ce type de configuration, un ensemble de logiciels est déjà préinstallé. Toutes les informations peuvent être trouvées directement sur GitHub à l’adresse suivante : https://github.com/actions/runner-images/tree/main/images

Il suffira dès lors de naviguer vers le système d’exploitation concerné, puis d’ouvrir le fichier...