{"id":3293,"date":"2021-06-25T13:59:00","date_gmt":"2021-06-25T11:59:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=3293"},"modified":"2021-07-02T17:52:29","modified_gmt":"2021-07-02T15:52:29","slug":"come-arricchire-le-pipeline-di-cd-ci-con-la-static-code-analysis-utilizzando-sonarqube","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/come-arricchire-le-pipeline-di-cd-ci-con-la-static-code-analysis-utilizzando-sonarqube\/","title":{"rendered":"Come arricchire le pipeline di CD\/CI con la static code analysis utilizzando SonarQube"},"content":{"rendered":"\n
Abbiamo pi\u00f9 volte trattato le pipeline di continuous delivery nel corso degli anni; questo perch\u00e9 crediamo davvero che disporre di un processo automatico, affidabile e completamente gestito per testare e distribuire il codice aiuti ad aumentare la qualit\u00e0 e la quantit\u00e0 del codice prodotto.<\/p>\n\n
Configurare una buona pipeline di CI\/CD \u00e8 un aspetto fondamentale per accelerare la distribuzione del software senza sacrificarne la qualit\u00e0, inoltre \u00e8 imprescindibile includere uno step di static code analysis nelle pipeline per sfruttarne a pieno i vantaggi e le potenzialit\u00e0. <\/p>\n\n
Uno strumento di static code analysis ispeziona la codebase durante il ciclo di sviluppo ed \u00e8 in grado di identificare bug, vulnerabilit\u00e0 e problemi di conformit\u00e0 senza eseguire effettivamente il codice sorgente. <\/p>\n\n
L’analisi del codice pu\u00f2 aiutare a garantire che il software sia sicuro, affidabile e conforme agli standard di qualit\u00e0 e stile definiti a livello aziendale.<\/p>\n\n
La static code analysis \u00e8 una pratica che consente ai team di sviluppo di rilevare automaticamente potenziali bug, problemi di sicurezza e, pi\u00f9 in generale, difetti nel codice sorgente di una o pi\u00f9 applicazioni. Pertanto, possiamo vedere l’analisi statica come un ulteriore processo di revisione del codice automatizzato. Esaminiamo questa analogia pi\u00f9 in dettaglio.<\/p>\n\n
Il processo di revisione del codice, o code review, \u00e8 probabilmente il modo migliore per garantire la qualit\u00e0 del codice prodotto da un team di sviluppo. Durante una code review, una coppia di sviluppatori esamina il codice con l’obiettivo preciso di migliorarlo e di individuare pratiche pericolose sia dal punto di vista della manutenibilit\u00e0 che della sicurezza. <\/p>\n\n
Durante il processo di revisione, l’autore del codice non dovrebbe spiegare come funzionano determinate parti del programma in modo che il revisore non sia prevenuto sul suo giudizio. Inoltre, il codice dovrebbe essere chiaro, semplice, e altamente gestibile; la complessit\u00e0 dovrebbe essere mitigata dall’astrazione e dall’incapsulamento. Infine, il codice dovrebbe essere ritenuto sufficientemente chiaro, gestibile e sicuro, da entrambi i programmatori per superare la revisione.<\/p>\n\n
Le code review sono particolarmente efficaci perch\u00e9 \u00e8 pi\u00f9 facile per uno sviluppatore, individuare bug, code smell, e suggerire miglioramenti al codice prodotto da qualcun altro, piuttosto che sul suo lavoro, per il quale si ha un forte bias. <\/p>\n\n
La pratica delle review dovrebbe essere eseguita con la maggiore frequenza possibile; tuttavia, l’attivit\u00e0 richiede molto tempo e di conseguenza risulta molto costosa sia in termini di tempo che di denaro.<\/p>\n\n
Un modo eccellente per aumentare la frequenza delle revisioni del codice consiste quindi nell’includere uno step di code review automatica all\u2019interno delle pipeline utilizzando uno strumento di static code analysis.<\/p>\n\n
Esistono strumenti e soluzioni per implementare la static code analysis in grado di scansionare automaticamente la codebase e generare report accurati sulle condizioni del codice che sono rivolti agli sviluppatori. Tali strumenti sono solitamente facili da integrare nelle pipeline CD\/CI; solitamente il comando di scansione restituisce un exit code mediante il quale \u00e8 possibile determinare se il codice \u00e8 sufficientemente buono o se non supera l’analisi statica.<\/p>\n\n
Naturalmente, una soluzione completamente automatizzata non pu\u00f2 sostituire una revisione completa del codice eseguita da uno o pi\u00f9 sviluppatori. Tuttavia, l’aumento del rapporto tra la frequenza dell’analisi del codice e l’impatto relativamente economico sul prezzo complessivo rende l’aggiunta di uno step di analisi alla pipeline un modo efficiente per migliorare la qualit\u00e0 e la sicurezza del codice.<\/p>\n\n
Aggiungere questo step non sostituisce le code review, ma la sua aggiunta porta sicuramente benefici a buon mercato.<\/p>\n\n
Molti strumenti di code analysis, sia commerciali che gratuiti, supportano una vasta pletora di linguaggi di programmazione. Uno dei pi\u00f9 famosi \u00e8 SonarQube<\/strong>, che descriveremo meglio in seguito.<\/p>\n\n Direttamente da AWS possiamo anche sfruttare CodeGuru<\/strong>, un servizio basato sul machine learning, che \u00e8 facile da integrare nelle pipeline e pu\u00f2 fornire suggerimenti di alta qualit\u00e0 per migliorare il codice. Sfortunatamente, al momento, CodeGuru supporta solo Java e Python, quest\u2019ultimo in preview.<\/p>\n\n CodeGuru mira a diventare uno strumento di analisi robusto e di alta qualit\u00e0. Tuttavia, al momento, \u00e8 stabile da utilizzare solo per gli sviluppatori Java; quindi, ci concentreremo su una soluzione pi\u00f9 matura che pu\u00f2 essere utilizzata per molte pi\u00f9 linguaggi.<\/p>\n\n Questo articolo approfondir\u00e0 come integrare SonarQube<\/strong> in una pipeline di CD\/CI.<\/p>\n\n Sonarqube<\/a> is open-source software for continuous inspection of code quality. It performs automatic reviews with static analysis on more than 20 programming languages. It can spot duplicated code, compute code coverage, code complexity, and finds bugs and security vulnerabilities. In addition, it can record metrics history and provides evolution graphs via a dedicated web interface.<\/p>\n\n The drawback of using SonarQube is that you can either subscribe to the managed SonarQube service (not provided by AWS) or manage your own installation.<\/p>\n\n Di solito tendiamo a consigliare e sfruttare servizi fully managed per la pipeline di sviluppo, perch\u00e9 consentono di concentrarsi sul core business piuttosto che sull’infrastruttura o sugli strumenti necessari per realizzare la pipeline. <\/p>\n\n Tuttavia, in questo caso, abbiamo optato per una soluzione personalizzata a causa di un modello di pricing non compatibile con il nostro utilizzo dello strumento. Inoltre, la fase di revisione automatica non \u00e8 un bloccante per la pipeline durante lo sviluppo, rendendo la disponibilit\u00e0 del cluster non critica.<\/p>\n\n In questo breve tutorial illustreremo ad alto livello come configurare un cluster SonarQube su AWS sfruttando i servizi gestiti.<\/p>\n\n Realizzeremo un cluster altamente disponibile e scalabile basato su ECS Fargate e Amazon Aurora Serverless<\/p>\n\n <\/p>\n\n <\/p>\n\n Per funzionare correttamente, SonarQube necessita di un database PostgreSQL o MySQL. In questo tutorial utilizzeremo Amazon Aurora Serverless con compatibilit\u00e0 PostgreSQL.<\/p>\n\n Per creare il database basta accedere alla Console di gestione AWS, navigare sino alla sezione AWS RDS e fai cliccare sul pulsante “Crea database”. Nel modulo seguente, selezionare Amazon Aurora come engine, Amazon Aurora con compatibilit\u00e0 PostgreSQL come edizione e Serverless come tipo di capacit\u00e0. Un riassunto delle scelte \u00e8 disponibile nell’immagine qui sotto.<\/p>\n\n <\/p>\n\n <\/p>\n\n Infine, completare la configurazione del cluster impostando il nome del database, la password e tutta la configurazione di rete.<\/p>\n\n Per esporre il servizio Fargate che conterr\u00e0 la nostra applicazione Sonarqube, dobbiamo creare un AWS Application Load Balancer con il suo target group. Per abilitare HTTPS, occorre creare o importare un certificato SSL all’interno di AWS Certificate Manager. In caso contrario, nella creazione del load balancer, \u00e8 possibile configurare solo il listener sulla porta 80.<\/p>\n\n Iniziamo quindi a creare il target group dalla pagina del servizio EC2. Nella sezione target group fare clic sul pulsante “Crea target group”. Selezionare “Indirizzo IP” come tipo di destinazione, HTTP come protocollo e 9000 come porta; assicurarsi inoltre di selezionare HTTP1 come versione del protocollo.<\/p>\n\n Ora che abbiamo il nostro target group, possiamo creare l’Application Load Balancer. Per farlo, dalla sezione Load Balancer all’interno della Console EC2 fare clic sul pulsante Crea Load Balancer. Quindi, fare clic sul pulsante Crea nella sezione Application Load Balancer nella procedura guidata come nell’immagine sottostante.<\/p>\n\n <\/p>\n\n <\/p>\n\n Selezionare il tipo internet facing e creare due listener, uno sulla porta 80 e uno sulla porta 443. Il bilanciatore va associato alle subnet pubbliche per rendere il cluster raggiungibile da internet.<\/p>\n\n <\/p>\n\n <\/p>\n\n Nella sezione successiva (solo se si crea il listener sulla porta 443), seleziona un certificato SSL da AWS Certificate Manager per abilitare HTTPS.<\/p>\n\n Infine, selezionare il target group creato precedentemente.<\/p>\n\n <\/p>\n\n <\/p>\n\n Se si sceglie di esporre il cluster via HTTPS occorre modificare il comportamento della regola di default per implementare un redirect da http ad https e inoltrare il traffico https ai container fargate.<\/p>\n\n <\/p>\n\n <\/p>\n\n Nella pagina di modifica, eliminare il comportamento predefinito e crearne uno nuovo facendo clic sul pulsante “Aggiungi azione”. Nella lista di controllo, selezionare il valore “Reindirizza a” per reindirizzare il traffico http al listener https.<\/p>\n\n <\/p>\n\n <\/p>\n\n Dalla console di ECS nella sezione Cluster ECS fare clic sul pulsante “Crea cluster”. Quindi, selezionare il modello “Networking only” come l’immagine qui sotto.<\/p>\n\n <\/p>\n\n <\/p>\n\n Indicare un nome per il cluster e procedere con il wizard. <\/p>\n\n <\/p>\n\n Nella sezione successiva selezionare “Crea nuova task definition” e selezionare il tipo Fargate.<\/p>\n\n <\/p>\n\n <\/p>\n\n Impostare quindi il ruolo IAM precedentemente configurato<\/p>\n\n e selezionare il dimensionamento dei container a 8 GB per la RAM e 2 vCPU.<\/p>\n\n <\/p>\n\n <\/p>\n\n Nella sezione container, aggiungere un nuovo container ed utilizzare “public.ecr.aws\/bitnami\/sonarqube:8.9.1” come immagine. Quest\u2019immagine \u00e8 la versione ufficiale di Sonarqube ospitata da AWS su un ECR pubblico. Volendo, \u00e8 possibile utilizzare il proprio repository privato ECR con una versione modificata o comunque controllata dell\u2019immagine di SonarQube. Nella mappatura delle porte, occorre mappare la porta 9000 del container.<\/p>\n\n <\/p>\n\n <\/p>\n\n Nella sezione delle variabili di ambiente occorre impostare i seguenti valori per il corretto funzionamento dell\u2019immagine di SonarQube:<\/p>\n\n <\/p>\n\n <\/p>\n\n At this point, you can configure a service for the SonarQube cluster. For example, you can define a service specifying a task and a set of parameters that determine how many instances of the task are required as a minimum, current, and maximum value to allow the service to function correctly. You can read more on how to set up a service in our previous article here<\/a>.<\/p>\n\n Alla fine, ECS avvier\u00e0 le istanze necessarie e sar\u00e0 possibile accedere al software mediante l\u2019URL del load balancer.<\/p>\n\n Ora che il cluster \u00e8 attivo e funzionante, possiamo accedervi e iniziare a configurare SonarQube. \u00c8 possibile mettere a punto la configurazione e le preferenze delle scansioni. Una volta che il nostro progetto \u00e8 stato creato e configurato, possiamo configurare l\u2019automatismo per analizzare il codice durante l\u2019esecuzione della pipeline.<\/p>\n\n Ci sono diversi modi per raggiungere questo obiettivo. Il pi\u00f9 comune e facile da implementare \u00e8 semplicemente aggiungere l\u2019esecuzione di un comando alla fase di build su CodeBuild. Per avviare un’analisi, \u00e8 necessario installare un agent e quindi eseguire un comando per avviare il processo. <\/p>\n\nSetup di SonarQube su AWS<\/h2>\n\n
<\/figure><\/div>\n\n
Creazione del cluster Amazon Aurora Serverless<\/h3>\n\n
<\/figure>\n\n
Creazione di un Application Load Balancer e del Target Group<\/h3>\n\n
<\/figure><\/div>\n\n
<\/figure><\/div>\n\n
<\/figure>\n\n
<\/figure>\n\n
<\/figure><\/div>\n\n
Creare il Cluster Fargate<\/h3>\n\n
<\/figure><\/div>\n\n
Dal pannello di gestione IAM, creare un nuovo ruolo IAM e collegarvi le policy gestite denominate “AmazonECSTaskExecutionRolePolicy<\/a>” e “AmazonEC2ContainerServiceRole<\/a> “.<\/p>\n\n<\/figure>\n\n
<\/figure><\/div>\n\n
<\/figure><\/div>\n\n
<\/figure><\/div>\n\n
<\/figure><\/div>\n\n
Come integrare la scansione SonarQube nella pipeline<\/h2>\n\n