Vogliamo condividere l'esperienza di implementazione della piattaforma per l'analisi continua e la misurazione della qualità del codice SonarQube nei processi di sviluppo esistenti del sistema DPO (integrazione con il sistema di contabilità depositaria e di clearing "Alameda") del Deposito Nazionale di Liquidità.
Il Deposito Nazionale di Liquidità (gruppo di società "Borsa di Mosca") è una delle aziende chiave dell'infrastruttura finanziaria, conservando e registrando titoli di emittenti russi e stranieri per un valore superiore ai 50 trilioni di rubli. L'aumento del volume delle operazioni effettuate dal sistema, insieme all'espansione continua delle funzionalità, richiede il mantenimento di un elevato standard di 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'integrazione fluida dell'analizzatore statico SonarQube nei processi di sviluppo esistenti del nostro dipartimento.
Chi siamo nel dipartimento
Le nostre responsabilità includono i seguenti moduli: pagamenti ai clienti NDP, gestione elettronica dei documenti (GED), elaborazione dei messaggi del deposito commerciale (registrazione delle transazioni OTC), canali di interazione elettronica tra clienti e NDP e molto altro. In generale, un'ampia serie di attività riguardanti l'aspetto tecnico delle operazioni. Lavoriamo su richiesta. Le richieste degli operatori vengono elaborate dagli analisti: raccolgono i requisiti del cliente e ci presentano la loro visione su come dovrebbe essere implementato nel programma. Poi segue la sequenza standard: sviluppo del codice – testing – collaudo – consegna del codice all'ambiente di produzione al cliente finale.
Perché proprio SonarQube?
Questa è la prima esperienza del nostro reparto nell'implementazione di una piattaforma per il controllo della qualità del codice: in precedenza lo facevamo manualmente, effettuando solo revisioni del codice. Tuttavia, l'aumento del carico di lavoro richiede l'automazione di questo processo. Inoltre, nel team ci sono anche dipendenti inesperti, che non sono completamente a conoscenza dei regolamenti interni di sviluppo e tendono a commettere più errori. Abbiamo deciso di implementare un analizzatore statico per il controllo della qualità del codice. Dato che SonarQube era già stato utilizzato in alcuni sistemi dell'NRD, non abbiamo dovuto scegliere a lungo. In precedenza, i colleghi di altri reparti avevano analizzato il codice dei microservizi nel sistema “Alemida” (il sistema di registrazione e clearing di deposito dell'NRD), in CFT (sistema informativo per la contabilità, il bilancio, la preparazione della reportistica obbligatoria e interna), in alcuni altri sistemi. Per gli esperimenti abbiamo deciso di iniziare con la versione gratuita di SonarQube. Dunque, passiamo al nostro caso.
Processo di implementazione
Abbiamo:
- compilazione automatica del sistema in TeamCity;
- è stato configurato il processo di caricamento del codice tramite MergeRequest dal branch feature al branch master in GitLab (processo di sviluppo secondo il GitHub Flow);
- SonarQube, configurato per l'analisi del codice per il sistema DPO su base programmata.
Il nostro obiettivo: implementare l'analisi automatica del codice nei processi CI/CD DPO.
Deve essere configurato: il processo di verifica automatica del codice da parte dell'analizzatore statico ad ogni MergeRequest nel branch principale.
Cioè, l'immagine obiettivo è la seguente: non appena un sviluppatore carica le modifiche nel branch feature, si avvia un controllo automatico per rilevare nuovi errori nel codice. Se non ci sono errori, le modifiche possono essere approvate, altrimenti dovranno essere corrette. Già alla 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 tale da funzionare per compiti specifici degli sviluppatori, per ogni sistema e stile di programmazione.
Configurazione del QualityGate in SonarQube
L'analisi del QualityGate è qualcosa che abbiamo scoperto nel profondo di Internet. Inizialmente abbiamo utilizzato un altro approccio, più complesso e da un certo punto di vista non del tutto corretto. All'inizio, eseguivamo la scansione attraverso SonarQube due volte: analizzavamo il ramo feature e il ramo in cui intendevamo unire il ramo feature, per poi confrontare il numero di errori. Questo metodo non era stabile e non produceva sempre risultati corretti. Poi abbiamo scoperto che, invece di eseguire SonarQube due volte, si può impostare un limite sul numero di errori consentiti (QualityGate) e analizzare solo il ramo che stai caricando e confrontando.
Per ora stiamo ancora utilizzando un controllo del codice piuttosto primitivo. Va notato che SonarQube non è compatibile con alcuni linguaggi di programmazione, tra cui Delphi. Attualmente, per il nostro sistema analizziamo solo il codice PLSql.
Funziona così:
- Analizziamo solo il codice PL/SQL per il nostro progetto.
- In SonarQube, il QualityGate è configurato in modo tale che il numero di errori non aumenti con il commit.
- Il numero di errori al primo avvio era 229. Se il numero di errori durante il commit aumenta, il merge non è consentito.
- In seguito, se gli errori vengono corretti, sarà possibile riconfigurare il QualityGate.
- È anche possibile aggiungere nuovi punti per l'analisi, come la copertura del codice tramite test, ecc.
Schema di lavoro:
Nei commenti dell'esecuzione dello script si vede che il numero di errori nel ramo feature non è aumentato. Quindi va tutto bene.
Il pulsante Merge diventa disponibile.
Nei commenti dell'esecuzione dello script si nota che il numero di errori nel ramo feature è aumentato oltre il limite consentito. Quindi le cose vanno MALE.
Il pulsante Merge è rosso. Attualmente non c'è divieto di caricare modifiche su codice errato, ma questo viene fatto a discrezione dello sviluppatore responsabile. In futuro, sarà possibile vietare tali commit nel ramo principale.
Lavoro autonomo sugli errori
In seguito è necessario controllare tutti gli errori rilevati dal sistema, perché SonarQube analizza secondo i propri rigorosi standard. Ciò che considera un errore potrebbe non essere realmente un errore nel nostro codice. Pertanto, è necessario verificare e segnare se effettivamente si tratta di un errore, o se non è necessario correggere nulla nelle nostre condizioni. In questo modo riduciamo il numero di errori. Col tempo, il sistema imparerà a comprendere queste sfumature.
A cosa siamo giunti
Il nostro obiettivo era capire se fosse opportuno nel nostro caso tradurre il controllo del codice in automazione. E i risultati hanno soddisfatto le aspettative. SonarQube ci consente di lavorare con i linguaggi di cui abbiamo bisogno, effettua un'analisi piuttosto accurata e ha il potenziale per apprendere dai suggerimenti degli sviluppatori. In generale, siamo soddisfatti della nostra prima esperienza con SonarQube e pianifichiamo di svilupparci ulteriormente in questa direzione. Ci aspettiamo che in futuro potremo risparmiare più tempo e sforzi nel controllo del codice e renderlo di migliore qualità, eliminando il fattore umano. È possibile che nel processo scopriamo dei difetti della piattaforma o, al contrario, ci convinciamo ancora una volta che si tratta di uno strumento fantastico con un grande potenziale.
In questo articolo di panoramica abbiamo parlato del nostro incontro con l'analizzatore statico SonarQube. Se hai domande, non esitare a scrivere nei commenti. Se sei interessato a questo argomento, in una nuova pubblicazione descriveremo già più in dettaglio come configurare tutto correttamente e scrivere codice per effettuare questo tipo di controllo.
Autore del testo:
Fonte: habr.com
