Close

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

Portrait de Sten Pittet
Sten Pittet

Auteur collaborateur

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

Durée

30 minutes

Public

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

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

Configurer un pipeline de déploiement continu

Dans cet exemple, nous allons étendre l'app node.js simple que nous avons intégrée dans en ajoutant 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.

Étape 1 : Créez une app Heroku

Dans le tutoriel sur la livraison continue, nous avons pushé une branche avec des merges vers l'app Heroku en production. Nous allons créer une autre app Heroku pour éviter les conflits lors du push dans ce tutoriel. Exécutez la commande suivante.

heroku create --remote production2
git push production2 main

Maintenant, git remote -vv affiche quelque chose qui ressemble à ceci. Utilisez le staging et production2 dans la suite de ce tutoriel.

wmarusiak@C02F207NML7L cdtutorial % git remote -vv
origin git@bitbucket.org:pmmquickstartguides01/cdtutorial.git (fetch)
origin git@bitbucket.org:pmmquickstartguides01/cdtutorial.git (push)
production https://git.heroku.com/fierce-basin-45507.git (fetch)
production https://git.heroku.com/fierce-basin-45507.git (push)
production2 https://git.heroku.com/limitless-headland-92324.git (fetch)
production2 https://git.heroku.com/limitless-headland-92324.git (push)
staging https://git.heroku.com/thawing-river-12585.git (fetch)
staging https://git.heroku.com/thawing-river-12585.git (push)

Étape 2 : Configurez 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:16

clone:
  depth: full

pipelines:
  branches:
    main:
      - step:
          name: deploy_to_staging
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main

Veillez à remplacer l'URL git push pour la branche principale par l'URL de staging de git remote -vv.

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.

Push de la configuration vers Bitbucket Pipelines

Le déploiement automatique en staging est terminé

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

Capture d'écran de l'application « Hello World » 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.

Pour ajouter un test d'acceptation, procédez comme suit.

mkdir acceptance-test
touch acceptance-test/test.js

Modifiez ensuite acceptance-test/test.js et ajoutez le snippet de code suivant.

var request = require('supertest');

// Running a test on our staging environment
describe('GET /', function() {
  it('displays "Hello World!" on staging', function(done) {
    var staging_url = 'https://' + process.env.HEROKU_STAGING + '.herokuapp.com'
    // The line below is the core test of our app.
    request(staging_url).get("/").expect("Hello World!", done);
  });
});

Mettez à jour le fichier package.json pour inclure --timeout 10000.

{
  "name": "cdtutorial",
  "version": "1.0.0",
  "description": "",
  "main": "server.js",
  "scripts": {
    "start": "node server.js",
    "test": "mocha --exit --timeout 10000"
  },
  "repository": {
    "type": "git",
    "url": "git+ssh://git@bitbucket.org/pmmquickstartguides01/cdtutorial.git"
  },
  "author": "",
  "license": "ISC",
  "bugs": {
    "url": "https://bitbucket.org/pmmquickstartguides01/cdtutorial/issues"
  },
  "homepage": "https://bitbucket.org/pmmquickstartguides01/cdtutorial#readme",
  "dependencies": {
    "express": "^4.17.3"
  },
  "devDependencies": {
    "mocha": "^9.2.2",
    "supertest": "^6.2.2"
  }
}

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

image: node:16

clone:
  depth: full

pipelines:
  branches:
    main:
      - step:
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
            - HEROKU_STAGING=thawing-river-12585 npm test acceptance-test

Veillez à remplacer l'URL git push pour la branche principale par l'URL de staging de git remote -vv.

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

Pipeline exécuté avec succès dans Bitbucket

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:16

clone:
  depth: full

pipelines:
  branches:
    main:
      - step:
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
            - HEROKU_STAGING=thawing-river-12585 npm test acceptance-test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/limitless-headland-92324.git main

Veillez à remplacer l'URL git push pour la branche principale par l'URL de staging de git remote -vv, et l'URL git push pour la branche de production par l'URL production2 de git remote -vv.

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.

Message de la page d'accueil mis à jour pour confirmer qu'il a été déployé en production « Hello World! Straight to production! »

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

Finalisation du pipeline de déploiement continu dans Bitbucket

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 vous 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.

Sten Pittet
Sten Pittet

Cela fait maintenant dix ans que je travaille dans le secteur logiciel et j'ai occupé différentes fonctions, du développement à la gestion de produits. Après avoir passé les cinq dernières années chez Atlassian à travailler sur des outils de développement, j'écris désormais des articles sur le développement des logiciels. En dehors de mon travail, j'affine mes compétences de père au contact d'un adorable bébé.


Partager cet article

Lectures recommandées

Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.

Illustration Devops

Communauté DevOps

Illustration Devops

Atelier de simulation

Illustration d'une carte

Essayez la solution gratuitement

Inscrivez-vous à notre newsletter Devops

Thank you for signing up