Quanta cronologia dell'analisi statica dovrebbe conservare un'azienda?

Non credo che sia necessario conservare molte informazioni di analisi statica, se non del tutto. Tuttavia, per supportare questo, hai bisogno di buone pratiche di gestione della configurazione.

In primo luogo, dovresti codificare regolarmente il codice nel tuo repository del codice sorgente. Prendi in considerazione i tag ( git , Svversione , ClearCase - la maggior parte dei sistemi di controllo delle versioni dovrebbe supportare funzionalità simili) qualsiasi build che fai. Contrassegnando le build cruciali con un identificatore univoco (come un numero di build o un timestamp), puoi collegare elementi come una particolare istantanea del codice sorgente alle voci in un database di tracciamento dei difetti o risultati di analisi statiche.

Ora che disponi di tag, puoi associare i risultati dell'analisi statica a specifici repository di codice sorgente. È comunemente accettato che non si debba mantenere il codice generato nel controllo della versione. Direi che non si dovrebbe tenere tutto ciò che può essere generato direttamente dal codice sorgente, che include l'analisi statica. Tuttavia, ai fini della tracciabilità, dovrai essere in grado di associare i difetti derivati dall'analisi statica alla build che ha causato il rilevamento.

Realisticamente, potresti voler mantenere alcuni risultati di analisi statica. Ad esempio, i risultati dell'analisi prima di una versione esterna possono essere inclusi come parte di un rapporto di prova formale. Anche se non fa parte di un rapporto di prova, è possibile mantenerlo in un archivio di progetto. Si può anche considerare di includere un sommario dell'analisi statica (come numero di risultati, numero di risultati per riga di codice sorgente, numero di risultati per modulo, numero di risultati per criticità o numero di risultati per tipo).

Potresti anche considerare come gestisci il tuo strumento di analisi statica, specialmente se lo stai utilizzando come parte di un qualche tipo di test o report formale. È necessario essere in grado di considerare la versione dello strumento, nonché il file di configurazione oi parametri utilizzati durante l'esecuzione dello strumento su una determinata versione del codice di base. Se non gestisci la versione e la configurazione del tuo strumento, diventa più difficile riuscire a rigenerare esattamente lo stesso rapporto per un determinato codice base.

Trovo che mantenere i risultati dell'analisi statica sia un'ottima pratica. Non sarei necessariamente così interessato a "quale build ha introdotto questo avviso", perché questo dovrebbe essere relativamente facile da vedere dal tuo sistema di controllo delle versioni. Inoltre, se sei interessato a tracciare la cronologia di un determinato avviso di analisi statica, probabilmente hai già fatto qualcosa di sbagliato, non correggendo quell'avvertimento quando è apparso in primo luogo.

Il motivo principale per cui mi piace la cronologia dei risultati dell'analisi statica è che mi consente di vedere le tendenze. Ad esempio, posso vedere la quantità di righe di codice, il numero di problemi e le metriche di copertura del codice. I problemi, per esempio, dovrebbero essere in una relazione lineare con le linee di codice. Se il numero di problemi cresce più velocemente delle righe di codice, qualcuno probabilmente sta facendo qualcosa di sbagliato. Allo stesso modo, aiuta a stabilire una linea di base della copertura di test desiderata, e puoi vedere se inizia a immergersi, se qualcuno dimentica di creare test.

Per quanto riguarda la tua domanda effettiva su quanto tempo conservare le informazioni di analisi statica. Direi che dovresti tenerlo bene fin dall'inizio del progetto, ma non hai bisogno di tenerlo tutto . Ad esempio, SonarQube, che sarebbe la mia arma preferita, elimina automaticamente le sue vecchie istantanee. (Un'istantanea è un insieme di risultati di analisi statiche su una particolare build.) Le regole predefinite sono descritte in link e la parte più rilevante è questa:

• only one snapshot per day is kept after 1 day. Snapshots marked by an event are not deleted.
• only one snapshot per week is kept after 1 month. Snapshots marked by an event are not deleted.
• only one snapshot per month is kept after 1 year. Snapshots marked by an event are not deleted.
• all snapshots older than 5 years are deleted, including snapshots marked by an event.

Quindi per il giorno corrente vedi tutte le analisi, ma domani solo l'ultima analisi del giorno precedente è disponibile, le altre sono state cancellate. Alla fine di aprile vengono cancellati tutti tranne l'ultima analisi di marzo. Ecc. Quindi vai per una diversa risoluzione per diversi periodi di tempo. Ciò ti consente di salvare in modo efficiente diversi anni di dati.