Articoli
Tutorial
Guide interattive
Scopri la continuous delivery con Bitbucket Pipelines
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 continuous deployment 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.
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.
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 ProcfileQuindi, aggiungi il seguente testo al Procfile:
web: npm startAccedi 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.
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.
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
Quindi clicca su Create branch (Crea branch).
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 mainPer vedere se ha funzionato correttamente, accedi a Heroku in un browser e verifica se ci sono due app in elenco.
Esegui anche:
git remote -vvI 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 mainAssicurati 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.
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:mainAssicurati 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
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.
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.
Al termine, le nuove modifiche saranno state distribuite con successo nell'ambiente di produzione.
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:mainAssicurati 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.
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.
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.
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!
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.
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.
Community DevOps
Percorso di apprendimento DevOps
