Smart Tips
Apr 27

Sonarqube

Per un importante Cliente, leader nel proprio settore a livello mondiale, dovevamo intervenire su un’applicazione per ampliarne le funzionalità e modificarne alcune. Il Cliente richiede l’adozione di più processi e “cerimonie” per garantire il raggiungimento e la verifica degli obbiettivi. Inoltre presta particolare attenzione alla qualità e robustezza del codice sorgente che viene consegnato.
In particolare, questi ultimi aspetti gli consentono di avere un giudizio qualitativo super partes con cui misurare il lavoro svolto dai fornitori. Inoltre, può identificare delle metriche, tramite l’ausilio di software di analisi dedicati, che forniscano la ragionevole sicurezza che l’applicazione sia priva di falle di sicurezza e che adotti le best practices e convenzioni descritte in letteratura.
L’applicazione in perimetro è basata su un’architettura client-server ed è composta da più di 150000 righe di codice (150k LoC).

Obiettivi

Come accennato, le attività pianificate ricadono nelle seguenti categorie:

  1. Nuove funzionalità, che sfruttano quanto già realizzato ma hanno una responsabilità propria
  2. Interventi migliorativi su funzionalità esistenti, dovendo modificare il codice fornito

Oltre al solito piano di test e alla documentazione a corredo dei rilasci, il Cliente ha richiesto un livello di qualità alta delle nuove funzionalità. Mentre gli interventi su quanto già presente non abbassassero il livello medio-alto precedentemente rilevato.
Per livello di qualità si intende un insieme di indicatori (KPI) rilevati attraverso gli strumenti di analisi del Cliente, eseguiti al momento della consegna e necessari per poter iniziare la fase di Test.

Approccio alla soluzione

Abbiamo analizzato le soluzioni possibili e identificato un approccio che ben si sposasse con la modalità di lavoro a Sprint basata su Scrum.

Abbiamo deciso di adottare Sonarqube di SonarSource. Si tratta di una piattaforma software opensource ampiamente conosciuta nella comunità degli sviluppatori, solida e organizzata a plugin con cui arricchirne le capacità di analisi. Ne abbiamo avuto bisogno data la natura dell’applicazione, basata su un client Web, server scritto in C# e database con funzioni PL/SQL.
L’installazione è molto rapida e può basarsi su container docker, ospitati anche su servizi cloud quali, a titolo di esempio, Azure di Microsoft.
Abbiamo escluso di adottare la soluzione SonarCloud di SonarSource per rispettare la segretezza con terzi del codice sorgente oggetto delle modifiche.

Caratteristiche principali

È una piattaforma capace di controllare la qualità del codice sorgente, eseguire analisi per rilevare bug, codice sospetto e vulnerabilità della sicurezza in oltre venti linguaggi di programmazione. Tutte le analisi utilizzate da Sonarqube si definiscono statiche, ovvero non richiedono l’esecuzione del programma.
La sua adozione, durante il ciclo di sviluppo del software, permette di:

  • Migliorare i processi di sviluppo e test dei componenti
  • Identificare potenziali problemi di qualità in fase di sviluppo, prima che il software entri in produzione
  • Rilevare aree nel codice che richiedono refactoring o semplificazione
  • Individuare errori di programmazione o difetti
  • Aumentare la comunicazione del team di sviluppo e incoraggiare gli sviluppatori a produrre codice di alta qualità


Inoltre, ben si integra con la pratica di Continous Integration (la creazione di una baseline di codice sorgente contenente tutto il lavoro svolto dal team, più volte al giorno), permettendo di arricchirla con le informazioni sulla qualità di quanto è stato realizzato.

Operatività

L’adozione è stata molto rapida e ha richiesto poche operazioni e modifiche all’operatività del team.

Configurazione iniziale

In fase iniziale abbiamo definito un quality gate con degli indicatori (presenza di unit test, quantità di codice duplicato, manutenibilità, affidabilità e sicurezza del codice sorgente) da raggiungere; nel caso anche uno solo di questi indicatori non fosse soddisfatto, Sonarqube è configurato per segnalare tramite notifica il non rispetto dei requisiti di qualità.

Abbiamo quindi creato una baseline raccogliendo le misure del codice sorgente fornite cosí come ci è stato consegnato: queste sono utilizzate come riferimento iniziale, tutti gli interventi successivi devono solo che migliorare gli indicatori di qualità.

Azure DevOps per la Continous integration

Successivamente abbiamo definito nel nostro ambiente di Continous Integration, basato su Azure DevOps, una Azure Pipeline per automatizzare il processo di analisi di Sonarqube alla modifica del codice sorgente da parte del team.
Azure DevOps è una piattaforma di Microsoft che fornisce servizi per permettere ad un team di pianificare il lavoro, collaborare allo sviluppo del codice e creare e distribuire applicazioni; le Azure pipeline sono servizi composti da task impiegabili su qualasiasi tipo di progetto, scritto in qualsiasi linguaggio di programmazione, che possono occuparsi, tra l’altro,  di eseguire la compilazione del codice sorgente ed eseguire i test automatici.
Possono essere eseguite manualmente, tramite una schedulazione temporale o in seguito ad un evento esterno(es: commit, webhook) e inoltre eseguire numerose altre operazioni come le integrazioni verso servizi esterni, anche tramite plugin, quali ad esempio Sonarqube:

Una volta che la pipeline supera la fase di compilazione, invia al server Sonarqube le meta-informazioni relative alla compilazione per poter eseguire l’analisi del codice sorgente e identificare le criticità introdotte rispetto alla baseline iniziale.

Le segnalazioni create da Sonarqube sono raccolte nella sua piattaforma e sono consultabili da ogni membro del team; queste sono inoltre automaticamente assegnate allo sviluppatore che ha introdotto la possibile criticità (sfruttando le informazioni delle commit prese dal sistema di versionamento del codice sorgente) e notificate tramite mail per avvisarlo della necessità di presa visione e risoluzione.
L’adozione, anche in questo progetto, della Continous integration si è nuovamente dimostrata una pratica vincente, permettendoci di:

  • Confermare, anche più volte al giorno, la robustezza dell’applicazione tramite l’esecuzione di tutti i test in un ambiente esterno a quello degli sviluppatori
  • Avere sempre a disposizione l’ultima versione dell’applicazione pronta, esente da errori di compilazione e con tutti i test superati, alla consegna nell’ambiente di Test del Cliente (aprendo alla possibilità della Continous delivery)

Gli Standup meeting

Nelle quotidiane sessioni di condivisone del lavoro del team, abbiamo introdotto la presa visione della dashboard di Sonarqube. Oltre allo stato del progetto con evidenza degli indicatori maggiormente coinvolti, riuciamo a monitorare il debito tecnologico accumulato. Per debito tecnologico si intende il tempo empirico richiesto per risolvere le segnalazioni di Sonarqube. Normalmente questo non richiede l’introduzione di un task specifico per la risoluzione delle segnalazioni. Sfruttando  il principio della Continous Integration riusciamo ad averne evidenza prima che le attività dello Sprint in corso superino la fase di test interno.

Esito

L’adozione di strumenti specialistici e ricchi di configurazioni ci ha permesso di arricchire la nostra modalità di lavoro in modo rapido e senza periodi di adattamento. La configurazione iniziale non ha mai dovuto subire modifiche durante lo svolgimento delle attività. Il team ha presto compreso come navigare all’interno della dashboard di Sonarqube e restringere i punti da analizzare o ordinarli per differenti priorità.

Benefici

  • Standard unico e condiviso da tutto il team tramite regole centralizzate
  • Individuazione di bug preventiva (es: porzioni di codice mai raggiunto, condizioni di test sempre vere, possibili nullpointer, complessità ciclomatica) ancora prima di aver scritto gli UnitTest
  • Individuazione di potenziali problemi di sicurezza (es: security promotion, magic strings) anche attingendo da database pubblici di vulnerabilità (CWE, Sans, OWASP)
  • Buona documentazione che accompagna ogni segnalazione con esempi di codice: parla la stessa lingua degli sviluppatori 
  • Abbattimento del tempo di codereview. I componenti più esperti del team sono interpellati solo su tematiche realmente complesse e non su bestpractices conosciute e già documentate
  • Dashboard chiara con misura dei KPI e loro andamento durante il progetto

Svantaggi

Non abbiamo riscontrato alcun svantaggio. Tuttavia bisogna sottolineare che è sempre richiesta l’analisi di ogni segnalazione. Infatti, non può essere presa per buona a prescindere, specialmente dove è coinvolta una grande porzione di codice sorgente legacy, su cui gli interventi devono essere mirati e il più possibile ridotti.


Mauro Inzerillo
Direttore Tecnico di Euris IT


Scrivici per saperne di più


    Acconsento al trattamento dei dati personali secondo quanto previsto nella Privacy Policy conforme al Regolamento (UE) n. 2016/679.