Close

Meer informatie over continue levering met Bitbucket Pipelines

Headshot van Sten Pittet
Sten Pittet

Mede-auteur

In deze handleiding leggen we uit hoe je Bitbucket Pipelines kunt gebruiken om een workflow voor continue levering te implementeren. Lees verder!

Tijd

30 minuten

Publiek

Continue implementatie en/of Bitbucket Pipelines is nieuw voor je

Het uitbrengen van een nieuwe functie is altijd een spannend moment omdat je op het punt staat je klanten nieuwe mogelijkheden te bieden. Maar het kan ook een riskante oefening zijn die veel voorbereiding vereist, waardoor je team terughoudend is om het vaak te doen. En hoe langer je wacht, hoe moeilijker het wordt om naar productie te implementeren. Veranderingen stapelen zich op, het is moeilijk om de scope van de verandering te begrijpen en het zal moeilijk zijn om de hoofdoorzaken te identificeren als er problemen optreden in de productie.

Een eenvoudige manier om de angst en de kosten van het implementeren van software weg te nemen, is door dit te automatiseren en vaker kleinere wijzigingen te releasen. Allereerst bespaar je talloze uren die normaal gesproken worden besteed aan het voorbereiden van de release. Maar je vermindert ook het risico van het implementeren van software door voor elke release een veel kleiner scope te hebben, waardoor het gemakkelijker wordt omgevingen te controleren en problemen op te lossen.

Deze implementatie-automatisering is iets dat je vandaag nog eenvoudig kunt doen met Bitbucket Cloud. Voor elk van je repository's kun je een pipeline configureren die automatisch bij elke push je code bouwt, test en implementeert in je omgevingen. In deze handleiding behandelen we hoe je Bitbucket Pipelines kunt gebruiken om een workflow voor continue levering te implementeren.

Continue levering versus continue implementatie

Continue levering is een werkwijze om ervoor te zorgen dat je code altijd gereleased kan worden, zelfs als je niet elke wijziging doorvoert naar productie. Het is aanbevolen om je productie zo vaak mogelijk bij te werken om ervoor te zorgen dat je de scope van de wijzigingen klein houdt, maar uiteindelijk heb jij de controle over het ritme van je releases.

Bij continue implementatie worden nieuwe wijzigingen die naar de repository worden doorgevoerd automatisch geïmplementeerd voor productie als ze de tests doorstaan. Dit legt meer nadruk (lees: druk) op je testcultuur, maar het is een geweldige manier om de feedbackloop met je klanten te versnellen.

Diagram met het verschil tussen continue implementatie en continue ontwikkeling | Atlassian CI/CD

Een continue levering-pipeline implementeren

In dit voorbeeld breiden we de eenvoudige node.js-app uit die we in de Tutorial Continue integratie bouwden, door een continue levering-pipeline toe te voegen die automatisch implementeert naar staging als de build de test doorstaat. We gaan twee verschillende strategieën zien voor de productie-implementatie: één die gebruikmaakt van branches en pull requests en de ander van aangepaste pipelines en handmatige triggers.

In beide voorbeelden gebruiken we een eenvoudige Node.js-toepassing die 'Hello World' in je browser toont. We zullen deze toepassing op beide manieren implementeren in staging- en productieomgevingen die op Heroku worden gehost.

Een eenvoudige Hello World-toepassing | Atlassian CI/CD

Onze zeer eenvoudige Hello World-toepassing

De implementatie naar Heroku voorbereiden

Meld je aan voor Heroku om te beginnen.

Installeer vervolgens de Heroku CLI.

Werk package.json bij tot die er ongeveer zo uitziet:

{
  "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"
  }
}

Werk het bestand server.js bij tot die er ongeveer zo uitziet:

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;

Let op de wijziging aan app.listen (). Dit omvat nu ook process.env.PORT dat is ingesteld door Heroku.

Voeg een Procfile toe aan de hoofdmap van de voorbeeldrepository door het uitvoeren van:

touch Procfile

Voeg vervolgens de volgende tekst toe aan het Profile-bestand:

web: npm start

Log in bij Heroku, klik op het gebruikerspictogram in de rechterbovenhoek, klik op Accountinstelling en scroll omlaag om de API-sleutel te vinden.

De API-sleutel vinden in de accountinstellingen van Heroku

Voeg vervolgens een omgevingsvariabele toe aan Bitbucket Pipelines zodat we naar Heroku kunnen implementeren:

  • HEROKU_API_KEY: je kunt je API-sleutel vinden in je Heroku-account

Ga naar Pipelines > Omgevingsvariabelen in je repository-instellingen om deze variabele toe te voegen.

Een schermafbeelding van het instellen van Heroku in Bitbucket | Atlassian CI/CD

Omgevingsvariabelen instellen om naar Heroku te implementeren

In deze gids gebruiken we Heroku, maar het is zeker mogelijk om dit voorbeeld aan te passen aan andere hostingdiensten. Gebruik deze handleiding als referentie voor Heroku.

Continue levering met branches als poort naar productie

Deze configuratie is geschikt voor teams met speciale release-branches die kunnen worden toegewezen aan een implementatie. Deze stelt je ook in staat om wijzigingen in een pull request te bekijken voordat ze in productie worden genomen.

In deze set-up zulllen we 2 verschillende branches gebruiken om implementaties te activeren:

  • main: elke push naar main zal de code implementeren in een staging-omgeving na het uitvoeren van de tests.
  • productie: code die is samengevoegd met de productiebranch wordt automatisch gereleased aan de productieomgeving.

Maak de productiebranch aan in Bitbucket Cloud door op Branches te klikken

Productiebrach in Bitbucket Cloud

Klik vervolgens op Branch aanmaken

'Branch aanmaken' selecteren in het pop-upvenster in Bitbucket Cloud

Typ productie en klik op Aanmaken.

Voer vanuit de hoofdmap van de voorbeeldrepository het volgende uit:

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

Om te zien of dit correct werkt, ga je naar Heroku in een browser en kijk je of er twee apps zijn vermeld.

Apps die worden vermeld in de Heroku-browser

Voer ook het volgende uit:

git remote -vv

De verwachte resultaten zullen drie externe branches hebben. Eén voor Bitbucket en twee voor Heroku. De ene zal een staging-branch zijn en de andere zal een productie-branch zijn.

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)

Configureer vervolgens de implementatie naar staging. Om dat te doen, gebruiken we de branchspecifieke pipelines en maken we een pipeline aan die wordt uitgevoerd voor elke push op de main-branch. Breng deze wijziging aan in je terminal en push naar bron main.

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

Zorg ervoor dat je de Git push-URL voor main vervangt door de staging-URL hierboven van git remote -vv.

We hebben nu een pipeline gemaakt die elke push van main naar Heroku zal implementeren na het bouwen en testen van onze toepassing. De kloon-sectie aan het begin van de configuratie zorgt ervoor dat we een volledige kloon maken (anders zou Heroku de Git-push kunnen weigeren). Push deze configuratie gewoon naar Bitbucket om je eerste geautomatiseerde implementatie naar staging te zien plaatsvinden.

Een schermafbeelding van een succesvolle pipeline-implementatie | Atlassian CI/CD

Een succesvolle pipeline die onze applicatie implementeert naar staging

Zoals je misschien al geraden hebt, hoeven we alleen nog een andere branch-pipeline toe te voegen voor de productiebranch om automatisch de productieomgeving te releasen wanneer wijzigingen worden samengevoegd met de productiebranch. Breng deze wijziging aan in je terminal en push naar bron main.

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

Zorg ervoor dat je de Git push-URL voor main vervangt door de staging-URL van git remote -vv, en de Git push-URL voor productie met de productie-URL van git remote -vv.

We voeren de tests opnieuw uit op de productiebranch om ons ervan te verzekeren dat niets de build heeft beïnvloed voordat de applicatie wordt gereleased.

Onze pipelines zijn nu geconfigureerd en we kunnen de productiebranch beperken om alleen merges te accepteren via pull requests. Ga naar Workflow > Branch-rechten onder je repository-instellingen om de productiebranch te beperken. Dit is een belangrijke stap omdat we willen voorkomen dat er rechtstreeks vanaf lokale machines naar productie gepusht kan worden.

Rechten voor de productiebranch configureren | Atlassian CI/CD

Rechten voor de productiebranch configureren

In de bovenstaande schermafbeelding zie je de rechten:

  • Niemand heeft schrijftoegang
  • Slechts één ontwikkelaar kan de branch mergen

We hebben ook een merge-controle toegevoegd om er zeker van te zijn dat de source-branch ten minste één green build heeft voordat de code wordt samengevoegd. Het stelt ons in staat om build-time te besparen en te voorkomen dat ontwikkelaars slechte code samenvoegen met onze productiebranch.

Wanneer dat is gebeurd, kun je een pull request aanmaken om de code van main met productie samen te voegen en vervolgens de nieuwe wijzigingen in je productieomgeving te releasen.

Een Bitbucket-schermafbeelding van het aanmaken van een pull request | Atlassian CI/CD

Maak een pull request aan om wijzigingen in de productie samen te voegen

Zodra je de pull request samenvoegt, kun je zien dat er een nieuwe pipeline wordt geactiveerd voor de productiebranch.

Een pipeline is met succes geactiveerd door de pull request | Atlassian CI/CD

Wanneer dit voltooid is, zijn je nieuwe wijzigingen met succes geïmplementeerd in de productieomgeving.

"Hello World!"-bericht waarin wordt bevestigd dat de productieomgeving up-to-date is

De productieomgeving is up-to-date!

Je hebt nu een continue leveringsworkflow opgezet met Bitbucket Pipelines en kunt veilig pull requests gebruiken om code te releasen aan je klanten.

Je kunt de uiteindelijke bron van dit voorbeeld vinden in de repository waarnaar hieronder is gelinkt.

Continue levering met handmatige trigger voor release

Deze configuratie is geweldig voor teams die trunk-gebaseerd ontwikkelen.

Met Bitbucket Pipelines is het mogelijk om aangepaste pipelines te configureren die handmatig kunnen worden geactiveerd. Ze kunnen voor verschillende doeleinden worden gebruikt: langlopende tests die je niet bij elke push wilt uitvoeren of specifieke acties die je zelf wilt beheersen. We zullen een aangepaste pipeline gebruiken om een continue leveringsworkflow op te zetten waarbij pushes naar de hoofdbranch automatisch worden geïmplementeerd in een staging-omgeving en commits handmatig kunnen worden geïmplementeerd voor productie.

Nu we onze staging-implementatie hebben ingesteld, kunnen we eenvoudig een aangepaste pipeline toevoegen aan onze bitbucket-pipelines.yml-configuratie die we zullen gebruiken om de trigger handmatig in productie te brengen.

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

Zorg ervoor dat je de Git push-URL voor main vervangt door de staging-URL van git remote -vv, en de Git push-URL voor productie met de productie-URL van git remote -vv.

Nadat je de nieuwe configuratie naar je Bitbucket-repository hebt gepusht, kun je naar de commit gaan en klikken op de link Pipeline uitvoeren onder de commit-informatie om de implementatie naar productie te triggeren.

Pipeline selecteren en uitvoeren vanuit Bitbucket

De actie Pipeline uitvoeren geeft een overzicht van de beschikbare aangepaste pipelines

Druk gewoon op de knop Uitvoeren en je wordt doorgestuurd naar de productie-implementatiepijplijn waar je de logs kunt monitoren.

Pipeline voor productie-implementatie in Bitbucket

In het gedeelte Commit-informatie van de pipeline kun je de naam zien van de aangepaste pipeline die is gebruikt. Je bent nu klaar om je nieuwe Bitbucket Pipelines-configuratie te gebruiken voor continue levering en je kunt je Hello World in productie controleren om er zeker van te zijn dat alles goed is gegaan!

"Hello World!"-testbericht in productie

Onze Hello World-toepassing is geïmplemeteerd voor productie met behulp van een handmatige trigger

Je kunt de uiteindelijke bron van dit voorbeeld vinden in de repository waarnaar hieronder is gelinkt.

Sten Pittet
Sten Pittet

Ik zit nu 10 jaar in de softwarebusiness in verschillende rollen, van ontwikkeling tot productmanagement. Nadat ik de afgelopen 5 jaar in Atlassian heb gewerkt aan ontwikkelaartools, schrijf ik nu over het bouwen van software. Buiten het werk om ontwikkel ik mijn vader-vaardigheden met een geweldige peuter.


Deel dit artikel
Volgend onderwerp

Aanbevolen artikelen

Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.

Toelichting DevOps

DevOps-community

Toelichting DevOps

DevOps-leertraject

Afbeelding van kaart

Gratis aan de slag

Meld je aan voor onze DevOps-nieuwsbrief

Thank you for signing up