Distribuzione di App Heroku in Ambienti di Staging e Produzione con GitLab CI/CD

In un articolo precedente, abbiamo esplorato come automatizzare i deployment su Heroku utilizzando GitLab CI/CD. Quella configurazione deployava l’app nel suo ambiente di produzione ogni volta che poussavamo del codice nel ramo main.

In questo articolo, esamineremo un approccio leggermente più complesso: Cosa succede se abbiamo più ambienti? La maggior parte delle organizzazioni di ingegneria utilizza almeno tre ambienti: un ambiente di sviluppo locale, un ambiente di staging e un ambiente di produzione.

Inoltre, alcune squadre di ingegneria seguono una strategia di branching Gitflow, dove hanno un ramo dev e un ramo main. Questa strategia è caduta in disuso ed è stata sostituita da trunk-based development, ma non è raro trovare organizzazioni che ancora seguiscono questa pratica.

Oggi esamineremo come configurare GitLab CI/CD per distribuire la nostra app sull’ambiente di test quando effettuiamo un push sul分支 dev e distribuire la nostra app sull’ambiente di produzione quando effettuiamo un push sul branch main.

Introduzione

Prima di iniziare, avremo bisogno di due cose: un account Heroku e un account GitLab.

Heroku è un ottimo posto per ospitare e distribuire le nostre app. Come piattaforma come servizio (PaaS), Heroku ci permette di concentrarci sulla creazione di cose interessantiwhile abstracting away gran parte della complessità dell’infrastruttura. Puoi creare un account Heroku qui.

GitLab è un ottimo posto per conservare il nostro codice. Oltre a essere uno strumento di gestione del codice sorgente, GitLab offre anche funzionalità native di CI/CD quindi puoi configurare pipeline per testare e distribuire il tuo codice senza richiedere un altro strumento di terze parti. Puoi creare un account GitLab qui.

L’app di esempio mostrata in questo articolo utilizza sia GitLab che Heroku. Puoi trovare tutto il codice nel repository GitLab qui.

Eseguire la Nostra App Localmente

Puoi eseguire l’app localmente clonando il repository, installando le dipendenze e eseguendo il comando di avvio. Nel tuo terminale, esegui quanto segue:

$ git clone https://gitlab.com/tylerhawkins1/heroku-gitflow-staging-production-gitlab-cicd-demo.git
$ cd heroku-gitflow-staging-production-gitlab-cicd-demo
$ npm install
$ npm start

Dopo aver avviato l’app, visita questo host locale nel tuo browser, e vedrai l’app eseguita localmente:

Applicazione Demo su Heroku

Distribuzione della Nostra App su Heroku

Ora che l’app è in esecuzione localmente, distribuisci su Heroku così puoi accedervi da anywhere, non solo sul tuo computer.

Ricorda che distribuiremo la tua app sia in un ambiente di preproduzione che in un ambiente di produzione. Questo significa che avremo due app Heroku basate sullo stesso repository GitLab.

Se non hai già installato il Heroku CLI sul tuo computer, dovrai installarlo prima di procedere.

Dopo aver installato il Heroku CLI, esegui i seguenti comandi dal tuo terminale per controllare il ramo main, creare una nuova app di produzione su Heroku, distribuirlo nel tuo ambiente di produzione e aprirlo nel tuo browser:

$ git checkout main
$ heroku create heroku-gitlab-ci-cd-production --remote heroku-production
$ git push heroku-production main
$ heroku open --remote heroku-production

Con questo, dovresti vedere la stessa app, ma questa volta in esecuzione su un URL Heroku invece che su localhost. Ottimo lavoro — hai distribuito la tua app Heroku in produzione!

Ma non siamo ancora finiti. Dobbiamo anche configurare e distribuire la tua app di preproduzione. Per fare questo, esegui la seguente serie di comandi simili mostrati di seguito:

$ git checkout dev
$ heroku create heroku-gitlab-ci-cd-staging --remote heroku-staging
$ git push heroku-staging main
$ heroku open --remote heroku-staging

Ora avrai nuovamente la stessa app distribuita, ma questa volta a un diverso URL che servirà come tuo ambiente di staging. Ora abbiamo configurato entrambi i tuoi ambienti!

Nota le differenze e le similitudini tra i comandi per l’app di produzione e l’app di staging:

1. L’app di produzione utilizza il ramo main, mentre l’app di staging utilizza il ramo dev.
2. L’app di produzione si chiama heroku-gitlab-ci-cd-production, e l’app di staging si chiama heroku-gitlab-ci-cd-staging.
3. Il remote git dell’app di produzione si chiama heroku-production, e il remote git dell’app di staging si chiama heroku-staging.
4. Entrambi i remote git dell’app di produzione e dell’app di staging utilizzano un ramo main, poiché Heroku distribuisce l’app solo quando il codice viene spinto al suo ramo principale.

Tieni presente che questo ramo main è diverso dal tuo set di rami main e dev. Il ramo main a cui stai spingendo qui è il ramo main sul tuo remote git — in questo caso, Heroku.

Quando sei sulla tua branch locale main e esegui git push heroku-production main, stai spingendo la tua branch main sulla branch main dell’applicazione Heroku di produzione. E quando sei sulla tua branch locale dev e esegui git push heroku-staging main, stai spingendo la tua branch dev sulla branch main dell’applicazione Heroku di staging.

Effettuare Modifiche alla Nostra App

Ora che abbiamo la nostra app Heroku funzionante, cosa succede se vogliamo fare alcune modifiche? Seguendo una grossolana approssimazione della strategia di branching Gitflow, potremmo fare quanto segue:

1. Checkout della branch dev
2. Effettuare modifiche al codice
3. Aggiungere, committare e spingere quelle modifiche sulla branch dev
4. Deployare quelle modifiche sull’app Heroku di staging eseguendo git push heroku-staging main
5. Checkout della branch main
6. Unire la branch dev nella branch main
7. Deployare quelle modifiche sull’app Heroku di produzione eseguendo git push heroku-production main

(Se stessimo davvero seguendo Gitflow, avremmo creato una branch feature da unire in dev, e una branch release da unire in main, ma abbiamo omesso questi passaggi per mantenere le cose semplici.)

Non sarebbe bello se potessimo automatizzare il deployment in uno dei nostri ambienti invece di doverli sempre deployare manualmente?

Qui entra in gioco GitLab CI/CD.

Integrazione Continua/Distribuzione Continua

L’integrazione continua (CI) riguarda il commit frequente e il mantenimento del build in uno stato buono in ogni momento. Tipicamente, si verifica che il build sia in uno stato buono eseguendo controlli in una pipeline CI. Questi controlli possono includere linter, test unitari e/o test end-to-end.

La distribuzione continua (CD) riguarda la distribuzione frequente. Se i controlli nella pipeline CI passano, allora il build viene distribuito. Se i controlli nella pipeline CI falliscono, allora il build non viene distribuito.

Con GitLab CI/CD, possiamo configurare la nostra pipeline CI per fare esattamente questo — eseguire i nostri test e poi distribuire la nostra app su Heroku se i test passano tutti. Più importante per la nostra configurazione, possiamo specificare regole all’interno della nostra pipeline CI per indicare dove l’app dovrebbe essere distribuita.

Configurazione GitLab CI/CD

Possiamo creare una pipeline CI in GitLab in modo programmatico utilizzando un file .gitlab-ci.yml. Il nostro file ha questo aspetto:

image: node:20.10.0

cache:
  paths:
    - node_modules/

before_script:
  - node -v
  - npm install

stages:
  - test
  - deploy

unit-test-job:
  stage: test
  script:
    - npm test

deploy-job:
  stage: deploy
  variables:
    HEROKU_APP_NAME: $HEROKU_APP_NAME_PRODUCTION
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        HEROKU_APP_NAME: $HEROKU_APP_NAME_PRODUCTION
    - if: $CI_COMMIT_REF_NAME =~ /dev/
      variables:
        HEROKU_APP_NAME: $HEROKU_APP_NAME_STAGING
  script:
    - apt-get update -yq
    - apt-get install -y ruby-dev
    - gem install dpl
    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY

Le pipeline CI di GitLab consistono in fasi e作业. Ogni fase può contenere uno o più作业. Nella nostra pipeline, abbiamo due fasi: test e deploy. Nella fase test, eseguiamo i nostri test unitari nel unit-test-job. Nella fase deploy, distribuiamo la nostra app su Heroku nel deploy-job.

Possiamo procedere solo alla fase successiva se tutti i作业 nella fase precedente passano. Questo significa che se i test unitari falliscono, l’app non sarà distribuita, il che è una buona cosa! Non vorremmo distribuire la nostra app se fosse in uno stato peggiore.

Noterai che la fase deploy ha una sezione rules con alcune logiche condizionali in atto. Qui specificiamo a quale ambiente dovrebbe essere distribuita la nostra app. Se siamo sul ramo main, distribuiamo la nostra app di produzione. Se siamo sul ramo dev, distribuiamo la nostra app di staging.

Noterai anche che la fase deploy fa riferimento a diverse variabili chiamate $HEROKU_APP_NAME_PRODUCTION, $HEROKU_APP_NAME_STAGING e $HEROKU_API_KEY. Queste sono memorizzate come variabili CI/CD all’interno di GitLab.

Se stai configurando questo nel tuo account GitLab personale, dovrai prima trovare la tua chiave API nel tuo account Heroku. Dentro le impostazioni del tuo account Heroku, dovresti vedere una sezione per la tua chiave API. Se non hai ancora generato una chiave API, fallo ora.

Heroku API key

Successivamente, nel tuo progetto GitLab, clicca su Impostazioni > CI/CD > Variabili. Espandi quella sezione e aggiungi tre nuove variabili:

1. Il valore per $HEROKU_API_KEY sarà la chiave API del tuo account Heroku.
2. Il valore per $HEROKU_APP_NAME_PRODUCTION sarà il nome della tua app di produzione su Heroku. Il nome della mia app di produzione è heroku-gitlab-ci-cd-production, ma poiché i nomi delle app Heroku sono unici a livello universale, il tuo sarà diverso.
3. Il valore per $HEROKU_APP_NAME_STAGING sarà il nome della tua applicazione Heroku di staging. Il nome della mia applicazione di staging è heroku-gitlab-ci-cd-staging. Ancora una volta, poiché i nomi delle applicazioni Heroku sono unici a livello universale, il tuo sarà diverso.

GitLab CI/CD variables

Con questo, il tuo pipeline GitLab CI è pronto per essere utilizzato! Proviamo a testarlo.

Distribuzione della Nostra Applicazione Heroku sull’Ambiente di Staging

Verifichiamo il ramo dev e apportiamo una modifica al codice della nostra applicazione. Ho fatto una semplice modifica al testo dell’intestazione e ho aggiunto diverse nuove linee al testo nell’interfaccia utente. Puoi fare una modifica simile nel tuo codice.

Adesso, aggiungi, committa e spingi questa modifica al ramo dev. Questo avvierà il pipeline GitLab CI. Puoi visualizzare il pipeline all’interno di GitLab e vedere i progressi in tempo reale.

GitLab CI pipeline build for the dev branch

Se tutto va bene, dovresti vedere che sia la fase test che quella deploy sono state completate con successo. Ora, vai a controllare la tua applicazione Heroku ospitata all’URL dell’ambiente di staging. Il pipeline GitLab CI ha gestito la distribuzione dell’applicazione per te, quindi ora vedrai le tue modifiche live nell’ambiente di staging!

Demo Heroku app with updated copy

Con un ambiente di staging configurato, ora hai un ottimo posto per testare manualmente il tuo codice in un ambiente ospitato. Questo è anche un punto perfetto per far verificare le modifiche ai tester QA o ai manager del prodotto prima che queste vengano distribuite in produzione.

Adesso, controlla l’URL della tua applicazione di produzione. Noterai che sta ancora mostrando l’interfaccia utente vecchia senza le modifiche più recenti. Questo perché il pipeline GitLab CI ha distribuito le modifiche solo all’ambiente di staging, non a quello di produzione.

Abbiamo verificato che il codice sembra buono nel nostro ambiente di staging, quindi procediamo a promuoverlo nel nostro ambiente di produzione.

Deploying Our Heroku App to the Production Environment

Lasciamo_controllare il ramo main e poi uniamo il ramo dev al tuo ramo main. Puoi farlo tramite una pull request o eseguendo git merge dev e poi git push.

Questo avvierà nuovamente il pipeline di GitLab CI, ma questa volta sarà pronto per distribuire la tua app di produzione.

GitLab CI pipeline build for the main branch

Puoi anche visualizzare tutte le esecuzioni del pipeline nella pagina Pipelines di GitLab per vedere le diverse build per i tuoi rami dev e main:

All GitLab CI pipeline builds

Una volta che il pipeline termina, visita l’URL della tua app Heroku di produzione. Dovresti ora vedere le tue modifiche anche distribuite in produzione. Ottimo lavoro!

Conclusione

A good CI pipeline allows you to ship new features quickly and confidently without manually managing the deployment process. Having multiple environments configured for local development, staging, and production gives you more control over where and when code is released.

Heroku e GitLab CI/CD ti permettono di automatizzare tutto questo per rendere i tuoi processi DevOps un gioco da ragazzi!