Desideriamo condividere l'esperienza di integrazione della piattaforma per l'analisi continua e la misurazione della qualità del codice SonarQube nei processi di sviluppo esistenti del sistema DPO (complemento al sistema di registrazione e clearing "Alameda") del Deposito Nazionale di Registrazione.
Il Deposito Nazionale di Registrazione (gruppo di aziende "Borsa di Mosca") è una delle principali aziende dell'infrastruttura finanziaria, custodisce e contabilizza titoli di valore di emittenti russi e stranieri per un ammontare superiore a 50 trilioni di rubli. L'aumento del volume delle operazioni effettuate dal sistema, così come il continuo ampliamento 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 integrazione senza soluzione di continuità dell'analizzatore statico SonarQube nei processi di sviluppo del nostro dipartimento.
Breve introduzione al dipartimento
Nella nostra competenza rientrano i seguenti moduli: pagamenti ai clienti NRD, flusso di documenti elettronici (EDE), elaborazione dei messaggi del repository commerciale (registrazione delle transazioni non quotate), canali di interazione elettronica tra clienti e NRD e molto altro. In sostanza, un ampio lavoro sulla parte tecnica delle operazioni. Lavoriamo sulla base di richieste. Le richieste degli operatori vengono elaborate dagli analisti: essi raccolgono i requisiti del cliente e ci presentano la loro visione su come dovrebbe essere implementato nel programma. Successivamente, segue la schematizzazione standard: sviluppo del codice – collaudo – sperimentazione operativa – consegna del codice nell'ambiente 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 – in precedenza, facevamo tutto manualmente, limitandoci a code review. Tuttavia, l'aumento del volume di lavoro richiede l'automazione di questo processo. Inoltre, nel team ci sono anche membri meno esperti che non sono completamente familiari con i protocolli interni di sviluppo e tendono a commettere più errori. È stata quindi presa la decisione di implementare un analizzatore statico per il controllo della qualità del codice. Dal momento che SonarQube era già stato utilizzato in alcuni sistemi NRD, non abbiamo dovuto pensarci troppo. In passato, i colleghi di altri dipartimenti analizzavano il codice dei microservizi nel sistema "Alameda" (il sistema interno di deposito e clearing di NRD), in CFT (sistema informativo per la gestione della contabilità, bilancio e preparazione di report obbligatori e interni) e in alcuni altri sistemi. Per gli esperimenti, abbiamo deciso di iniziare con la versione gratuita di SonarQube. Quindi, passiamo al nostro caso.
Processo di implementazione
Abbiamo:
- build automatica del sistema in TeamCity;
- processo di upload del codice configurato tramite MergeRequest da un ramo feature al ramo master in GitLab (processo di sviluppo secondo GitHub Flow);
- SonarQube, configurato per analizzare il codice del sistema DPO secondo una pianificazione.
Il nostro obiettivo: implementare l'analisi automatica del codice nei processi CI/CD del DPO.
Deve essere configurato: processo di verifica automatica del codice tramite analisi statica ad ogni MergeRequest nella branch principale.
Cioè, il quadro target è il seguente: non appena uno sviluppatore carica modifiche nel branch feature, viene avviata un'analisi automatica per rilevare nuovi errori nel codice. Se non ci sono errori, le modifiche possono essere accettate; in caso contrario, sarà necessario correggere gli errori. Già nelle prime fasi abbiamo potuto identificare un certo numero di errori nel codice. Il sistema offre impostazioni molto flessibili: può essere configurato in modo da funzionare in base alle specifiche esigenze degli sviluppatori, per ciascun sistema e stile di programmazione.
Configurazione del QualityGate in SonarQube
L'analisi QualityGate è qualcosa che abbiamo scoperto nel profondo di Internet. Inizialmente usavamo un approccio diverso, più complicato e non sempre corretto. Prima eseguivamo due volte la scansione tramite SonarQube: scansionavamo il ramo feature e il ramo in cui volevamo unire il ramo feature, per poi confrontare il numero di errori. Questo metodo non era stabile e non restituiva sempre risultati corretti. Poi abbiamo scoperto che potevamo, invece di eseguire due passaggi con SonarQube, impostare un limite sul numero di errori ammessi (QualityGate) e analizzare solo il ramo che stai caricando e confrontando.
Finora stiamo ancora utilizzando un controllo del codice piuttosto primitivo. Vale la pena notare che SonarQube non è compatibile con alcuni linguaggi di programmazione, incluso Delphi. Attualmente, per il nostro sistema stiamo analizzando solo codice PLSql.
Funziona così:
- Analizziamo solo codice PL/SQL per il nostro progetto.
- In SonarQube, il QualityGate è impostato in modo tale che il numero di errori non aumenti con il commit.
- Il numero di errori al primo avvio è stato di 229. Se il numero di errori durante il commit aumenta, allora il merge non è consentito.
- Successivamente, a seguito della correzione degli errori, sarà possibile riconfigurare QualityGate.
- È inoltre possibile aggiungere nuovi punti per l'analisi, come la copertura del codice con i test, ecc.
Schema di funzionamento:
Nei commenti dell'esecuzione dello script si può vedere che il numero di errori nel ramo feature non è aumentato. Quindi tutto va bene.
Diventa disponibile il pulsante Merge.
Nei commenti dell'esecuzione dello script si può vedere che il numero di errori nel ramo feature è aumentato oltre il limite accettabile. Quindi, la situazione è grave.
Il pulsante Merge è rosso. Attualmente non c'è divieto di caricare modifiche su codice errato, ma ciò avviene a discrezione del responsabile dello sviluppo. In futuro sarà possibile vietare tali commit nel ramo principale.
Lavoro autonomo sugli errori.
Successivamente, è necessario controllare tutti gli errori identificati dal sistema, poiché SonarQube analizza secondo i suoi rigorosi standard. Ciò che considera un errore potrebbe non esserlo nel nostro codice. Pertanto, è necessario verificare e annotare se si tratta realmente di un errore o se non è necessario apportare correzioni 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 fosse opportuno nel nostro caso tradurre il controllo del codice in automazione. E i risultati hanno superato le aspettative. SonarQube ci permette di lavorare con i linguaggi di cui abbiamo bisogno, offre 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 intendiamo proseguire su questa strada. Ci aspettiamo che in futuro potremo risparmiare più tempo e sforzi nel controllo del codice, migliorandone la qualità e riducendo il fattore umano. È possibile che nel processo scopriremo dei difetti della piattaforma o, al contrario, confermeremo ancora una volta che si tratta di una risorsa straordinaria con un grande potenziale.
In questo articolo di panoramica abbiamo parlato del nostro incontro con l'analizzatore statico SonarQube. Se avete domande, non esitate a scrivere nei commenti. Se siete interessati a questo argomento, in una nuova pubblicazione descriveremo in dettaglio come configurare tutto correttamente e scrivere codice per eseguire tale verifica.
Autore del testo:
Fonte: habr.com
