Il miglior approccio per eseguire un audit di configurazione fisica CMMI?

Question

L'organizzazione che attualmente lavoro per un'organizzazione che si sta muovendo nell'intero mondo CMMI per documentare tutto. Mi è stato assegnato (insieme a un altro individuo) il titolo di Configuration Manager. Congratulazioni a me giusto.

Parte dei compiti consiste nell'eseguire regolarmente (stanno ancora definendo regolarmente, sarà trimestrale o mensile) un audit di configurazione fisica. Questo è fondamentalmente un controllo delle versioni del codice sorgente distribuite in produzione a quelle che crediamo siano le versioni del codice sorgente in produzione.

Il nostro progetto è un'applicazione web relativamente piccola con scritta in Java. I tipi di file con cui lavoriamo sono java, jsp, xml, file delle proprietà e pacchetti sql.

Il problema che ho (e che ho espresso ma sembra essere ignorato) è come dovrei accedere fisicamente al server di produzione e verificare le versioni dei file e, anche se potessi, ci vorrebbe un tempo ridicolo?

Le versioni del file non sono nemmeno attualmente nel file (cioè in un commento o qualcosa del genere). È stato suggerito di posizionare numeri di versione visibili su ogni schermata visibile anche agli utenti. Ho pensato anche a questo ridicolo, poiché gli schermi stessi rappresentano solo una piccola parte del codice che manteniamo.

Gli strumenti che attualmente utilizziamo sono Netbeans per il nostro IDE e le dimensioni Serena come nostro strumento di controllo delle versioni.

Sto specificatamente cercando idee su come eseguire questo audit in modo spero più automatizzato, che sia accurato e non dispendioso in termini di tempo.

La mia idea è attualmente quella di aggiungere un commento all'inizio di ogni file che contenga il numero di versione di quel file, uno script che viene eseguito quando viene creata una build di produzione per creare un file XML o qualcosa di simile contenente il nome e la versione del file file di ciascun file nella build. Quindi, quando ho bisogno di fare un controllo, vado sul server di produzione, afferro il file xml con le informazioni e lo confronto a livello di codice con quello che crediamo sia in produzione, e produco un rapporto.

Qualche idea migliore. So che questo deve essere già stato fatto e mi sembra folle che non ho trovato altre risorse.

Answer 1

È possibile calcolare un hash SHA1 dei file di origine sul server di produzione e confrontare tale valore di hash con le versioni archiviate nel controllo del codice sorgente. Se riesci a trovare lo stesso hash nel controllo del codice sorgente, allora sai quale versione è in produzione. Se non riesci a trovare lo stesso hash nel controllo del codice sorgente, allora ci sono modifiche non tracciate nella produzione e il tuo nuovo incarico è giustificato. :)

Answer 2

Le tipiche organizzazioni trappola che rientrano nel CMMI stanno cercando di esagerare con tutto. Se potessi suggerire qualcosa, sarebbe iniziare piccolo & amp; fai solo quello che ti serve. Quindi considera tutti i problemi che potresti aver avuto nell'area CM in modo pietoso.

Il CMMI descrive COSA dovrebbe fare un'organizzazione, ma lascia il HOW a te. La specifica CMMI , capitolo 2 vale la pena leggi - descrive i componenti richiesti, previsti e informativi della specifica - fondamentalmente sono richiesti gli obiettivi, le pratiche sono previste e tutto il resto è informativo. Ciò significa che esiste solo una piccola parte delle specifiche che un perito CMMI può richiedere direttamente: gli obiettivi. A livello di pratica, è consentito avere le pratiche descritte, o alternative accettabili .

Nel caso di audit di configurazione, l'obiettivo SG3 è "stabilito e mantenuto l'integrità delle linee di base". SP3.2 dice "Eseguire controlli di configurazione per mantenere l'integrità delle linee di base di configurazione." Non si afferma nulla sulla frequenza con cui vengono eseguiti o su quanto tempo possono impiegare.

Nella mia precedente organizzazione, FCA / PCA di solito veniva fatto solo come parte del processo di rilascio del prodotto e abbiamo usato ClearCase come strumento di controllo delle versioni, con etichette applicate attraverso la base di codice per definire le linee di base. Non avevamo i numeri di versione in tutti i file sorgente, né i numeri di versione in tutte le schermate dei prodotti: l'attività di CM stava facendo la cosa giusta & amp; è stato supportato da audit e questo non è mai stato un problema in nessuna valutazione CMMI. Potremmo usare i delta tra le etichette per vedere quali file sono stati modificati, eseguire differenze per vedere le effettive modifiche al codice. Una parte importante del processo è quella di poter ricollegare tali modifiche a un requisito / segnalazione di bug / qualunque sia il motivo che ha avviato la modifica.

Il nostro controllo ha utilizzato gli script per automatizzare il processo, ma questi erano script sviluppati internamente specifici di ClearCase - in pratica avrebbero elencato tutti i file, le loro versioni nel sistema CM e l'elemento baseline / config a cui apparteneva.

Answer 3

non puoi usare il controllo del codice sorgente per questo? se distribuisci una versione e tagghi il tuo sourcecontrol con quella distribuzione, puoi quindi verificare il sistema di controllo del codice sorgente