Articles
Tutoriels
Guides interactifs
Découvrir la livraison continue grâce à Bitbucket Pipelines
Sten Pittet
Auteur collaborateur
Dans ce guide, nous verrons comment 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.
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.
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 ProcfileAjoutez ensuite le texte suivant au fichier Procfile :
web: npm startConnectez-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.
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.
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.
Cliquez ensuite sur Create branch (Créer une branche).
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 mainPour voir si tout a fonctionné correctement, accédez à Heroku dans un navigateur et vérifiez si deux apps sont répertoriées.
Exécutez également :
git remote -vvLes 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 mainVeillez à 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.
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:mainVeillez à 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
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.
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.
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.
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:mainVeillez à 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.
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.
Partager cet article
Thème suivant
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.
Communauté DevOps
Parcours de formation DevOps
