Templatisation des Pipelines

Cette approche est prise en charge par divers outils CI/CD, en particulier Azure DevOps, permettant aux équipes de définir des configurations d’étapes de pipeline standard pouvant être utilisées dans tous les pipelines d’une organisation.

Le principe DRY (Don’t Repeat Yourself)

Le principe DRY (Don’t Repeat Yourself) est un concept fondamental en développement logiciel qui met l’accent sur l’importance d’éviter la redondance en créant des composants réutilisables et modulaires. Ce principe est très applicable aux pipelines CI/CD.

Dans le contexte des pipelines, le principe DRY préconise la création de modèles qui encapsulent des configurations et des flux de travail communs. En adhérant à ce principe, les équipes de développement peuvent éliminer la redondance, réduire les erreurs et améliorer la maintenabilité de leurs processus CI/CD.

Paramètres et Variables dans les Modèles

Le principe DRY dans la templatisation des pipelines réside dans la création de configurations réutilisables à l’aide de paramètres. Ces paramètres servent d’entrées dynamiques permettant la personnalisation tout en maintenant une structure standardisée.

Paramètres

Les paramètres sont les valeurs que vous pouvez transmettre à un modèle pour personnaliser son comportement. Ils peuvent être utilisés pour contrôler l’exécution d’étapes, de jobs ou de stages dans un modèle. Les paramètres peuvent être de différents types, y compris des chaînes, des booléens et des objets, et ils peuvent avoir des valeurs par défaut. Voyons cela avec un exemple :

parameters:
- name: nodeVersion
  default: '18.X'

steps:
- task: UseNode@1
  displayName: Use Node version ${{ parameters.nodeVersion }}
  inputs:
      version: ${{ parameters.nodeVersion }}

Ce modèle accepte nodeVersion comme paramètre et utilise ‘18.X’ par défaut lorsque le paramètre n’est pas fourni.

Variables

Les variables dans les pipelines, en particulier dans Azure DevOps, sont une fonctionnalité puissante qui permet d’assigner dynamiquement des valeurs à des parties de la configuration du pipeline. Elles peuvent être définies à différents niveaux de portée, pipeline, étape et job, ce qui les rend très flexibles.

Variables Définies par l’Utilisateur

variables:
  myVariable: 'Hello World'

steps:
  - script: echo $(myVariable)

Variables Système

Azure DevOps fournit un ensemble de variables système prédéfinies qui sont automatiquement disponibles dans le pipeline. Ces variables fournissent des informations sur le pipeline, l’agent et l’environnement.

steps:
  - script: echo $(Build.BuildId)

Cette étape affiche l’ID de la build actuelle, en utilisant la variable système Build.BuildId.

Types de Modèles

Comme on le sait, le pipeline YAML commun dans Azure DevOps est composé de stages, de jobs et d’étapes comme le montre cet exemple :

trigger:
- main

stages:
- stage: Build
 displayName: 'Build Stage'
 pool:
    vmImage: ubuntu-latest
 jobs:
 - job: BuildJob
    displayName: 'Build Job'
    steps:
    - script: echo Building the application...
      displayName: 'Build Application'
    - script: echo Running tests...
      displayName: 'Run Tests'

Les mêmes types de modèles s’appliquent :

SModèles de Stages : Les modèles de stages permettent la définition d’un ou de plusieurs stages pouvant être réutilisés à travers plusieurs pipelines. Par exemple, vous pouvez avoir un stage commun pour le build, les tests et le déploiement de certaines applications.

parameters:
  - name: buildJobName

stages:
- stage: Build
 displayName: 'Build Stage'
 jobs:
 - job: Build
    displayName: 'Build Job'
    steps:
    - script: echo Building...

- stage: Test
 displayName: 'Test Stage'
 jobs:
 - job: Test
    displayName: 'Test Job'
    steps:
    - script: echo Testing...

- stage: Deploy
 displayName: 'Deploy Stage'
 jobs:
 - job: Deploy
    displayName: 'Deploy Job'
    steps:
    - script: echo Deploying...

Pour utiliser ce modèle de stage dans un pipeline avec buildJobName comme paramètre :

trigger:
  - main

pool: 'ubuntu-latest'

stages:
  - template: templates/build-test-deploy.yml
    parameters:
      buildJobName: 'Build Job'

Modèles de Jobs : Les modèles de jobs permettent de définir un ou plusieurs jobs pouvant être réutilisés à travers différents stages dans les pipelines. Voici un exemple de modèle de job :

jobs:
- job: Test
 displayName: 'Test Job'
 steps:
 - script: echo Testing...

Pour utiliser ce modèle de job dans un stage :

trigger:
- main

pool: 'ubuntu-latest'

stages:
- stage: Test
 displayName: 'Test Stage'
 jobs:
 - template: templates/test.yml

Modèles d’Étapes : Les modèles d’étapes permettent de définir une ou plusieurs étapes pouvant être réutilisées à travers différents jobs dans plusieurs pipelines. Cela est utile pour définir des tâches communes, telles que l’exécution de vérifications de style et l’installation de Node qui sont fréquemment utilisées.

parameters:
  - name: nodeVersion

steps:
  - task: UseNode@1
    displayName: Use Node version ${{ parameters.nodeVersion }}
    inputs:
      version: ${{ parameters.nodeVersion }}

  - task: Cache@2
    inputs:
      key: 'npm | "$(Agent.OS)" | package-lock.json'
      restoreKeys: |
        npm | "$(Agent.OS)"
      path: $(npm_config_cache)
    displayName: Cache npm

  - task: Bash@3
    displayName: Install NodeJS Dependencies
    inputs:
      targetType: inline
      script: |
        npm ci
      workingDirectory: $(System.DefaultWorkingDirectory)

Pour utiliser ce modèle d’étapes dans le pipeline principal :

trigger:
- main

pool: 'ubuntu-latest'

stages:
- stage: BuildAndTest
 displayName: 'Build and Test Stage'
 jobs:
 - job: NpmInstall
    displayName: 'Npm Install'
    steps:
    - template: templates/npm-install-step.yml
      parameters:
        nodeVersion: '20.X'

Modèles de Variables : Le modèle de variables peut être défini en spécifiant les variables et leurs valeurs dans un fichier YAML séparé. Par exemple :

variables:
  - name: nodeVersion
    value: '18.X'

Et cela peut être utilisé comme ceci :

variables:
    - template: 'templates/variables.yml'

trigger:
- main

pool: 'ubuntu-latest'

stages:
- stage: BuildAndTest
 displayName: 'Build and Test Stage'
 jobs:
 - job: NpmInstall
    displayName: 'Npm Install'
    steps:
    - template: templates/npm-install-step.yml
      parameters:
        nodeVersion: ${{ variables.nodeVersion }}

Avantages de la Templatisation des Pipelines

Consistance et Normalisation : La templatisation garantit que tous les pipelines au sein d’une organisation suivent la même structure et les mêmes conventions. Cette cohérence est cruciale pour maintenir la qualité et réduire le risque d’erreurs.
Réduction de la Duplication : En utilisant des modèles, les pipelines sont plus propres et plus faciles à gérer, mais réduisent également la probabilité d’erreurs.
Maintenabilité Améliorée : Lorsque des modifications doivent être apportées, telles que la mise à jour d’une étape ou l’ajout d’un nouveau paramètre, vous avez seulement besoin de mettre à jour le modèle.
Flexibilité et Personnalisation : Les modèles peuvent être personnalisés avec des paramètres, permettant ainsi l’adaptation du comportement du pipeline aux besoins spécifiques de chaque projet ou étape.

En résumé, l’adoption de la templatisation des pipelines révolutionne les flux de travail CI/CD, favorisant la cohérence, l’efficacité et l’adaptabilité.