Sonarqube

    Sonarqube

    Per un importante Cliente, leader nel proprio settore a livello mondiale, abbiamo ricevuto l’incarico di intervenire su un’applicazione preesistente per ampliarne le funzionalità e intervenire con delle modifiche su alcune di quelle già in essere; il Cliente richiede l’adozione di più processi e “cerimonie” per garantire il raggiungimento e verifica degli obbiettivi e 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 e poter identificare delle metriche, rilevate 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).

    Obbiettivi

    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 alla consueta stesura del piano di test e documentazione a corredo dei rilasci, il Cliente ha richiesto che le nuove funzionalità (1) raggiungessero un livello di qualità alta, mentre gli interventi su quanto già presente (2) 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 utilizzati dal Cliente, eseguiti al momento della consegna e necessarie per poter iniziare la fase di Test.

    Approccio alla soluzione

    Per rispettare i desiderata espressi, abbiamo analizzato le soluzioni possibili e identificato un approccio che ben si sposasse con la modalità di lavoro a Sprint basata su Scrum.

    Sonarqube

    Abbiamo deciso di adottare Sonarqube di SonarSource (https://www.sonarqube.org/) perchè si tratta di una piattaforma software opensource (https://github.com/SonarSource/sonarqube/ ) 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 (https://sonarcloud.io/) per rispettare il requisito mandatorio di segretezza e non condivisione con terzi del codice sorgente oggetto delle modifiche.

    Caratteristiche principali

    È una piattaforma in grado di controllare la qualità del codice sorgente ed 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 (ovvero 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 di Sonarqube è stata molto rapida e ha richiesto poche operazioni e modifiche all’operatività del team.

    Configurazione iniziale di Sonarqube

    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 (https://dev.azure.com/), 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 (https://docs.microsoft.com/en-us/azure/devops/pipelines/) 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)

    Sonarqube negli Standup meeting

    Nelle quotidiane sessioni di condivisone del lavoro del team, abbiamo introdotto la presa visione della dashboard di Sonarqube, dove, oltre allo stato del progetto con evidenza degli indicatori maggiormente coinvolti, monitoriamo il debito tecnologico accumulato (ovvero 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, senza la necessità di un periodo di adattamento. La configurazione iniziale no 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, ma é opportuno sottolineare come sia sempre richiesta l’analisi di ogni segnalazione: non può essere presa per buona a prescindere, specialmente, come in questo caso, dove è coinvolta una più che cospicua porzione di codice sorgente legacy su cui gli interventi devono essere mirati e il piú possibile ridotti.