Vorremmo condividere la nostra esperienza nell'implementazione di una piattaforma per l'analisi continua e la misurazione della qualità del codice SonarQube nei processi esistenti per lo sviluppo del sistema DPO (un'aggiunta al sistema di deposito e compensazione Alameda) del National Settlement Depository.
Il National Settlement Depository (Moscow Exchange Group of Companies) è una delle principali società di infrastrutture finanziarie che immagazzina e registra titoli di emittenti russi e stranieri per un valore di oltre 50 trilioni di rubli. Il crescente volume di operazioni svolte dal sistema, così come il continuo aumento delle funzionalità, richiedono il mantenimento dell'elevata qualità del codice sorgente dei sistemi. Uno degli strumenti per raggiungere questo obiettivo è l'analizzatore statico SonarQube. In questo articolo, descriviamo 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
La nostra competenza include i seguenti moduli: pagamenti ai clienti NSD, gestione elettronica dei documenti (EDF), elaborazione dei messaggi del trade repository (registrazione delle transazioni fuori borsa), canali di interazione elettronica tra clienti e NSD e molto altro. In generale, un ampio livello di lavoro sul lato tecnico delle operazioni. Lavoriamo sulla base delle applicazioni. Le candidature dei cassieri vengono elaborate dagli analisti: raccolgono i requisiti dei clienti e ci presentano la loro visione di come dovrebbe inserirsi nel programma. Inoltre, lo schema standard: sviluppo del codice - test - operazione di prova - consegna del codice al circuito produttivo al cliente diretto.
Perché SonarQube?
Questa è la prima esperienza del nostro dipartimento nell'implementazione di una piattaforma per il controllo della qualità del codice - prima lo facevamo manualmente, solo revisione del codice. Ma il crescente volume di lavoro richiede l'automazione di questo processo. Inoltre, nel team ci sono anche dipendenti inesperti che non conoscono del tutto le normative di sviluppo interno e tendono a commettere più errori. Per controllare la qualità del codice, si è deciso di implementare un analizzatore statico. Poiché SonarQube è già stato utilizzato in alcuni sistemi NSD, non ci è voluto molto per scegliere. In precedenza, i colleghi di altre divisioni lo utilizzavano per analizzare il codice dei microservizi nel sistema Alameda (il sistema di contabilità di deposito e compensazione proprio di NSD), nel CFT (sistema informativo per la contabilità, il bilancio, la preparazione della rendicontazione obbligatoria e interna), in alcuni altri sistemi. Per la sperimentazione, abbiamo deciso di iniziare con la versione gratuita di SonarQube. Quindi passiamo al nostro caso.
Processo di implementazione
Abbiamo:
- assemblaggio automatico del sistema in TeamCity;
- impostare il processo di caricamento del codice tramite MergeRequest da un feature branch al master branch in GitLab (processo di sviluppo secondo GitHub Flow);
- SonarQube configurato per analizzare il codice per il sistema DPO nei tempi previsti.
Il nostro obbiettivo: implementare l'analisi automatica del codice nei processi CI/CD di AVE.
Bisogno di personalizzare: il processo di controllo automatico del codice da parte di un analizzatore statico con ogni MergeRequest al ramo principale.
Quelli. l'immagine di destinazione è la seguente: non appena lo sviluppatore carica le modifiche al feature branch, inizia un controllo automatico per 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 tale da funzionare per compiti specifici degli sviluppatori, per ogni sistema e stile di programmazione.
Configurazione di QualityGate in SonarQube
L'analisi QualityGate è una cosa che leggiamo nelle viscere di Internet. Inizialmente, abbiamo utilizzato un approccio diverso, più complesso e in qualche modo non del tutto corretto. Per prima cosa, abbiamo eseguito la scansione attraverso SonarQube due volte: abbiamo scansionato il ramo delle caratteristiche e il ramo in cui avremmo unito il ramo delle caratteristiche, quindi abbiamo confrontato il numero di errori. Questo metodo non era stabile e non dava sempre il risultato corretto. E poi abbiamo appreso che invece di eseguire SonarQube due volte, puoi impostare un limite al numero di errori commessi (QualityGate) e analizzare solo il ramo che carichi e confronti.
Per ora, utilizziamo ancora un controllo del codice piuttosto primitivo. Va notato che SonarQube non è compatibile con alcuni linguaggi di programmazione, incluso Delphi. Al momento, per il nostro sistema, analizziamo solo codice PLSql.
Funziona così:
- Analizziamo solo codice PL/SQL per il nostro progetto.
- QualityGate è configurato in SonarQube in modo che il numero di errori non aumenti con il commit.
- Il numero di errori alla prima esecuzione era 229. Se ci sono più errori durante il commit, l'unione non è consentita.
- Inoltre, previa correzione degli errori, sarà possibile riconfigurare QualityGate.
- Puoi anche aggiungere nuovi elementi per l'analisi, ad esempio la copertura del codice con i test, ecc.
Schema di lavoro:
Nei commenti dello script, puoi vedere che il numero di errori nel feature branch non è aumentato. Quindi è tutto a posto.
Il pulsante Unisci diventa disponibile.
Nei commenti dello script, puoi vedere che il numero di errori nel feature branch è diventato superiore a quello consentito. Quindi tutto è MALE.
Il pulsante Unisci è rosso. Al momento, non vi è alcun divieto di caricare modifiche al codice errato, ma ciò viene fatto a discrezione dello sviluppatore responsabile. In futuro, puoi impedire che tali commit vengano effettuati sul ramo principale.
Gestire autonomamente i bug
Successivamente, è necessario controllare tutti gli errori rilevati dal sistema, perché SonarQube analizza secondo i suoi rigidi standard. Quello che considera un errore potrebbe non essere effettivamente uno nel nostro codice. Pertanto, è necessario verificare e notare se si tratta davvero di un errore o se non è necessario modificare le nostre condizioni. Pertanto, riduciamo il numero di errori. Nel tempo, il sistema imparerà a comprendere queste sfumature.
A cosa siamo arrivati
Il nostro obiettivo era capire se nel nostro caso fosse opportuno trasferire la verifica del codice all'automazione. E il risultato è stato all'altezza delle aspettative. SonarQube ci consente di lavorare con le lingue di cui abbiamo bisogno, esegue analisi abbastanza competenti e ha il potenziale per imparare dai suggerimenti degli sviluppatori. In generale, siamo soddisfatti della nostra prima esperienza con SonarQube e prevediamo di svilupparci ulteriormente in questa direzione. Ci aspettiamo che in futuro saremo in grado di risparmiare più tempo e fatica sulla revisione del codice e migliorarla eliminando il fattore umano. Forse nel processo scopriremo i difetti della piattaforma o, al contrario, ci assicureremo ancora una volta che si tratti di una cosa interessante con un grande potenziale.
In questo articolo di panoramica, abbiamo parlato della nostra conoscenza dell'analizzatore statico SonarQube. Se hai domande, scrivi nei commenti. Se sei interessato a questo argomento, nella nuova pubblicazione descriveremo in modo più dettagliato come impostare tutto correttamente e scrivere il codice per eseguire tale controllo.
Autore del testo:
Fonte: habr.com