Découvrir le déploiement continu grâce à Bitbucket Pipelines

Nous verrons dans ce guide comment vous pouvez implémenter un pipeline de déploiement continu grâce à Bitbucket Pipelines.

Sten Pittet Sten Pittet

Dans le développement logiciel, vous devez souvent faire des compromis difficiles lors du développement d'une application. Si vous voulez aller plus vite, la croyance générale veut que vous deviez faire des compromis sur la qualité de vos livraisons. Mais il existe une pratique de développement qui peut vous permettre de gagner du temps tout en accélérant les livraisons : il s'agit du déploiement continu.

Avec le déploiement continu, vous éliminez le stress lié au déploiement de logiciels en en faisant un processus automatisé. Votre équipe de développement n'a plus besoin de s'arrêter et de changer de contexte pour une livraison : le code est envoyé aux clients aussitôt qu'un développeur a terminé son travail.

Nous verrons dans ce guide comment vous pouvez implémenter un pipeline de déploiement continu grâce à Bitbucket Pipelines.

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 montrant la différence entre le déploiement et le développement continus | CI/CD Atlassian

Exigences

Durée :

30 minutes

Public :

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

Prérequis :

Essayez-le gratuitement

Configurer un pipeline de déploiement continu

Le déploiement continu est un excellent moyen pour les équipes d'accélérer le développement. Il élimine les obstacles liés au processus d'approbation des livraisons et permet aux développeurs d'obtenir un feedback des clients dès qu'ils ont terminé leur travail. Les tickets sont plus faciles à identifier et à corriger, et il y a moins de changement de contexte, car il n'y a plus de délai de livraison.

La configuration d'un pipeline de déploiement continu grâce à Bitbucket Pipelines est très simple. Nous allons voir comment le faire avec une simple application Hello World qui passe par un environnement de staging et des tests d'acceptation avant d'être livrée automatiquement en production.

Vous pouvez trouver la source de l'application Hello World dans le dépôt lié ci-dessous.

Préparer le déploiement pour Heroku

Avant de commencer, nous devons ajouter quelques variables d'environnement pour pouvoir déployer notre app 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 > Environment variables (Pipelines > Variables d'environnement) dans les paramètres de votre dépôt pour ajouter les variables.

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

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.

Configurer le pipeline

Notre workflow sera simple :

  • Faire un build de l'application.
  • Exécuter des tests sur le build.
  • Déployer en staging.
  • Effectuer des tests d'acceptation en staging.
  • Déployer en production.

Vous verrez qu'il est très facile de créer la configuration de pipeline correspondante. Nous allons commencer par ajouter notre déploiement automatique à l'environnement de staging pour nous assurer qu'il se déroule correctement à chaque push.

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 noterez que nous utilisons un clone complet pour nous assurer que Heroku ne rejette pas notre push. Nous utilisons également un pipeline spécifique à la branche pour nous assurer que nous déployons en staging uniquement les changements pushés vers la principale et non vers les autres branches. Vous pouvez pusher cette configuration vers Bitbucket pour la voir en action.

Le déploiement automatique en staging est terminé


À ce stade, notre application Hello World est maintenant déployée en staging.

Nous pouvons maintenant passer à l'étape suivante et ajouter nos tests d'acceptation. Les tests d'acceptation sont là pour s'assurer que notre application se comporte comme prévu dans un environnement de type production (staging). L'objectif est d'éliminer les incertitudes liées aux différences de configuration entre l'environnement utilisé pour tester le build et votre production.

Si vous observez le code de notre app, notre test fait quelque chose d'extrêmement simple, puisqu'il vérifie simplement la présence de la chaîne « Hello World » sur la page. Dans une application réelle, nous vous recommandons d'avoir des tests d'acceptation qui vont beaucoup plus loin et vérifient que tous les services sous-jacents utilisés par votre application (base de données, cache, applications tierces, etc.) fonctionnent correctement.

Ajoutons donc notre test juste après notre déploiement en staging.

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             - HEROKU_STAGING=$HEROKU_STAGING npm test acceptance-test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main             - npm test acceptance-test  

Après avoir transféré cette nouvelle configuration vers Bitbucket, nous pouvons voir notre pipeline se terminer avec succès.

Bitbucket Pipelines effectue maintenant des tests d'acceptation après avoir été déployé en staging

Il ne reste plus qu'à ajouter notre déploiement en production à la fin pour compléter notre pipeline de déploiement continu.

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             - HEROKU_STAGING=$HEROKU_STAGING npm test acceptance-test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git main  

Un push final vers Bitbucket fera passer nos changements de code par tout le pipeline, en buildant et en testant le code, puis en le déployant en production après avoir vérifié que le staging fonctionne. Dans ce cas, la page d'accueil a été mise à jour avec un message différent pour s'assurer qu'elle serait déployée jusqu'en production.

Notre nouveau message a été déployé en production comme prévu !

Vous pouvez vérifier le pipeline pour vous assurer qu'il est passé correctement par toutes les différentes phases.

Vérifier que le code a été injecté dans le pipeline

Il est important de souligner l'importance de la mise en place d'une bonne suite de tests et d'une surveillance en temps réel avant de se lancer et d'implémenter un déploiement continu pour vos propres dépôts. Dorénavant, les changements seront directement mis en production dès qu'ils seront pushés vers la branche principale. Il est donc d'autant plus important de vous assurer que vos tests automatisés vérifient les parties critiques de votre application. De plus, vous aurez besoin d'outils de monitoring pour détecter les changements qui affectent négativement vos instances de production, qu'il s'agisse d'un bug complet ou d'un service dégradé.

Vous pouvez trouver les sources finales dans le dépôt Bitbucket Cloud accessible via le lien ci-dessous.