Devex capitolo 2: automatizziamo alcuni passaggi dello sviluppo

By Saverio Menin

Abbiamo notato durante lo sviluppo con la Developer platform del Santagostino che sono alcune operazioni, fatte manualmente dallo sviluppatore che possono spesso essere dimenticate generando errori in fase di deploy e quindi perdita di tempo per la gestione del problema ecc…

Questo per lo sviluppatore può essere frustrante e può portarlo a non utilizzare più questi strumenti di controllo qualità.

Ci siamo quindi chiesti come migliorare questa parte del processo di sviluppo e rilascio di una nuova funzionalità.

Abbiamo quindi integrato nei nostri starterkit alcuni flussi automatici:

  • Hook di git per la qualità del codice
  • Workflow di GitHubAction per il versioning del servizio

Hook di Git per la qualità del codice

Al Santagostino lo sviluppatore doveva ricordarsi di lanciare un lint e un jest test per vedere se la sua modifica era ok. Spesso però si dimenticava 😅. Abbiamo quindi introdotto l’hook pre-commit di Git che esegue questi comandi in automatico.

Cosa fa l’hook?

In Git gli hook permettono di compiere azioni personalizzate prima o dopo un determinato comando git. Sfruttando questa possibilità (hook pre-commit) per effettuare lint e unit test prima del commit abbiamo quindi gestito un semplice script bash che eseguiva i nostri 2 comandi per eseguire il lint e gli unit test.

Ecco un’esempio dello script bash creato:

#!/bin/bash

Color_Off='\033[0m'       # Text Reset
Blue='\033[0;34m'         # Blue
BBlue='\033[1;34m'        # Blue bold

echo -e "${BBlue} Start actions pre-commit.. ${Color_Off}"
echo -e "${Blue} Run lint ${Color_Off}"
docker-compose exec -T app bash -c "yarn lint"
echo -e "${Blue} Run unit test ${Color_Off}"
docker-compose exec -T app bash -c "yarn test"
echo -e "${BBlue} End actions pre-commit ${Color_Off}"

Da notare che gli script hook di git devono essere posizionati nella cartella .git/hooks per funzionare. Questo porta una complicazione: la cartella .git non è versionata e quindi ogni sviluppatore doveva gestire la creazione dello script individualmente. Per evitare questa ulteriore azione manuale allo sviluppatore abbiamo:

  • inserito i file di script all’interno del repository per versionarli
  • inserito negli starterkit un nuovo comando make init che si occuperà di copiare gli script per gli hook nell’apposita cartella
  • introdotto nel makeFile il flusso di inizializzazione che si occuperà di gestire la prima configurazione sulla macchina locale.

Il flusso di inizializzazione si occuperà di:

  1. fare la login a dotenv (servizio che usiamo per salvare in un vault sicuro i nostri env)
  2. recuperare l’ultima versione dell’env
  3. fare un git checkout stage
  4. fare un git pull

Workflow di GitHubAction per il versioning del servizio

Nei nostri servizi da qualche tempo abbiamo deciso di gestire anche il numero di versione, così da sapere che versione sta girando in produzione e per permetterci un rapido rollback usando la pipeline di rilascio.

Questo però comportava allo sviluppatore di aggiornare manualmente il numero di versione sul package.json e spesso ci si dimenticava 😅.

Abbiamo quindi introdotto 2 comandi sul makeFile che permettono di:

  • creare un branch con le regole definite nella nostra styleguide
  • incrementare la versione nel packege.json in base alle regole del semVersion

Inoltre abbiamo introdotto un workflow su gitHubAction che, al merge sul branch master, permette di:

  • creare un tag basandosi sulla versione del package.json
  • creare una release (basata sul tag creato) con in descrizione il chengelog

Ecco un’esempio del workflo che utilizziamo

name: Master branch tagging
on:
  push:
    branches:
      - master

jobs:
  qa:
    name: Create tag
    runs-on: ubuntu-latest
    steps:
      - name: Check out repo
        uses: actions/checkout@v3
        with:
          ref: master
      - name: Get version
        id: version
        uses: martinbeentjes/npm-get-version-action@main
      - name: Create and push tag
        id: create-push-tag
        continue-on-error: true
        run: |
          git tag ${{ steps.version.outputs.current-version}}
          git push origin ${{ steps.version.outputs.current-version}}
      - name: Create and push release
        uses: fregante/release-with-changelog@v3
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          exclude: '^Merge'
          commit-template: '- {date} | {title} ← {hash}'
          template: |
            ### Changelog

            {range}

            {commits}

Conclusione

Questi sono alcuin degli automatisi che abbiamo implementato e inserito nei nostri tarterkit per diminuire le azioni “amministrative” che lo sviluppatore deve fare e per permettersi di concentrarsi sul vero valore: la business logic.