Close

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

Portrait de Sten Pittet
Sten Pittet

Auteur collaborateur

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

Durée

30 minutes

Public

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

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

Adoption d'un pipeline de livraison continue

Dans cet exemple, nous allons étendre l'app node.js simple que nous avons intégrée dans le tutoriel sur l'intégration continue en ajoutant un pipeline de livraison continue 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. 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, inscrivez-vous à Heroku.

Ensuite, installez l'interface de ligne de commande Heroku.

Mettez à jour package.json pour qu'il ressemble à ceci :

{
  "name": "cdtutorial",
  "version": "1.0.0",
  "description": "",
  "main": "server.js",
  "scripts": {
    "start": "node server.js",
    "test": "mocha --exit"
  },
  "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"
  }
}

Mettez à jour le fichier server.js pour qu'il ressemble à ceci :

var express = require("express");
var app = express();

app.get("/", function (req, res) {
  res.send("Hello World!");
});

app.listen(process.env.PORT || 3000, function () {
  console.log("Example app listening on port 3000!");
});

module.exports = app;

Notez le changement apporté à app.listen(). Cette fonction inclut désormais process.env.PORT qui est défini par Heroku.

Ajoutez un fichier Procfile au répertoire racine de l'exemple de dépôt en exécutant :

touch Procfile

Ajoutez ensuite le texte suivant au fichier Procfile :

web: npm start

Connectez-vous à Heroku, cliquez sur l'icône utilisateur en haut à droite, cliquez sur Account Setting (Paramètres du compte) et faites défiler vers le bas pour rechercher la clé d'API.

Localisation de la clé d'API dans les paramètres du compte Heroku

Ensuite, ajoutez une variable d'environnement à Bitbucket Pipelines pour pouvoir effectuer un déploiement sur Heroku :

  • HEROKU_API_KEY : vous trouverez votre clé d'API dans votre compte Heroku

Accédez à Pipelines > Environment variables (Pipelines > Variables d'environnement) dans les paramètres de votre dépôt pour ajouter cette variable.

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. Utilisez ce guide comme référence Heroku.

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.

Créez la branche de production dans Bitbucket Cloud en cliquant sur Branches.

Branche de production dans Bitbucket Cloud

Cliquez ensuite sur Create branch (Créer une branche).

Sélectionnez « Create Branch » (Créer une branche) dans la fenêtre contextuelle de Bitbucket Cloud.

Tapez production, puis cliquez sur Create (Créer).

Dans le répertoire racine de l'exemple de dépôt, exécutez :

heroku create --remote staging
git push staging main
heroku create --remote production
git push production main

Pour voir si tout a fonctionné correctement, accédez à Heroku dans un navigateur et vérifiez si deux apps sont répertoriées.

Apps répertoriées dans le navigateur Heroku

Exécutez également :

git remote -vv

Les résultats escomptés présenteront trois remotes. Un pour Bitbucket et deux pour Heroku. L'un sera un remote de staging et les autres, des remotes de production.

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/young-harbor-11356.git (fetch)
production https://git.heroku.com/young-harbor-11356.git (push)
staging https://git.heroku.com/boiling-refuge-14681.git (fetch)
staging https://git.heroku.com/boiling-refuge-14681.git (push)

Configurez ensuite 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. Apportez ce changement dans votre terminal et pushez vers la branche principale initiale.

bitbucket-pipelines.yml

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/boiling-refuge-1468.git main

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

Nous avons maintenant créé un pipeline qui déploiera chaque push depuis la branche principale 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. Apportez ce changement dans votre terminal et pushez vers la branche principale initiale.

bitbucket-pipelines.yml

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
    production:
      - step:
          name: deploy_to_production
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/fierce-basin-45507.git production: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 de production de git remote -vv.

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.

Message « Hello World! » confirmant que l'environnement de production est à jour

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.

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: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
  custom:
    prod-deployment:
      - step:
          name: deploy_to_production
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/fierce-basin-45507.git production: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 de production de git remote -vv.

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.

Sélection et exécution du pipeline depuis Bitbucket

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.

Pipeline de déploiement en production dans Bitbucket

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é !

Message de test « Hello World! » en production

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.

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

Parcours de formation DevOps

Illustration d'une carte

Essayez la solution gratuitement

Inscrivez-vous à notre newsletter Devops

Thank you for signing up