Découvrir la livraison continue grâce à Bitbucket Pipelines

Dans ce guide, nous verrons comment utiliser Bitbucket Pipelines pour adopter un workflow de livraison continue. Poursuivez votre lecture ! 

Sten Pittet Sten Pittet

Exigences

Durée :

30 minutes

Public :

Vous êtes novice en matière de livraison continue et/ou vous débutez dans Bitbucket Pipelines.

Prérequis :

Essayez-le gratuitement

La livraison d'une nouvelle fonctionnalité est toujours un moment passionnant, car vous êtes sur le point de proposer de nouvelles fonctionnalités à vos clients. Mais il peut aussi s'agir d'un exercice risqué nécessitant beaucoup de préparation, et votre équipe peut éprouver des réticences à s'y adonner trop souvent. Et plus vous attendez, plus il devient difficile de déployer en production. Les changements s'accumulent, il est difficile de comprendre le périmètre du changement, et il sera difficile d'identifier les causes profondes si des problèmes surviennent en production.

Une façon simple d'éliminer la crainte et le coût liés au déploiement de logiciels est d'automatiser cette étape et de livrer plus fréquemment les moindres changements. Tout d'abord, vous vous épargnerez le nombre incalculable d'heures qui sont normalement consacrées à la préparation de la livraison. Vous réduirez également le risque lié au déploiement de logiciels en ayant un périmètre beaucoup plus restreint pour chaque livraison, ce qui facilitera la surveillance des environnements et la résolution des tickets.

Cette automatisation du déploiement est quelque chose que vous pouvez réaliser facilement grâce à Bitbucket Cloud aujourd'hui. Pour chacun de vos dépôts, vous pouvez configurer un pipeline qui va automatiquement développer, tester et déployer votre code dans vos environnements à chaque push. Nous verrons dans ce guide comment vous pouvez utiliser Bitbucket Pipelines pour adopter un workflow de livraison continue.

Livraison continue ou déploiement continu

La livraison continue est la pratique qui consiste à vous assurer que votre code est toujours prêt à être livré, même si vous ne déployez pas chaque changement en production. Il est recommandé de mettre à jour votre production aussi souvent que possible pour vous assurer que le périmètre des changements reste limité, mais en fin de compte, c'est vous qui contrôlez la cadence de vos livraisons.

Dans le cadre du déploiement continu, les nouveaux changements apportés au dépôt sont automatiquement déployés en production s'ils réussissent les tests. Cela met davantage l'accent (lire : la pression) sur votre culture de test, mais c'est un excellent moyen d'accélérer la boucle de feedback avec vos clients.

Diagramme présentant la livraison continue et l'intégration continue (CI et CD) | CI/CD Atlassian

Adoption d'un pipeline de livraison continue

Dans cet exemple, nous allons créer un pipeline de livraison continue simple qui se déploie automatiquement en staging lorsque le build réussit le test. Nous verrons deux stratégies différentes pour le déploiement en production : l'une utilisant des branches et des pull requests, l'autre utilisant des pipelines personnalisés et des déclencheurs manuels.

Dans les deux exemples, nous utiliserons une application Node.js simple qui affiche un message « Hello World » dans votre navigateur. Vous pouvez cloner le code de l'application « Hello World » ci-dessous et l'utiliser pour suivre ce tutoriel.

Nous allons déployer cette application dans des environnements de staging et de production hébergés sur Heroku en utilisant les deux méthodes.

Une application Hello World de base | CI/CD Atlassian

Notre application Hello World très simple

Préparer le déploiement pour Heroku

Pour commencer, nous devrons ajouter quelques variables d'environnement à Bitbucket Pipelines pour pouvoir effectuer un déploiement sur Heroku :

  • HEROKU_API_KEY : vous trouverez votre clé API dans votre compte Heroku
  • HEROKU_STAGING : nom de votre environnement de staging
  • HEROKU_PROD : nom de votre environnement de production

Accédez à Pipelines > Variables d'environnement dans les paramètres de votre dépôt pour ajouter toutes ces variables.

Capture d'écran de la configuration d'Heroku dans Bitbucket | CI/CD Atlassian

Configuration des variables d'environnement à déployer sur Heroku

Nous utilisons Heroku dans ce guide, mais il est tout à fait possible d'adapter cet exemple à d'autres services d'hébergement. Vous trouverez d'autres guides de déploiement dans la documentation.

Livraison continue avec des branches comme validation vers la production

Cette configuration convient aux équipes qui ont des branches de livraison spéciales pouvant être mappées à un déploiement. Elle vous permet également de réviser les changements d'une pull request avant qu'ils ne soient déployés en production.

Dans cette configuration, nous allons utiliser deux branches différentes pour déclencher des déploiements :

  • Branche principale (main) : tout push vers la branche principale déploiera le code dans un environnement de staging après l'exécution des tests.
  • production : le code mergé à la branche de production sera automatiquement livré dans l'environnement de production.

Nous allons d'abord configurer le déploiement en staging. Pour ce faire, nous utilisons les pipelines spécifiques aux branches et nous créons un pipeline qui est exécuté pour chaque push sur la branche principale.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     # When code is pushed to the main branch it is deployed automatically to the staging environment.     main:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main

Nous avons maintenant créé un pipeline qui déploiera chaque push vers la branche principale puis vers Heroku après avoir créé et testé notre application. La section clone au début de la configuration garantit que nous effectuons un clone complet (sinon Heroku pourrait rejeter la commande git push). Il suffit de pusher cette configuration vers Bitbucket pour voir votre premier déploiement automatisé jusqu'au staging.

Capture d'écran d'un déploiement de pipeline réussi | CI/CD Atlassian

Un pipeline réussi qui déploie notre application en staging

Comme vous l'avez peut-être deviné, nous avons juste besoin d'ajouter un autre pipeline de branche pour la branche de production afin de livrer automatiquement l'environnement de production lorsque des changements sont mergés dans la branche de production.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     # When code is pushed to the main branch it is deployed automatically to the staging environment.     main:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main     # When code is pushed to the main branch it is deployed automatically to the production environment.     production:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git production:main  

Nous exécutons à nouveau les tests sur la branche de production pour nous assurer que rien n'affecte le build avant de livrer l'application.

Nos pipelines sont maintenant configurés et nous pouvons restreindre la branche de production pour accepter les merges uniquement par le biais de pull requests. Accédez simplement à Workflow > Autorisations de branches dans les paramètres de votre dépôt pour restreindre la branche de production. Il s'agit d'une étape importante, car nous voulons empêcher les gens de passer directement à la production à partir de leur machine locale.

Configuration des autorisations de la branche de production | CI/CD Atlassian

Configuration des autorisations de la branche de production

Dans la capture d'écran ci-dessus, vous pouvez voir les autorisations :

  • Personne n'a accès en écriture (Nobody has write access)
  • Un seul développeur peut merger dans la branche

Nous avons également ajouté une vérification des merges pour nous assurer que la branche source a au moins un build fonctionnel avant de merger le code. Cela nous permettra de gagner du temps de build et d'empêcher les développeurs de merger le mauvais code à notre branche de production.

Ensuite, vous pouvez créer une pull request pour merger le code de la branche principale vers la production, puis livrer les nouveaux changements dans votre environnement de production.

Capture d'écran Bitbucket d'une création de pull request | CI/CD Atlassian

Création d'une pull request pour merger les changements en production

Dès que vous mergez la pull request, un nouveau pipeline est déclenché pour la branche de production.

Un pipeline a été déclenché avec succès par la pull request | CI/CD Atlassian

Ensuite, vos nouveaux changements auront été déployés avec succès dans l'environnement de production.

L'environnement de production est à jour !

Vous avez maintenant configuré un workflow de livraison continue grâce à Bitbucket Pipelines, et vous pouvez utiliser en toute sécurité les pull requests pour livrer du code à vos clients.

Vous trouverez la source finale de cet exemple dans le dépôt lié ci-dessous.

Livraison continue avec déclencheur manuel pour la livraison

Cette configuration est idéale pour les équipes qui pratiquent le Trunk-Based Development.

Avec Bitbucket Pipelines, il est possible de configurer des pipelines personnalisés qui peuvent être déclenchés manuellement. Ces pipelines peuvent être utilisés à diverses fins : pour des tests de longue durée que vous ne voulez pas exécuter à chaque push ou des actions spécifiques que vous voulez contrôler vous-même. Nous utiliserons un pipeline personnalisé pour mettre en place un workflow de livraison continue dans lequel les pushs vers la branche principale sont automatiquement déployés dans un environnement de staging, et les commits peuvent être déployés manuellement en production.

Tout d'abord, nous devons configurer le déploiement automatique en staging. Il vous suffit d'ajouter un pipeline spécifique à la branche principale qui déploiera l'environnement de staging.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     main:       - step:           script: # Modify the commands below to build your repository.             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main  

Vous pouvez transférer cette configuration dans votre dépôt pour voir le premier déploiement en staging en action.

Notre premier déploiement automatique en staging

Maintenant que notre déploiement intermédiaire est configuré, nous pouvons simplement ajouter un pipeline personnalisé à notre configuration bitbucket-pipelines.yml que nous utiliserons pour déclencher manuellement la livraison en production.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     main:       - step:           script: # Modify the commands below to build your repository.             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main   custom:     prod-deployment:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git main  

Après avoir pushé la nouvelle configuration vers votre dépôt Bitbucket, vous pouvez accéder au commit et cliquer sur le lien Run pipeline (Exécuter le pipeline) sous les informations de commit pour déclencher le déploiement en production.

L'action Run pipeline (Exécuter le pipeline) répertoriera les pipelines personnalisés disponibles

Appuyez simplement sur le bouton Run (Exécuter) et vous serez redirigé vers le pipeline de déploiement en production où vous pouvez surveiller les journaux.

Dans la section relative aux informations de commit du pipeline, vous pouvez voir le nom du pipeline personnalisé qui a été utilisé. Vous êtes maintenant prêt à utiliser votre nouvelle configuration Bitbucket Pipelines pour la livraison continue, et vous pouvez vérifier votre application Hello World en production pour vous assurer que tout s'est bien passé !

Notre Hello World a été déployé en production à l'aide d'un déclencheur manuel

Vous trouverez la source finale de cet exemple dans le dépôt lié ci-dessous.