Créer un pipeline de construction avec Travis CI

1. Introduction

Dans le développement logiciel moderne, le terme pipeline est beaucoup utilisé. Mais qu'est-ce que c'est?

De manière générale, un pipeline de build est un ensemble d'étapes automatisées qui déplacent le code du développement à la production .

Les pipelines de construction sont parfaits pour mettre en œuvre des flux de travail d'intégration continue pour les logiciels. Ils nous permettent de créer des changements plus petits avec une plus grande fréquence , dans le but de trouver les bogues plus tôt et de réduire leur impact.

Dans ce didacticiel, nous examinerons la création d'un pipeline de construction simple à l'aide de Travis CI.

2. Étapes d'un pipeline de construction

Un pipeline de build peut comprendre de nombreuses étapes différentes, mais au minimum, il doit inclure:

  • Compiler du code : dans notre cas, cela signifie compiler le code source Java dans des fichiers de classe
  • Exécuter des tests : comme exécuter des tests unitaires et éventuellement des tests d'intégration
  • Déployer des artefacts : empaqueter le code conforme en artefacts, par exemple dans des fichiers jar , et les déployer

Si une application utilise des technologies différentes, des étapes supplémentaires peuvent être incluses dans le pipeline de génération . Par exemple, nous pourrions avoir une étape supplémentaire qui réduit les fichiers JavaScript ou publie une documentation API mise à jour.

3. Qu'est-ce que Travis CI?

Pour notre exemple de pipeline de build, nous utiliserons Travis CI, un outil d'intégration continue basé sur le cloud .

Cela a un certain nombre de fonctionnalités qui en font un excellent choix pour commencer à construire des pipelines:

  • S'intègre rapidement à n'importe quel référentiel GitHub public
  • Prend en charge tous les principaux langages de programmation
  • Se déploie sur plusieurs plates-formes cloud différentes
  • Offre une variété d'outils de messagerie et d'alerte

À un niveau élevé, cela fonctionne en surveillant un référentiel GitHub pour les nouveaux commits.

Lorsqu'un nouveau commit est effectué, il exécute les étapes du pipeline de construction telles que définies dans un fichier de configuration (plus d'informations ci-dessous). Si une étape échoue, le pipeline se termine et il nous en informera.

Hors de la boîte, Travis CI nécessite très peu de configuration. La seule configuration requise est la spécification du langage de programmation .

Nous pouvons toujours fournir plus de configuration pour adapter notre pipeline si nécessaire. Par exemple, nous pouvons limiter les branches qui déclenchent les builds, ajouter des étapes supplémentaires au pipeline, et bien plus encore.

3.1. Versions gratuites et payantes

Il est important de savoir que Travis CI propose actuellement 2 offres: une version gratuite et une version payante.

La version gratuite, désignée par le nom de domaine .org , offre des fonctionnalités complètes pour tout référentiel GitHub public . Il n'y a aucune limite au nombre de builds ou de référentiels, bien que des limites de ressources soient imposées lorsque votre pipeline est en cours d'exécution.

La version payante, qui utilise le nom de domaine .com , est requise pour les référentiels GitHub privés. Il offre également plus de builds simultanés et des minutes de build illimitées par rapport au plan gratuit. Il existe un essai gratuit pour les 100 premières versions pour tester la version payante.

4. Création d'un pipeline de construction avec Travis CI

Pour ce tutoriel, nous utiliserons la version gratuite mentionnée ci-dessus. Tout référentiel public peut être utilisé pour créer un pipeline gratuit.

Tout ce que nous avons à faire est de nous connecter à Travis CI avec notre compte GitHub et de l'autoriser:

Une fois que nous avons accordé des autorisations à notre compte GitHub, nous sommes prêts à commencer à configurer notre pipeline de build.

4.1. Configuration du référentiel

Au départ, tous nos référentiels publics sont considérés comme inactifs. Pour résoudre ce problème, nous devons activer notre référentiel à partir de la page des paramètres du compte .

Cela répertorie tous nos référentiels publics, ainsi qu'un bouton bascule. Cliquez sur le bouton bascule pour configurer Travis CI pour commencer à surveiller ce référentiel pour les nouveaux commits, en utilisant la branche par défaut de master:

Notez que chaque référentiel dispose également d'un bouton Paramètres . C'est ici que nous pouvons configurer différents comportements de pipeline:

  • Définir les événements qui déclenchent le pipeline (push, pull requests, etc.)
  • Définir les variables d'environnement qui sont transmises au pipeline
  • Annulation automatique des builds lorsque de nouveaux événements sont déclenchés

Pour ce didacticiel, les paramètres par défaut fonctionneront correctement. Plus tard, nous verrons comment remplacer certains des comportements par défaut.

4.2. Création de la configuration Travis

L'étape suivante consiste à créer un nouveau fichier nommé .travis.yml dans le répertoire racine de notre référentiel. Ce fichier contient toutes les informations nécessaires pour configurer un pipeline. Sans ce fichier, le pipeline ne s'exécutera pas .

Pour ce didacticiel, nous devons simplement inclure la configuration minimale, qui spécifie le langage de programmation:

language: java

C'est ça! Sans fournir plus d'informations, Travis CI exécutera un pipeline simple qui:

  • Compile notre code source
  • Exécute nos tests

Une fois que nous avons validé le fichier .travis.yml , Travis lancera notre première compilation. Tout autre commit dans la branche master déclenchera des builds supplémentaires. Le tableau de bord nous permet également de déclencher manuellement le pipeline à tout moment sans nécessiter de demande de validation ou d'extraction.

5. Configuration supplémentaire

Dans la section précédente, nous avons vu qu'une seule ligne de configuration est tout ce dont nous avons besoin pour exécuter notre pipeline de construction. Mais la plupart des projets nécessiteront une configuration supplémentaire pour mettre en œuvre un pipeline significatif.

Cette section décrit certaines des configurations les plus utiles que nous pourrions souhaiter ajouter à notre pipeline.

5.1. Modification de la commande de construction par défaut

La commande par défaut utilisée pour construire des projets Maven est:

mvn test -B

Nous pouvons changer cela en n'importe quelle commande en définissant la directive de script dans .travis.yml :

script: mvn package -DskipTests

Il est possible d'enchaîner plusieurs commandes dans une seule ligne de script à l'aide de l' opérateur && .

Certaines commandes de construction sont complexes et peuvent s'étendre sur plusieurs lignes ou avoir une logique complexe. Par exemple, ils peuvent effectuer différentes actions basées sur des variables d'environnement.

Dans ces cas, il est recommandé de placer la commande build dans un script autonome et d'appeler ce script depuis le fichier de configuration:

script: ./build.sh

5.2. Déploiement du code

Les paramètres de construction par défaut pour les projets Java compilent simplement le code et exécutent des tests. Les artefacts résultants (fichiers .jar, etc.) sont supprimés à la fin du pipeline à moins que nous ne les déployions quelque part.

Travis CI prend en charge une variété de services tiers bien connus. Les artefacts peuvent être copiés sur de nombreux systèmes de stockage cloud populaires tels que Amazon S3, Google Cloud Storage, Bintray, etc.

Il peut également déployer du code directement sur les plates-formes de cloud computing les plus populaires telles que AWS, Google App Engine, Heroku et bien d'autres.

Voici un exemple de configuration montrant comment nous pouvons déployer sur Heroku. Pour générer des propriétés cryptées, nous devons utiliser l'outil Travis CLI.

deploy: provider: heroku api_key: secure: "ENCRYPTED_API_KEY"

De plus, il fournit une option de déploiement générique qui nous permet d'écrire notre propre script de déploiement. Ceci est utile si nous devons déployer des artefacts sur un système tiers qui n'est pas pris en charge de manière native.

Par exemple, nous pourrions écrire un script shell qui copie en toute sécurité les artefacts sur un serveur FTP privé:

deploy: provider: script script: bash ./custom-deploy.sh

5.3. Gestion des branches qui déclenchent le pipeline

Par défaut, le pipeline s'exécutera pour toute validation sur master . Cependant, la plupart des grands projets utilisent une forme de branchement git pour gérer les cycles de développement.

Travis CI prend en charge à la fois la liste blanche et la liste noire des branches git pour déterminer quels commits doivent déclencher le pipeline.

À titre d'exemple, considérons la configuration suivante:

branches: only: - release - stable except: - master - nightly

Cela ignorerait les commits sur les branches principales et nocturnes . Les validations vers la version et les branches stables déclencheraient le pipeline. Notez que la seule directive a toujours la priorité sur la directive except .

Nous pouvons également utiliser des expressions régulières pour contrôler les branches qui déclenchent le pipeline:

branches: only: - /^development.*$/

Cela démarrerait le pipeline uniquement pour les commits sur les branches commençant par le développement .

5.4. Ignorer des validations spécifiques

Nous pouvons utiliser le message git commit pour ignorer les commits individuels . Travis CI examinera le message pour les modèles suivants:

  • sauter
  • sauter

Où est l'une des valeurs suivantes:

  • ci
  • Travis
  • travis ci
  • travis-ci
  • travisci

Si le message de validation correspond à l'un de ces modèles, le pipeline ne s'exécutera pas.

5.5. Utilisation de différents environnements de construction

L'environnement de construction par défaut pour les projets Java est Ubuntu Linux. Les pipelines peuvent également s'exécuter sur Mac OSX ou Windows Server en ajoutant la configuration suivante dans .travis.yml :

os: osx # can also be 'windows'

Même avec Linux, il existe 3 distributions différentes parmi lesquelles nous pouvons choisir:

os: linux dist: xenial # other choices are 'trusty' or 'precise'

La documentation de la plateforme de construction couvre tous les environnements disponibles et leurs différences.

Rappelez - vous que si nous changeons la plate - forme, nous pourrions avoir besoin aussi de changer de coutume construire ou déployer des scripts pour assurer la compatibilité. Il existe plusieurs façons de gérer plusieurs systèmes d'exploitation en configuration.

5.6. Utilisation de différentes versions de JDK

Nous pouvons également tester une version spécifique du JDK en définissant la configuration suivante dans le fichier .travis.yml :

jdk: oraclejdk8

Gardez à l'esprit que différents environnements de construction, même les différentes distributions Linux, peuvent avoir différentes versions de JDK disponibles. Consultez la documentation de chaque environnement pour voir la liste complète des versions de JDK.

6. Construire des matrices

Par défaut, chaque fois que notre pipeline s'exécute, il s'exécute comme une tâche unique. Cela signifie que toutes les phases du pipeline s'exécutent séquentiellement sur une seule machine virtuelle avec les mêmes paramètres.

Mais l'une des grandes fonctionnalités de Travis CI est la possibilité de créer une matrice de construction. Cela nous permet d'exécuter plusieurs tâches pour chaque validation, en utilisant des valeurs différentes pour certains des paramètres que nous avons vus précédemment.

Par exemple, nous pouvons utiliser une matrice de construction pour exécuter notre pipeline à la fois sur Linux et Mac OSX, ou avec les JDK 8 et 9.

Il existe deux façons de créer des matrices de construction . Tout d'abord, nous pouvons fournir un tableau de valeurs pour une ou plusieurs des configurations de langage et d'environnement que nous avons vues précédemment. Par exemple:

language: java jdk: - openjdk8 - openjdk9 os: - linux - osx

En utilisant cette approche, Travis CI étendra automatiquement chaque combinaison de configuration pour former plusieurs tâches. Dans l'exemple ci-dessus, le résultat serait quatre emplois au total.

La deuxième façon de créer une matrice de construction consiste à utiliser la directive matrix.include . Cela nous permet de déclarer explicitement les combinaisons que nous voulons exécuter:

language: java matrix: include: - jdk: openjdk8 os: linux - jdk: openjdk9 os: osx

L'exemple ci-dessus entraînerait deux emplois.

Encore une fois, si nous construisons sur plusieurs systèmes d'exploitation, nous devons veiller à ce que nos scripts de construction et de déploiement fonctionnent dans tous les cas. Les scripts Shell ne fonctionneront pas sous Windows, par exemple. Nous devons utiliser des instructions conditionnelles appropriées pour gérer différents systèmes d'exploitation.

Il existe d'autres options qui offrent un contrôle plus granulaire sur les tâches à créer et sur la manière de gérer les échecs.

7. Conclusion

Dans cet article, nous avons créé un pipeline de construction simple à l'aide de Travis CI. En utilisant principalement une configuration prête à l'emploi, nous avons créé un pipeline qui construit du code et exécute des tests.

Nous avons également vu un petit exemple de la configuration de Travis CI. Il fonctionne avec une variété de langages de programmation et de plates-formes cloud tierces. Le seul inconvénient est qu'il ne fonctionne actuellement qu'avec les référentiels GitHub.