I file di registro in questione sono file di log delle metriche. Uno di questi è un file di progetto prodotto da SourceMonitor , a cui aggiungo regolarmente checkpoint per tracciare lo stato di avanzamento dei progetti.
I file di registro in questione sono file di log delle metriche. Uno di questi è un file di progetto prodotto da SourceMonitor , a cui aggiungo regolarmente checkpoint per tracciare lo stato di avanzamento dei progetti.
Oggigiorno lo spazio di archiviazione è economico. Se si tratta di metriche che puoi utilizzare per mostrare aumenti delle prestazioni che coincidono con le versioni, allora direi che tenerle nel controllo del codice sorgente va bene. Assicurati di archiviarle per un motivo . Se è possibile rigenerare questi file di registri / prestazioni dall'origine (ovvero posso verificare il codice, eseguirlo e produrre il file esatto che si sta per memorizzare), probabilmente non è necessario.
Al giorno d'oggi un sacco di cose sono archiviate nel controllo della versione, inclusa qualsiasi documentazione e altri file che cambiano insieme alla versione del progetto / codice.
Nota: le memorizzeresti in un ramo al di fuori del tuo ramo di codice. Come la risposta di Thomas, il ramo del codice sorgente utilizzato per costruire / distribuire l'app dovrebbe essere separato in modo che il tuo server di build (o tu, se non hai tempo / spazio) possa scaricare / checkout il codice indipendentemente da la documentazione.
Non li memorizzerei nel controllo di versione, almeno nello stesso progetto del codice sorgente per il prodotto consegnabile. Per me, non ha molto senso combinare ciò che effettivamente registra i dati in una struttura di directory per un prodotto consegnabile. Il repository utilizzato per il progetto non deve contenere nulla al di fuori di ciò che è necessario per costruire e distribuire / consegnare il sistema a portata di mano (comprese le istruzioni per la creazione e la distribuzione).
Suggerirei di archiviarli nello stesso luogo o utilizzando la stessa metodologia utilizzata per gli altri documenti, come la cronologia dei risultati del test, i documenti di progettazione, le specifiche dei requisiti e così via. Non so quale tecnologia usi, ma il caricamento su un server SharePoint funzionerebbe, così come caricherò su un server di dati condiviso e inserirò il percorso (e forse i riepiloghi) su una pagina wiki.
Non dovrei aggiungere il file di registro nel controllo di versione, sono temporanei e statici quindi non devi mantenere la versione di esso. Raccogli anche i risultati dei file di registro in un grafico, quindi non penso sia necessario aggiungere i file di registro nel controllo di versione.
IMO, no, è posto nei backup archiviati, se desideri avere quei dati in seguito. Regola generale Io uso, immagazzino solo cose che ti fai o altri, se dici, includi il codice sorgente di un altro strumento. Qualsiasi file prodotto da strumenti codegen, registri, qualsiasi altro dato di output dovrebbe essere lasciato fuori dal repository o memorizzato separatamente. Il punto è che, di solito, è possibile verificare la versione richiesta e ricreare i dati in qualsiasi momento. Sono eccezioni, suppongo, ma non li ho incontrati finora.
Ottieni il tuo server di build per raccogliere le tue metriche e archiviarle lì per ogni build.
Ci dovrebbero essere alcune cose di cui hai bisogno solo l'ultima versione di e alcune cose che ti servono in modo permanente per migliorare i grafici. Ad esempio, se si costruisce un report di copertura del codice completo per ogni build, è solo necessario consultare l'ultimo report per decidere dove concentrare gli sforzi di scrittura del test. Ma è utile mantenere la copertura del codice%, la copertura delle filiali%, ecc. Per ogni build e tracciarne il grafico.
Jenkins è ottimo per gestire questo tipo di cose. Il plug-in per editore HTML può essere pubblicato per pubblicare rapporti temporanei e attuali (oppure puoi tenere per n giorni, se hai lo spazio e bisogno), mentre il plug-in di plot può essere fatto per tracciare progressi a lungo termine.
Puoi anche memorizzarli in un database NoSQL, quindi puoi scrivere un'interfaccia per ottenere il reporting dei dati. Penso che NoSQL dovrebbe essere adatto a questo.
Sono file che cambiano nel tempo?
È utile essere in grado di recuperare versioni precedenti?
La perdita di questi file potrebbe essere un problema?
Se hai risposto "sì" a uno o più dei precedenti, quindi sicuro, vai avanti e memorizzali in un sistema di controllo della versione. Dal momento che hai risposto "sì", ovviamente c'è un certo beneficio da guadagnare e poco motivo per non farlo.
L'argomento migliore a cui posso pensare contro l'uso del controllo di versione per questi file è che i file di registro tendono ad essere lineari in natura - l'unico modo in cui normalmente li si modifica è quello di aggiungere nuovi dati alla fine del file. Dato che, hanno una sorta di meccanismo di tracciamento delle modifiche primitivo integrato, quindi la complessità aggiuntiva dell'utilizzo del controllo di versione potrebbe non essere necessaria.
È una buona idea eseguire il backup dei file di log, ma NON appartengono al controllo del codice sorgente!
I file di registro contengono spesso informazioni riservate. Gli utenti possono incollare la propria password nel campo sbagliato e farlo finire nei registri. Tutti i tipi di informazioni finiscono lì probabilmente coperti da Safe Harbor e da altre normative internazionali sulla privacy, anche se non sono altrimenti considerati privati dai vostri clienti. Vuoi limitare il numero di persone che hanno accesso a questa roba e generalmente tutti i programmatori hanno accesso al controllo del codice sorgente.
Il controllo del codice sorgente è progettato per piccoli file sorgente da 100K-5M. Non Gigabyte di junk di registrazione. A seconda dello strumento di controllo del codice sorgente che utilizzi, potresti trovarti ad aspettare per settimane solo per ottenere l'ultima versione del tuo codice se memorizzi enormi registri.
Il controllo del codice sorgente è progettato per confrontare le versioni. Non esiste un confronto delle versioni come questo con i file di registro. Se è necessario fare riferimento a questi file in modo rapido e costante, la tabella di registro in un database (SQL o NoSQL potrebbero funzionare) è la strada da percorrere. Il controllo della versione non è adatto per questo scopo.
Leggi altre domande sui tag version-control