Manuale d uso della piattaforma per lo sviluppo e rilascio di componenti software. QMSS - Continuous Integration

Transcript

1 Manuale d uso della piattaforma per lo sviluppo e rilascio di componenti software Verifica massiva - ReadMe 13/12/2017 README 1 di 7

2 AGGIORNAMENTI Versione Data Paragrafi modificati Motivo modifica /12/2017 Prima emissione. README 2 di 7

3 Sommario 1. Introduzione Corpo mail Allegati <nome unix progetto>.issues.txt build.log [2] Checkout sorgenti [3] Compilazione sonar.<referente RT>.VERIFICA.<nome unix progetto>.json issues components rules... 7 README 3 di 7

4 1. Introduzione Nell ambito della piattaforma OSCAT è stato implementato un sistema (QMSS) per la verifica dei sorgenti associati ai progetti relativi ai software commissionati da Regione Toscana. Per estendere la base dei progetti verificati si è ritenuto necessario adottare un meccanismo di verifica automatica applicato massivamente a tutti i progetti presenti nel repository. La mail ricevuta è parte di questa iniziativa e raccoglie le informazioni del processo di verifica applicato al progetto specificato in oggetto. In particolare questo documento descrive le informazioni presenti nel corpo della mail e negli allegati presenti. 2. Corpo mail Nel corpo della mail sono riassunte le principali informazioni di contesto: Progetto: il nome progetto unix Numero file analizzati: il numero totale dei file del progetto analizzati Numero di problemi (issue) individuati totali, suddivisi per: o Numero issue per severity (BLOCKER, CRITICAL, MAJOR, MINOR, INFO) Esito della compilazione (Success Failed) URL della dashboard SonarQube dove consultare ulteriori dettagli Se per il progetto in esame non sono stati rilasciati i sorgenti nel repository SCM viene comunicato il seguente messaggio: Il progetto analizzato non contiene sorgenti nella sezione SCM. 3. Allegati Gli allegati presenti nella mail di notifica della verifica dei progetti OSCAT sono quattro: README.pdf (questo documento) <nome unix progetto>.issues.txt build.log (generato da Jenkins, può non essere presente nel caso in cui la struttura dei sorgenti non sia compatibile con quella definita nel manuale Oscat Manuale d Uso della Piattaforma per lo Sviluppo e Rilascio di Componenti Software - Processo di Sviluppo e Rilascio al paragrafo 3.1.2) sonar.<referente RT>.VERIFICA.<nome unix progetto>.json (generato da SonarQube) 3.1. <nome unix progetto>.issues.txt È un file testuale, compendio del file sonar.<referente RT>.VERIFICA.<nome unix progetto>.json, contenente le informazioni sulle issue individuate e strutturato nel seguente modo: { "component": "<referente RT>.VERIFICA.RulesTester:src/main/java/it/toscana/regione/rulestester/rules/RDriverManager.java", "line": 15, README 4 di 7

5 } "message": "Utilizzo della classe DriverManager", "project": "<referente RT>.VERIFICA.RulesTester", "rule": "pmd:it.toscana.regione.rt-drivermanager", "severity": "CRITICAL", 3.2. build.log È un log della compilazione (Maven o ANT) del progetto. Come precedentemente osservato, può non essere presente nel caso in cui la struttura dei sorgenti non sia compatibile con quella definita nel manuale Oscat Manuale d Uso della Piattaforma per lo Sviluppo e Rilascio di Componenti Software - Processo di Sviluppo e Rilascio al paragrafo Il file di log presenta le seguenti sezioni: 1. header con informazioni tecniche 2. lista dei sorgenti scaricati (fase di checkout) 3. compilazione 4. invio sorgenti a SonarQube 5. recupero informazioni da SonarQube Le sezioni di diretto interesse sono la 2 e la [2] Checkout sorgenti In questa sezione sono elencati i file scaricati dal repository SCM di Oscat: il tag A associato significa che il file è stato aggiunto al workspace (Add). il tag AU indica i file binari (documenti Word, jar, ecc.) la lista termina con la riga At revision X con X = numero di modifiche che ha subito il repository [3] Compilazione Dopo il checkout dei sorgenti viene eseguita la compilazione. Abbiamo due casi: MAVEN: viene eseguito il parsing del pom.xml (che deve essere presente sulla directory root del progetto) e la piattaforma inizia la compilazione standard con il comando: mvn clean install ANT: viene eseguito il parsing del build.xml (che deve essere presente sulla directory root del progetto) e la piattaforma inizia la compilazione con il seguente comando: ant build README 5 di 7

6 Le compilazioni possono terminare correttamente o con errore: MAVEN [INFO] BUILD SUCCESS [INFO] Total time: 02:29 min [INFO] Finished at: T16:12:43+01:00 [INFO] Final Memory: 39M/392M [INFO] BUILD FAILURE [INFO] Total time: s [INFO] Finished at: T16:17:15+01:00 [INFO] Final Memory: 16M/170M ANT BUILD SUCCESSFUL Build step 'Invoke Ant' marked build as failure I vari job terminano tutti con successo anche se la compilazione non va a buon fine. Quindi in fondo al file di log sarà sempre presente il pattern: INFO: INFO: EXECUTION SUCCESS INFO: Questo perché, dopo la compilazione, i file sorgenti vengono comunque passati a SonarQube per l analisi del codice sonar.<referente RT>.VERIFICA.<nome unix progetto>.json È un file contenente i risultati dell analisi effettuata da SonarQube sui sorgenti memorizzati nel formato JSON (JavaScript Object Notation). Un pratico viewer on line è raggiungibile alla URL Il file JSON è suddiviso in varie sezioni di cui andremo a descrivere quelle di interesse issues Elenco (Array) di problemi individuati da SonarQube ognuno descritto con i seguenti campi: "component": longname del componente interessato, "componentid": id del component interessato, "creationdate": data di creazione della issue, "fupdateage": data di aggiornamento della issue, "key": chiave della issue, README 6 di 7

7 "line": linea di codice dove è stata trovata la issue, "message": messaggio della issue, "project": progetto, "rule": regola, "severity": severità, "status": stato (issue APERTA, issue CHIUSA), "updatedate": Data di aggiornamento components Elenco (Array) dei sorgenti analizzati (riferiti nel campo component della lista precedente): "id": ID del componente, "key": chiave del componente "longname": Nome del componente dentro il progetto, "name": Nome della classe, "path": path del componente/classe dentro il progetto, "projectid": ID del progetto, "qualifier": tipo del componente: VW: view SVW: sub-view TRK: project BRC: module CLA: class UTS: unit test DIR: directory FIL: file DEV: developer, "subprojectid": ID del sottoprogetto, se presente rules Elenco (Array) delle regole configurate in SonarQube e utilizzate per verificare la qualità del software: "desc": Descrizione della regola, "key": chiave della regola, "name": nome della regola, "status": stato della regola README 7 di 7