Effectuer une migration depuis Travis vers Azure Pipelines

Azure DevOps Services

Ce guide vous aide à migrer de Travis vers Azure Pipelines. Il montre comment traduire une configuration Travis vers une configuration Azure Pipelines.

Différences clés

Travis et Azure Pipelines diffèrent de plusieurs façons, notamment :

• Les builds Travis ont des phases, des travaux et des phases, tandis qu’Azure Pipelines a des étapes que vous organisez et exécutez dans n’importe quel ordre ou regroupement que vous choisissez.

• Azure Pipelines vous permet de stocker des définitions de travaux et des étapes dans des fichiers YAML distincts dans le même référentiel ou un autre référentiel. Cette approche vous permet de partager des étapes entre plusieurs pipelines.

• Azure Pipelines offre un support complet à des fins de génération et de test sur des images Linux, Windows et macOS gérées par Microsoft. Pour plus d’informations sur les agents hébergés, consultez Agents hébergés par Microsoft.

Prérequis

• Un compte GitHub dans lequel vous pouvez créer un référentiel. Créez-en un gratuitement.
• Une organisation Azure DevOps. Créez-en un gratuitement. Si votre équipe dispose déjà d’une organisation Azure DevOps, assurez-vous que vous êtes administrateur du projet Azure DevOps que vous souhaitez utiliser.
• Possibilité d’exécuter des pipelines sur des agents hébergés par Microsoft. Vous pouvez acheter un travail parallèle ou demander un niveau gratuit.
• Connaissances de base d’Azure Pipelines. Si vous débutez avec Azure Pipelines, consultez les articles suivants pour en savoir plus sur Azure Pipelines et son fonctionnement avant de commencer votre migration :
  • Créer votre premier pipeline
  • Concepts clés pour les nouveaux utilisateurs Azure Pipelines

Langage

Travis utilise le mot clé language afin d’identifier l’environnement de build requis pour configurer pour votre build. Par exemple, pour sélectionner Node.js 16.x :

.travis.yml

language: node_js
node_js:
  - 22

Les agents hébergés par Microsoft incluent les kits SDK pour de nombreuses langues par défaut. Pour utiliser une version de langue spécifique, vous devrez peut-être utiliser une tâche de sélection de langue pour configurer l’environnement.

Par exemple, pour sélectionner Node.js 16.x :

azure-pipelines.yml

steps:
- task: UseNode@1
  inputs:
    version: '22.x'

Mappages de langage

Le language mot clé dans Travis CI fonctionne à la fois comme la version des outils de langage à utiliser et un signal implicite que de nombreuses étapes de génération sont effectuées. Dans Azure Pipelines, vous spécifiez les commandes que vous souhaitez exécuter.

Voici un guide de traduction du mot clé language vers les commandes exécutées automatiquement pour les langages les plus couramment utilisés :

Vous pouvez activer des langages moins courants, mais ils nécessitent une autre étape d’installation de dépendance ou une exécution à l’intérieur d’un conteneur Docker :

Sélections de langages multiples

Vous pouvez également configurer un environnement qui prend en charge la génération d’applications différentes dans plusieurs langages. Par exemple, pour garantir que l’environnement de build cible à la fois Node.JS 16.x et Ruby 3.2 ou mieux :

azure-pipelines.yml

steps:
- task: UseNode@1
  inputs:
    version: '8.x'
- task: UseRubyVersion@0
  inputs:
    versionSpec: '>= 3.2'

Phases

Dans Travis, les étapes sont définies dans un ensemble fixe de phases nommées telles que before_install ou before_script. Azure Pipelines ne comporte pas de phases nommées, et les étapes peuvent être regroupées, nommées et organisées selon le pipeline.

Par exemple :

.travis.yml

before_install:
    - npm install -g bower
install:
    - npm install
    - bower install
script:
    - npm run build
    - npm test

azure-pipelines.yml

steps:
- script: npm install -g bower
- script: npm install
- script: bower install
- script: npm run build
- script: npm test

Vous pouvez également regrouper les étapes et éventuellement les nommer :

azure-pipelines.yml

steps:
- script: |
    npm install -g bower
    npm install
    bower install
  displayName: 'Install dependencies'
- script: npm run build
- script: npm test

Travaux parallèles

Travis assure un parallélisme en vous permettant de définir un index, qui est un groupe de travaux exécutés en parallèle. Une build Travis peut comporter plusieurs index ; une fois que tous les travaux d’un index sont terminés, l’index suivant commence.

Avec Azure Pipelines, vous pouvez faire en sorte que chaque étape ou index dépende de n’importe quelle autre étape. De cette façon, vous spécifiez les étapes qui s’exécutent en série et celles qui peuvent s’exécuter en parallèle. Ainsi, vous pouvez effectuer une distribution ramifiée avec plusieurs étapes exécutées en parallèle après l’achèvement d’une étape, puis revenir à une distribution non ramifiée avec une étape unique qui s’exécute par la suite. Ce modèle vous permet de définir des flux de travail complexes, si nécessaire. Pour l’instant, voici un exemple simple :

Par exemple, pour exécuter un script de build, puis, lorsque ce dernier est terminé, exécuter à la fois les tests unitaires et les tests d’intégration en parallèle, et, une fois tous les tests terminés, créer un package avec les artefacts, puis exécuter le déploiement en préproduction :

.travis.yml

jobs:
  include:
  - stage: build
    script: ./build.sh
  - stage: test
    script: ./test.sh unit_tests
  - script: ./test.sh integration_tests
  - stage: package
    script: ./package.sh
  - stage: deploy
    script: ./deploy.sh pre_prod

azure-pipelines.yml

jobs:
- job: build
  steps:
  - script: ./build.sh
- job: test1
  dependsOn: build
  steps:
  - script: ./test.sh unit_tests
- job: test2
  dependsOn: build
  steps:
  - script: ./test.sh integration_tests
- job: package
  dependsOn:
  - test1
  - test2
  script: ./package.sh
- job: deploy
  dependsOn: package
  steps:
  - script: ./deploy.sh pre_prod

Exécution parallèle avancée

Dans Azure Pipelines, vous disposez d’autres options et contrôlez l’orchestration de votre pipeline.

Par exemple, une équipe dispose d’un ensemble de tests unitaires rapides et d’un autre ensemble de tests d’intégration plus lents. L’équipe souhaite commencer à créer le fichier .ZIP à des fins de mise en production dès que l’unité est terminée, car cela garantit avec un degré de confiance élevé que la build fournit un bon package. Toutefois, avant de procéder au déploiement en préproduction, l’équipe veut s’assurer de la réussite de tous les tests :

Dans Azure Pipelines, elle peut le faire de cette façon :

azure-pipelines.yml

jobs:
- job: build
  steps:
  - script: ./build.sh
- job: test1
  dependsOn: build
  steps:
  - script: ./test.sh unit_tests
- job: test2
  dependsOn: build
  steps:
  - script: ./test.sh integration_tests
- job: package
  dependsOn: test1
  script: ./package.sh
- job: deploy
  dependsOn:
  - test1
  - test2
  - package
  steps:
  - script: ./deploy.sh pre_prod

Réutilisation d’une étape

Dans Travis, vous pouvez utiliser des matrices pour exécuter plusieurs exécutions dans une configuration unique. Dans Azure Pipelines, vous pouvez utiliser des matrices de la même façon, mais vous pouvez également implémenter la réutilisation de la configuration à l’aide de modèles.

Exemple : variable d’environnement dans une matrice

L’une des façons les plus courantes d’exécuter plusieurs builds avec une légère variation consiste à modifier l’exécution à l’aide de variables d’environnement. Par exemple, votre script de build peut rechercher la présence d’une variable d’environnement et modifier la façon dont il génère votre logiciel, ou la façon dont il teste le logiciel.

Utilisez une matrice pour exécuter une configuration de build plusieurs fois, une fois pour chaque valeur dans la variable d’environnement. Par exemple, exécutez un script donné trois fois, chaque fois avec un paramètre différent pour une variable d’environnement :

.travis.yml

os: osx
env:
  jobs:
  - MY_ENVIRONMENT_VARIABLE: 'one'
  - MY_ENVIRONMENT_VARIABLE: 'two'
  - MY_ENVIRONMENT_VARIABLE: 'three'
script: echo $MY_ENVIRONMENT_VARIABLE

azure-pipelines.yml

pool:
  vmImage: 'macOS-latest'
strategy:
  matrix:
    set_env_to_one:
      MY_ENVIRONMENT_VARIABLE: 'one'
    set_env_to_two:
      MY_ENVIRONMENT_VARIABLE: 'two'
    set_env_to_three:
      MY_ENVIRONMENT_VARIABLE: 'three'
steps:
- script: echo $(MY_ENVIRONMENT_VARIABLE)

Exemple : versions de langage dans une matrice

Un autre scénario courant consiste à effectuer une exécution sur plusieurs environnements de langage différents. Travis prend en charge une définition implicite grâce au mot clé language, tandis qu’Azure Pipelines attend une tâche explicite pour définir la configuration de cette version de langage.

Vous pouvez utiliser les options de matrice de variable d’environnement dans Azure Pipelines pour activer une matrice pour différentes versions de langage. Par exemple, vous pouvez définir une variable d’environnement dans chaque variable de matrice qui correspond à la version de langage que vous souhaitez utiliser, puis, lors de la première étape, vous pouvez utiliser cette variable d’environnement pour exécuter la tâche de configuration de langage :

.travis.yml

os: linux
jobs:
  include:
  - rvm: 2.3.7
  - rvm: 2.4.4
  - rvm: 2.5.1
script: ruby --version

azure-pipelines.yml

vmImage: 'ubuntu-latest'
strategy:
  matrix:
    ruby 2.3:
      ruby_version: '2.3.7'
    ruby 2.4:
      ruby_version: '2.4.4'
    ruby 2.5:
      ruby_version: '2.5.1'
steps:
- task: UseRubyVersion@0
  inputs:
    versionSpec: $(ruby_version)
- script: ruby --version

Exemple : systèmes d’exploitation dans une matrice

Il est également courant d’exécuter des builds dans plusieurs systèmes d’exploitation. Travis prend en charge cette définition grâce au mot clé os, tandis qu’Azure Pipelines vous permet de configurer le système d’exploitation en sélectionnant le pool à exécuter à l’aide du mot clé vmImage.

Par exemple, vous pouvez définir une variable d’environnement dans chaque variable de matrice qui correspond à l’image du système d’exploitation que vous souhaitez utiliser. Ensuite, vous définissez le pool d’ordinateurs sur la variable que vous définissez :

.travis.yml

jobs:
  include:
  - os: linux
  - os: windows
  - os: osx
script: echo Hello, world!

azure-pipelines.yml

strategy:
  matrix:
    linux:
      imageName: 'ubuntu-latest'
    mac:
      imageName: 'macOS-latest'
    windows:
      imageName: 'windows-latest'

pool:
  vmImage: $(imageName)

steps:
- script: echo Hello, world!

Gestion des réussites et des échecs

Travis vous permet de spécifier des étapes qui s’exécutent lorsque la compilation réussit, à l’aide de la after_success phase, ou lorsque la compilation échoue, à l’aide de la after_failure phase. En utilisant Azure Pipelines, vous pouvez définir des conditions de réussite et d’échec en fonction du résultat de n’importe quelle étape, ce qui permet des pipelines plus flexibles et puissants.

.travis.yml

build: ./build.sh
after_success: echo Success 
after_failure: echo Failed 

azure-pipelines.yml

steps:
- script: ./build.sh
- script: echo Success
  condition: succeeded()
- script: echo Failed
  condition: failed()

Gestion avancée des réussites et des échecs

Dans Azure Pipelines, vous pouvez programmer un ensemble flexible de dépendances et de conditions pour contrôler des flux entre plusieurs travaux.
Vous pouvez configurer des travaux à exécuter en fonction de la réussite ou de l’échec de travaux précédents ou en fonction de variables d’environnement. Vous pouvez même configurer des travaux pour qu’ils s’exécutent en permanence, quelle que soit la réussite des autres travaux.

Par exemple, si vous souhaitez exécuter un script en cas d’échec de la build, mais uniquement dans le cas d’une exécution en tant que build sur la branche primaire :

azure-pipelines.yml

jobs:
- job: build
  steps:
  - script: ./build.sh
- job: alert
  dependsOn: build
  condition: and(failed(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  steps:
  - script: ./sound_the_alarms.sh

Variables prédéfinies

Travis et Azure Pipelines définissent plusieurs variables d’environnement pour vous aider à inspecter et à interagir avec l’environnement d’exécution du système CI.

Dans la plupart des cas, une variable Azure Pipelines correspond à la variable d’environnement dans Travis. Voici une liste des variables d’environnement couramment utilisées dans Travis et leur variable analogique dans Azure Pipelines :

Raisons de la compilation :

La variable TRAVIS_EVENT_TYPE contient des valeurs qui correspondent aux valeurs fournies par la variable BUILD_REASON Azure Pipelines :

Système d’exploitation :

La variable TRAVIS_OS_NAME contient des valeurs qui correspondent aux valeurs fournies par la variable AGENT_OS Azure Pipelines :

Pour plus d’informations, consultez Variables d’environnement prédéfinies.

S’il n’existe aucune variable pour les données dont vous avez besoin, utilisez une commande shell pour l’obtenir. Par exemple, un bon substitut à une variable d’environnement contenant l’ID de validation de la pull request en cours de création consiste à exécuter une commande git : git rev-parse HEAD^2.

Génération de branches spécifiques

Par défaut, Travis et Azure Pipelines effectuent des builds CI sur toutes les branches. De même, les deux systèmes vous permettent de limiter ces builds à des branches spécifiques. Dans Azure Pipelines, les branches à générer doivent être répertoriées dans la liste include, et les branches à ne pas générer doivent être répertoriées dans la liste d’exclusion. Les caractères génériques sont pris en charge.

Par exemple, pour générer uniquement la branche primaire et celles qui commencent par le mot « releases » (mises en production) :

.travis.yml

branches:
  only:
  - main
  - /^releases.*/

azure-pipelines.yml

trigger:
  branches:
    include:
    - main
    - releases*

Mise en cache de la sortie

Travis prend en charge la mise en cache des dépendances et de la sortie de build intermédiaire pour améliorer les temps de génération. Azure Pipelines ne prend pas en charge la mise en cache de la sortie de build intermédiaire, mais offre une intégration par le biais d’Azure Artifacts aux fins du stockage des dépendances.

Sous-modules Git

Travis et Azure Pipelines clonent les dépôts Git de manière récursive par défaut. Ce paramètre par défaut signifie que l’agent clone les sous-modules, ce qui est utile, car les sous-modules contiennent généralement des dépendances. Toutefois, le clonage supplémentaire prend du temps supplémentaire. Si vous n’avez pas besoin des dépendances, désactivez le clonage des sous-modules :

.travis.yml

git:
  submodules: false

azure-pipelines.yml

checkout:
  submodules: false