Skip to main content

CD CI Tryber Platform

In questa pagina (dopo una panoramica sulla struttura della piattaforma) andremo a descrivere quelli che sono i processi di sviluppo e deploy (o rilascio) della piattaforma Tryber nei vari ambienti (di sviluppo e rilascio).

Ambienti di lavoro​

Gli ambienti di sviluppo di ogni programmatore del Team Tryber sono 2:

  • Ambiente LOCALE (il pc sul quale ogni programmatore lavora)
  • Ambiente di STAGING (https://dv-crowd.app-quality.com/) Gli ambienti di rilascio sono 2
  • Ambiente di PRE-PRODUZIONE (anche detto CLONE internamente al team)
  • Ambiente di (rilascio) PRODUZIONE (https://tryber.me/) "NOTA-1: Gli ambienti di STAGING, PRE-PRODUZIONE e PRODUZIONE sono infrastrutture in cloud hostate dal CloudVendor AWS su un account Aziendale"

"NOTA-2: PRE-PRODUZIONE e PRODUZIONE condividono lo stesso DataBase invece STAGING per motivi di sviluppo e di test ha un suo DataBase a se stante, cio significa che al momento del rilascio su PRE-PRODUZIONE non va in alcun modo alterato il dato a DATABASE esssendo il DB quello di PRODUZIONE"

Piattaforma e Repositories​

Attualmente lo sviluppo della piattaforma Tryber sta attraversando un periodo di migrazione (delle parti che la compongono) da uno stack tecnologico ad un altro. Nello specifico lo stato attuale della piattaforma comprende 3 parti.

  • Una parte che comprende un CMS WordPress nel quale possiamo trovare la maggioranza del core della pittaforma (logica flusso campagne e flusso candidatura dei tryber e interazione tryber-campagne), avente numerosi plugins custom, sviluppati ad hoc per varie features (alcuni dei plugins sviluppati sono racchiusi in submoduli del repo principale). "Questa parte della piattaforma è containerizzata in un'immagine docker."
  • Pagine React con Typescript costruite utilizzando un DesignSystem custom che è composto da componenti React (per la parte grafica)
  • Le pagine React si interfacciano al DataBase di WordPress tramite delle API in Javascript , sempre con Typescript e Test con Jest (per quanto riguarda i dati)
  • Il CMS WordPress è conteinerizzato in un Docker

In base alla situazione sopra descritta tutto il codice della piattaforma su basa su 5 fra i tanti repositories presenti sull'account aziendale di GitHub:

Deployment di un BRANCH sull'ambiente di STAGING​

Nell'ottica di miglioramento della nostra CD/CI, "da github" sono state configurate delle action (per alcuni repositories) che triggherano delle pipeline su AWS che ci permettono di "deploiare" sull'Ambiente di STAGING un determinato BRANCH di un determinato repository.

Questo è molto importante perché in fase di sviluppo ci permette di testare e far testare una feature che è in corso di sviluppo su un ambiente (STAGING) che non sia il nostro LOCALE simulando così dinamiche più complesse e complete rispetto al LOCALE.

STAGING infatti mira ad "emulare" gli ambienti di PRE-PRODUZIONE e PRODUZIONE essendo un ambiente su AWS così come lo sono gli ambienti di rilascio e interfacciandosi con gli altri repositories della piattaforma cosa che magari non sempre succede in LOCALE.

  • Prerequisiti:
    • Assicurarsi di aver pushato tutti i commit sul branch che si desidera testare sull'albiente di STAGING
    • Avere un account githhub che sia almeno membro o contributor sul repository
  • Deploy:
    • Una volta che il branch è pronto andare sulla pagina github del repository e cliccare sulla sezione Actions scegliendo la Action "Deploy to staging".
    • Nel menu a tendina (a destra) "Run workflow" ricercare e scegliere il branch da "deploiare" e avviare il deploy cliccando su "Run workflow". Nella lista dello storico delle actions presente in pagina comparirà il nuovo workflow di deploy e una volta completato diverrà verde. A quel punto nell'ambiente di staging sarà online il branch desiderato e sarà possibile testarne le modifiche.
    • NOTA: se lo si desidera cliccando sul workflow in progress è possibile monitorare gli step e lo stato di avanzamento del workflow di deploy.

Flusso di Rilsascio (di crowd_wp, tryber-api e appq-register-page)​

Essendo l'infrastruttura di PRODUCTION su AWS, per rilasciare tramite github è necessario avere anche dei permessi come utente AWS in quanto per ragioni di sicurezza vi è uno step da eseguire sul portale AWS. Vediamo i prerequisiti e gli step da seguire.

P.S. La procedura è la stessa sia per tutti è tre i repositories, ma c'è una piccola differenza per crowd_wp che descriviamo più in basso.

  • Prerequisiti:
    • Avere un account githhub che sia almeno membro o contributor sul repository.
    • Avere un account su AWS collegato all'organizazione che sia autorizzato tramite IAM come membro del gruppo "releaser"
    • Assicurarsi di aver pushato tutti i commit su tutti i branch.
    • Assicurarsi di aver mergiato tutte le pull-requests a develop e che non ci siano features da rilasciare che non siano state mergiate a develop
    • Successivamente fare una pull-request da develop su main (o master a seconda dell'età del repository). Se al merge la action non ha sollevato criticità, procedere al flusso di rilascio.
  • Release: (ogni repository necessita del suo rilascio)
    • Una volta che il branch main/master è pronto per iniziare il rilascio bisogna andare nella pagina github del repository e cliccare sul title Releases (sulla destra).
    • Da qui cliccando su Draft a new release si può settare la action di rilascio del repository, per farlo bisogna:
      • inserire un tag cliccando Choose a tag e scrivendo il nome del tag che DEVE OBBLIGATORIAMENTE iniziare con "release-" es. release-2022-12-30 e cliccare su Create new tag
      • Inserito il tag bisogna scegliere il Target ovvero il branch da rilasciare main o master
      • Inserire un qualsivoglia titolo della release
      • Inserire una Descrizione, se i passi precendenti sono stati eseguiti correttamente è possibile popolare la descrizione con i nomi delle pull-request mergiate cliccando sul pulsante "+ Auto-generate release notes"
      • Infine cliccare su Publish release per iniziare il flusso di rilascio.
    • Andando nella sezione Actions del repository è possibile monitorare lo stato di avanzamento della release clicando sulla action in corso. NOTA: per quanto riguarda il rilascio di crowd_wp, la release si fa partire come sempre dal repo crowd_wp -> Releases -> Draft a new realese ma il monitoraggio sarà nella sezione Actions di un altro repo, il repo crowd_wp_platform -> Actions -> release in corso
    • Monitorando gli stati di avanzamento del flusso di rilascio si può notare che una volta che i branch sono stati pullati dalle macchine di PRE-PRODUZIONE e di PRODUZIONE prima di completare la release viene richiesto uno step manuale, nel dettaglio
    • #Inizia il rilascio sugli ambienti di PRE-PRODUZIONE (clone) e PRODUZIONE
    • #In parallelo si interrompe il rilascio in PRODUZIONE restando in attesa di una conferma manuale e viene completato il rilascio in PRE-PRODUZIONE (clone)
    • #QA e Sviluppatori testano sul clone nel nuove feature e controllano che non ci siano dei bug e nemmeno regression, Se è tutto Ok sul clone:
    • #Si conferma manualmente da PipelineAWS il preseguo del rilascio e il branch main/master viene rilasciato in PRODUZIONE
    • Su AWS viene eseguita una Pipeline di rilascio. Andando QUI è possibile vedere tutte le pipelines e filtrare per repo e ambiente (api-production, crowd-production, react-production ) si può aprire la pipeline e accedere allo step della conferma manuale.

NOTA-TECNICA: al fine di mantenere sempre attivo il servizio tramite le configurazioni della pipeline di rilascio su AWS si è scelto (tramite auto-scaling-groups) di aumentare il numero delle macchine online così da deviare le richieste durante il rilascio per poi spegnere le macchine in più al termine del rilascio.

  • INTERRUZIONE-RELESE: nel caso in cui per motivi di hotfixing o altro venga interrotta una pipeline di rilascio da aws è necessario: