Close

Scopri la continuous delivery con Bitbucket Pipelines

Primo piano di Sten Pittet
Sten Pittet

Scrittore collaboratore

In questa guida ti spiegheremo come utilizzare Bitbucket Pipelines per adottare un flusso di lavoro di continuous delivery. Continua a leggere!

Ora

30 minuti

Pubblico

Persone che non hanno familiarità con la continuous integration e/o Bitbucket Pipelines

Il rilascio di una nuova funzione è sempre un momento entusiasmante perché significa che stai per offrire nuove funzionalità ai tuoi clienti. Tuttavia può essere anche un esercizio rischioso che richiede molta preparazione, cosa che rende il tuo team poco propenso a farlo spesso. Inoltre più aspetti, più diventa difficile la distribuzione in produzione: le modifiche si accumulano, è difficile comprenderne l'ambito e diventa complicato identificare le cause alla radice se si verificano problemi nella produzione.

Un modo semplice per eliminare la paura e il costo della distribuzione del software è automatizzare il processo e rilasciare modifiche più piccole con maggiore frequenza. Prima di tutto, risparmierai innumerevoli ore che normalmente vengono impiegate per preparare il rilascio. Inoltre, ridurrai anche il rischio di distribuire software avendo un ambito molto più ristretto per ogni rilascio, semplificando il monitoraggio degli ambienti e la risoluzione dei problemi.

Questa automazione della distribuzione è qualcosa che puoi fare facilmente con Bitbucket Cloud oggi. Per ciascuno dei tuoi repository, puoi configurare una pipeline che compilerà, testerà e distribuirà automaticamente il tuo codice nei tuoi ambienti a ogni push. In questa guida, ti spiegheremo come utilizzare Bitbucket Pipelines per adottare un flusso di lavoro di continuous delivery.

Continuous delivery e continuous deployment a confronto

La continuous delivery è la pratica di assicurarsi che il codice sia sempre pronto per il rilascio anche se non tutte le modifiche vengono distribuite in produzione. Ti consigliamo di aggiornare la produzione tutte le volte che puoi per assicurarti che l'ambito delle modifiche sia ristretto, ma in ultima analisi decidi tu il ritmo dei rilasci.

Nella continuous deployment, le nuove modifiche inviate al repository vengono distribuite automaticamente in produzione se superano i test. Questo pone maggiore enfasi (leggi: pressione) sulla tua cultura dei test, ma è un ottimo modo per accelerare il ciclo di feedback con i tuoi clienti.

Diagramma che mostra la differenza tra continuous deployment e sviluppo continuo | CI/CD di Atlassian

Come adottare una pipeline di continuous delivery

In questo esempio, estenderemo la semplice app Node.js che abbiamo costruito nel tutorial sulla continuous integration aggiungendo una pipeline di continuous delivery che esegue la distribuzione automatica all'ambiente di staging quando la build supera il test. Vedremo due diverse strategie per la distribuzione della produzione: una utilizza branch e pull request e l'altra pipeline personalizzate e trigger manuali.

In entrambi gli esempi, useremo una semplice applicazione Node.js che mostra un messaggio "Hello World" nel tuo browser. Distribuiremo questa applicazione agli ambienti di staging e produzione ospitati su Heroku utilizzando entrambi i metodi.

Un'applicazione Hello World di base | CI/CD di Atlassian

La nostra applicazione Hello World molto semplice

Come preparare la distribuzione a Heroku

Per iniziare, iscriviti a Heroku.

Quindi installa la CLI di Heroku.

Aggiorna package.json per fare in modo che abbia un aspetto simile al seguente:

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

Aggiorna il file server.js per fare in modo che abbia un aspetto simile al seguente:

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;

Nota la modifica a app.listen(). Ora include process.env.PORT che è stato impostato da Heroku.

Aggiungi un Procfile alla directory principale del repository di esempio eseguendo:

touch Procfile

Quindi, aggiungi il seguente testo al Procfile:

web: npm start

Accedi a Heroku, clicca sull'icona dell'utente nell'angolo in alto a destra, clicca su Account Setting (Impostazioni account) e scorri verso il basso per trovare la chiave API.

Individuazione della chiave API nelle impostazioni dell'account di Heroku

Successivamente, aggiungi una variabile di ambiente a Bitbucket Pipelines in modo da poter effettuare una distribuzione su Heroku:

  • HEROKU_API_KEY: puoi trovare la tua chiave API nel tuo account Heroku

Accedi a Pipelines > Variabili di ambiente nelle impostazioni del tuo repository per aggiungere questa variabile.

Screenshot della configurazione di Heroku in Bitbucket | CI/CD di Atlassian

Configurazione di variabili di ambiente da distribuire su Heroku

In questa guida stiamo usando Heroku, ma sicuramente è possibile adattare questo esempio ad altri servizi di hosting. Usa questa guida come riferimento per Heroku.

Continuous delivery con branch come punto di accesso alla produzione

Questa configurazione è adatta per i team con release branch speciali che possono essere mappati a una distribuzione. Consente inoltre di controllare le modifiche in una pull request prima che vengano distribuite in produzione.

In questa configurazione useremo 2 branch diversi come trigger delle distribuzioni:

  • main: qualsiasi push a main distribuirà il codice in un ambiente di staging dopo aver eseguito i test.
  • production: il codice per cui è stato eseguito il merge nel branch di produzione verrà rilasciato automaticamente nell'ambiente di produzione.

Crea il branch di produzione in Bitbucket Cloud cliccando su Branches

Branch di produzione in Bitbucket Cloud

Quindi clicca su Create branch (Crea branch).

Selezione di "Create Branch" (Crea branch) nella finestra pop-up in Bitbucket Cloud

Digita production e clicca su Create (Crea).

Dalla directory principale del repository di esempio esegui:

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

Per vedere se ha funzionato correttamente, accedi a Heroku in un browser e verifica se ci sono due app in elenco.

App elencate nel browser di Heroku

Esegui anche:

git remote -vv

I risultati previsti avranno tre branch remoti. Uno per Bitbucket e due per Heroku. Un branch remoto sarà per lo staging, l'altro per la produzione.

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)

Quindi, configura la distribuzione nell'ambiente di staging. Per fare questo, utilizziamo le pipeline specifiche del branch e creiamo una pipeline che viene eseguita per ogni push sul branch main. Apporta questa modifica nel tuo terminale ed esegui il push sul main di origine.

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

Assicurati di sostituire l'URL di git push per main con l'URL di staging di git remote -vv qui sopra.

Ora abbiamo creato una pipeline che distribuirà ogni push da main su Heroku dopo aver creato e testato la nostra applicazione. La sezione clone all'inizio della configurazione ci assicura di creare un clone completo (altrimenti Heroku potrebbe rifiutare il git push). Non devi fare altro che eseguire il push di questa configurazione su Bitbucket per vedere la tua prima distribuzione automatica all'ambiente di staging.

Screenshot della distribuzione di una pipeline avvenuta correttamente | CI/CD di Atlassian

Una pipeline di successo che distribuisce la nostra applicazione all'ambiente di staging

Come avrai intuito, non dobbiamo fare altro che aggiungere un'altra pipeline del branch per il branch di produzione per eseguire il rilascio automatico all'ambiente di produzione dopo il merge delle modifiche al branch di produzione. Apporta questa modifica nel tuo terminale ed esegui il push sul main di origine.

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

Assicurati di sostituire l'URL di git push per main con l'URL di staging di git remote -vv e l'URL di git push per la produzione con l'URL di production di git remote -vv.

Eseguiamo nuovamente i test sul branch di produzione per assicurarci che nulla abbia influito sulla build prima del rilascio dell'applicazione.

Le nostre pipeline sono ora configurate e possiamo imporre al branch di produzione di accettare solo merge tramite pull request. Basta accedere a Workflow > Branch permissions (Flusso di lavoro > Autorizzazioni del branch) nelle impostazioni del repository per applicare delle restrizioni al branch di produzione. Questo è un passo importante in quanto vogliamo impedire alle persone di eseguire direttamente il push alla produzione dalla loro macchina locale.

Configurazione delle autorizzazioni del branch di produzione | CI/CD di Atlassian

Configurazione delle autorizzazioni del branch di produzione

Nello screenshot qui sopra puoi vedere le autorizzazioni:

  • Nessuno ha accesso in scrittura
  • Solo uno sviluppatore può eseguire il merge al branch

Abbiamo anche aggiunto un controllo del merge per assicurarci che il branch di origine abbia almeno una build operativa prima del merge del codice. Questo ci consentirà di risparmiare tempo con le build e impedirà agli sviluppatori di eseguire il merge di codice errato nel nostro branch di produzione.

Successivamente, puoi creare una pull request per eseguire il merge del codice da main a production , quindi rilasciare le nuove modifiche al tuo ambiente di produzione.

Screenshot di Bitbucket sulla creazione di una pull request | CI/CD di Atlassian

Crea una pull request per eseguire il merge delle modifiche in produzione

Eseguito il merge della pull request, potrai vedere una nuova pipeline che viene attivata per il branch di produzione.

Una pipeline è stata attivata correttamente dalla pull request | CI/CD di Atlassian

Al termine, le nuove modifiche saranno state distribuite con successo nell'ambiente di produzione.

Messaggio di "Hello World!" che conferma che l'ambiente di produzione è aggiornato

L'ambiente di produzione è aggiornato!

Ora hai configurato un flusso di lavoro di continuous delivery con Bitbucket Pipelines e puoi utilizzare in sicurezza le pull request per rilasciare codice ai tuoi clienti.

Puoi trovare la fonte finale di questo esempio nel repository, a cui puoi accedere tramite il link di seguito.

Continuous delivery con trigger manuale per il rilascio

Questa configurazione è ideale per i team che stanno praticando lo sviluppo basato su trunk.

Con Bitbucket Pipelines è possibile configurare pipeline personalizzate che possono essere attivate manualmente. Possono essere utilizzate per diversi scopi: test di lunga durata che non vuoi eseguire a ogni push o azioni specifiche che vuoi controllare per conto tuo. Useremo una pipeline personalizzata per configurare un flusso di lavoro di continuous delivery in cui i push al branch main vengono distribuiti automaticamente in un ambiente di staging e i commit possono essere distribuiti manualmente in produzione.

Ora che abbiamo configurato la nostra distribuzione in staging, possiamo semplicemente aggiungere una pipeline personalizzata alla nostra configurazione bitbucket-pipelines.yml che useremo per attivare manualmente il rilascio in produzione.

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

Assicurati di sostituire l'URL di git push per main con l'URL di staging di git remote -vv e l'URL di Git push per production con l'URL di production di git remote -vv.

Dopo aver eseguito il push della nuova configurazione al tuo repository Bitbucket, puoi accedere al commit e cliccare sul link Esegui pipeline sotto le informazioni del commit per attivare la distribuzione in produzione.

Selezione ed esecuzione di una pipeline da Bitbucket

L'azione Esegui pipeline mostrerà la lista delle pipeline personalizzate disponibili

Non devi fare altro che premere il pulsante Esegui e verrai reindirizzato alla pipeline della distribuzione in produzione dove puoi monitorare i log.

Pipeline della distribuzione in produzione in Bitbucket

Nella sezione della pipeline con le informazioni del commit, puoi vedere il nome della pipeline personalizzata che è stata utilizzata. Ora sei pronto per utilizzare la tua nuova configurazione Bitbucket Pipelines per la continuous delivery e puoi controllare la tua applicazione Hello World in produzione per verificarne il corretto funzionamento!

Messaggio test di "Hello World!" in produzione

L'applicazione Hello World è stata distribuita in produzione utilizzando un trigger manuale

Puoi trovare la fonte finale di questo esempio nel repository, a cui puoi accedere tramite il link di seguito.

Sten Pittet
Sten Pittet

I've been in the software business for 10 years now in various roles from development to product management. After spending the last 5 years in Atlassian working on Developer Tools I now write about building software. Outside of work I'm sharpening my fathering skills with a wonderful toddler.


Condividi l'articolo
Argomento successivo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Illustrazione su Devops

Community DevOps

Illustrazione su Devops

Workshop di simulazione

Illustrazione di una mappa

Inizia gratis

Iscriviti alla nostra newsletter DevOps

Thank you for signing up