Best practice per le informazioni sulla versione?

Question

Attualmente sto lavorando per automatizzare / migliorare il processo di rilascio per l'imballaggio dell'intero prodotto del mio negozio. Attualmente il prodotto è una combinazione di:

• Base di codice lato server Java
• File XML di configurazione e applicazione
• Script shell e batch per amministratori
• Pagine HTML fornite staticamente
• e alcune altre cose, ma questo è per lo più

Tutti o la maggior parte dei quali contengono varie informazioni sulla versione, utilizzate per scopi diversi. Parte del processo di packaging della release prevede molte ricerche, grep'ing e sed'ing (negli script) per aggiornare le informazioni. Questa colla che imballa il prodotto sembra essere stata messa insieme in un modo organico, giusto in tempo, ed è piuttosto orribile da mantenere. Ad esempio, alcuni metodi Java creano oggetti Date per il momento del rilascio, gli argomenti per i quali vengono aggiornati da una sostituzione testuale, senza convalida del compilatore ... solo, urgh.

Sto cercando di evitare di fornire esempi del software effettivamente utilizzato (ad esempio CVS, SVN, formica, ecc.) perché vorrei evitare la funzione "usa xyz per fare questo" e concentrarsi maggiormente sulle pratiche generali. Vorrei dare la colpa al design scadente per il problema, ma se dovessi ricominciare, usando ancora tecnologie diverse, non sarei sicuro del modo migliore per gestire questo, oltre a stabilire convenzioni.

Le mie domande sono: esistono buone pratiche o suggerimenti e consigli per mantenere e aggiornare le informazioni sul controllo delle versioni attraverso diverse tecnologie, tipi di file, piattaforme e sistemi di controllo della versione?

Answer 1

In effetti, per completare la risposta di Craig Angus, la regola empirica qui dovrebbe essere di non includere alcuna meta-informazione nei tuoi normali file di consegna , ma per riportare quelle meta -data (numero di versione, data di rilascio e così via) in un file speciale - incluso nella versione -.

Ciò aiuta quando si utilizza uno strumento VCS (Version Control System) dallo sviluppo all'omologazione alla pre-produzione.
Ciò significa che ogni volta che carichi uno spazio di lavoro (sia per lo sviluppo, sia per il test o per preparare una versione in produzione), è lo strumento versionning che ti fornisce tutti i dettagli.

Quando prepari una consegna (un set di file impacchettati), dovresti chiedere a quel VCS tool tutte le meta-informazioni che vuoi conservare e scriverle in un file speciale incluso nel set di file.

Tale consegna deve essere impacchettata in una directory esterna (al di fuori di qualsiasi area di lavoro) e:

• copiato in una directory condivisa (o in un repository maven) se si tratta di una versione non ufficiale (ma solo un pacchetto rapido per aiutare il team della porta accanto che sta aspettando la tua consegna ). In questo modo è possibile effettuare 10 o 20 consegne al giorno, non importa: sono facilmente disponibili.

• importato nel VCS per servire come consegne ufficiali e per essere implementato facilmente poiché tutto ciò che serve è chiedere allo strumento di versioning la versione giusta della consegna giusta e puoi iniziare a distribuire esso.

Nota: ho appena descritto un processo di gestione delle versioni utilizzato principalmente per molti progetti interdipendenti. Per un singolo progetto singolo, puoi saltare l'importazione nello strumento VCS e archiviare le tue consegne altrove.

Answer 2

Crea un file delle proprietà che contiene il numero di versione e fai in modo che tutti i diversi componenti facciano riferimento al file delle proprietà

• I file Java possono fare riferimento alle proprietà tramite
• XML può usare include?
• HTML può utilizzare un JavaScript per scrivere il numero di versione dalle proprietà nell'HTML
• Gli script della shell possono essere letti nel file

Answer 3

Oltre a quelli di Craig Angus includono la versione degli strumenti utilizzati.