Vorremmo condividere la nostra esperienza nell'implementazione della piattaforma SonarQube per l'analisi continua e la misurazione della qualità del codice nei processi esistenti di sviluppo del sistema DPO (aggiunta al sistema di contabilità di deposito e compensazione "Alameda") del National Settlement Depository.
Il Deposito Nazionale di Regolamento (Moscow Exchange Group of Companies) è una delle principali società di infrastrutture finanziarie, che custodisce e contabilizza titoli di emittenti russi e stranieri per un valore di oltre 50 trilioni di rubli. Il crescente volume di transazioni effettuate dal sistema, nonché la continua espansione delle funzionalità, richiedono il mantenimento di un'elevata qualità del codice sorgente dei sistemi. Uno degli strumenti per raggiungere questo obiettivo è l'analizzatore statico SonarQube. In questo articolo, descriveremo l'esperienza di successo dell'implementazione senza soluzione di continuità dell'analizzatore statico SonarQube nei processi di sviluppo esistenti del nostro dipartimento.
Brevemente sul dipartimento
Le nostre competenze includono i seguenti moduli: pagamenti ai clienti NSD, gestione elettronica dei documenti (EDM), elaborazione dei messaggi del repository commerciale (registrazione delle transazioni over-the-counter), canali di interazione elettronica tra clienti e NSD e molto altro. In generale, un ampio livello di lavoro riguarda l'aspetto tecnico delle attività operative. Lavoriamo sulla base di applicazioni. Le applicazioni degli operatori vengono elaborate dagli analisti: raccolgono i requisiti del cliente e ci presentano la loro visione di come questi dovrebbero integrarsi nel programma. Quindi, lo schema standard: sviluppo del codice, test, funzionamento di prova, consegna del codice al circuito di produzione direttamente al cliente.
Perché SonarQube?
Questa è la prima esperienza del nostro dipartimento nell'implementazione di una piattaforma di controllo della qualità del codice: in precedenza lo facevamo manualmente, limitandoci a revisionare il codice. Tuttavia, il crescente volume di lavoro richiede l'automazione di questo processo. Inoltre, il team include dipendenti inesperti che non hanno una conoscenza approfondita delle normative di sviluppo interne e sono inclini a commettere più errori. Si è deciso di implementare un analizzatore statico per controllare la qualità del codice. Poiché SonarQube era già utilizzato in alcuni sistemi NSD, non c'era molta scelta. In precedenza, colleghi di altri dipartimenti lo utilizzavano per analizzare il codice dei microservizi nel sistema Alameda (il sistema di deposito e compensazione contabile di NSD), in CFT (un sistema informativo per la contabilità, il bilancio, la preparazione di report obbligatori e interni) e in alcuni altri sistemi. Per gli esperimenti, abbiamo deciso di iniziare con la versione gratuita di SonarQube. Passiamo quindi al nostro caso.
Processo di implementazione
Abbiamo:
- assemblaggio automatico del sistema in TeamCity;
- è stato configurato il processo di caricamento del codice tramite MergeRequest dal branch delle funzionalità al branch master in GitLab (il processo di sviluppo è conforme a GitHub Flow);
- SonarQube configurato per analizzare il codice per il sistema DPO secondo una pianificazione.
Il nostro obbiettivo: implementare l'analisi automatica del codice nei processi CI/CD DPO.
Bisogno di impostare: il processo di controllo automatico del codice da parte di un analizzatore statico a ogni MergeRequest al ramo principale.
In altre parole, l'obiettivo è il seguente: non appena lo sviluppatore carica le modifiche nel feature branch, viene avviato un controllo automatico per individuare nuovi errori nel codice. Se non ci sono errori, le modifiche possono essere accettate, altrimenti gli errori dovranno essere corretti. Già nella fase iniziale, siamo stati in grado di identificare un certo numero di errori nel codice. Il sistema ha impostazioni molto flessibili: può essere configurato in modo da adattarsi alle specifiche attività degli sviluppatori, per ogni sistema e stile di programmazione.
Impostazione di QualityGate in SonarQube
L'analisi QualityGate è qualcosa di cui abbiamo letto nei meandri di Internet. Inizialmente, abbiamo utilizzato un approccio diverso, più complesso e per certi versi non del tutto corretto. Inizialmente, abbiamo eseguito la scansione due volte tramite SonarQube: abbiamo analizzato il ramo delle feature e il ramo in cui avremmo unito il ramo delle feature, e poi abbiamo confrontato il numero di errori. Questo metodo non era molto stabile e non sempre forniva il risultato corretto. Poi abbiamo scoperto che invece di eseguire SonarQube due volte, è possibile impostare un limite al numero di errori (QualityGate) e analizzare solo il ramo che si sta unendo e confrontando.
Per ora, utilizziamo ancora un controllo del codice piuttosto primitivo. Vale la pena notare che SonarQube è incompatibile con alcuni linguaggi di programmazione, tra cui Delphi. Al momento, analizziamo solo codice PLSql per il nostro sistema.
Funziona così:
- Per il nostro progetto analizziamo solo codice PL/SQL.
- In SonarQube, QualityGate è configurato in modo tale che il numero di errori non aumenti con un commit.
- Il numero di errori durante la prima esecuzione è stato 229. Se durante il commit si verificano più errori, l'unione non è consentita.
- Quindi, una volta corretti gli errori, sarà possibile riconfigurare QualityGate.
- È anche possibile aggiungere nuovi elementi per l'analisi, come la copertura del codice tramite test, ecc.
Schema di lavoro:
I commenti di lavoro dello script mostrano che il numero di errori nel ramo delle funzionalità non è aumentato. Quindi è tutto a posto.
Diventa disponibile il pulsante Unisci.
I commenti di lavoro dello script mostrano che il numero di errori nel feature branch è diventato più che accettabile. Ciò significa che tutto è MALE.
Il pulsante "Unisci" è rosso. Attualmente non esiste alcun divieto di unire modifiche al codice errato, ma questa opzione è a discrezione dello sviluppatore responsabile. In futuro, sarà possibile impedire l'esecuzione di tali commit sul branch principale.
Lavoro indipendente sugli errori
Successivamente, è necessario verificare tutti gli errori rilevati dal sistema, poiché SonarQube esegue l'analisi secondo i suoi rigorosi standard. Ciò che considera un errore potrebbe non esserlo effettivamente nel nostro codice. Pertanto, è necessario verificare e annotare se si tratta effettivamente di un errore o di qualcosa che non necessita di correzione nelle nostre condizioni. In questo modo, riduciamo il numero di errori. Col tempo, il sistema imparerà a comprendere queste sfumature.
A cosa siamo arrivati?
Il nostro obiettivo era capire se nel nostro caso avesse senso trasferire il controllo del codice all'automazione. E il risultato ha soddisfatto le nostre aspettative. SonarQube ci permette di lavorare con i linguaggi di cui abbiamo bisogno, esegue un'analisi piuttosto competente e ha il potenziale per imparare dai suggerimenti degli sviluppatori. In generale, siamo soddisfatti della nostra prima esperienza con SonarQube e prevediamo di svilupparlo ulteriormente in questa direzione. Ci aspettiamo che in futuro saremo in grado di risparmiare più tempo e fatica nel controllo del codice e di renderlo più qualitativo, eliminando il fattore umano. Forse nel processo scopriremo le carenze della piattaforma o, al contrario, ci convinceremo ancora una volta che si tratta di una soluzione interessante con un grande potenziale.
In questo articolo di revisione abbiamo parlato della nostra conoscenza dell'analizzatore statico SonarQube. Per qualsiasi domanda, scrivete nei commenti. Se siete interessati all'argomento, nella nuova pubblicazione descriveremo più dettagliatamente come impostare tutto correttamente e scrivere il codice per eseguire tale controllo.
Autore del testo:
Fonte: habr.com
