Da quello che vedo, ti riferisci a gestione della configurazione , tuttavia, se sono parti diverse del tuo sistema e vuoi metterle in controllo di versione per mantenerle coerenti, il meglio che posso pensare è:

A) Per mantenere un file (in XML, JSON o qualsiasi formato di serializzazione che ti piace) dove descrivi la versione di ogni cosa che ti serve per ciascun componente.

{
  "JAVA": ">1.7.0_05",
  "MYSQL": ">=5.0.28",
  ...
}

Chiedete a ciascun componente di importare questo file in costanti e di far valere i propri valori rispetto all'ambiente su cui sono in esecuzione, ci sono modi per ottenere queste informazioni ovunque sia distribuita l'applicazione. Se non corrispondono ai valori desiderati (o anche a intervalli di valori), lancia un avvertimento.

B) Se hai componenti diversi e usi qualcosa come Mercurial per il controllo della versione, allora tu potrebbe utilizzare qualcosa come la funzione di sottoreposizione , in cui il repository top / manager essenzialmente esegue la gestione della configurazione, questo è, il repository principale terrà traccia di quali versioni di ciascun componente vengono utilizzate in un determinato momento nel tempo. Immaginalo:

project_x #250 <- top repository at changeset 250
|--component_a #1232 <-component a at changeset 1232
|--component_b #23 <- component b at changeset 23
|--component_c #32 <- component c at changeset 32

E poi con la nuova versione di component_a (per esempio 1233) hai bisogno di una nuova versione di component_c , ma non di component_b , quindi aggiorna component_a e component_c e carica project_x in una nuova versione che registra tali modifiche

project_x #251 <- top repository at changeset 251, recording 1233 and 33 for a and c
|--component_a #1233 <-component a now at at changeset 1233
|--component_b #23 <- component b at changeset 23
|--component_c #33 <- component c now at changeset 33

Tieni presente che potrebbe non essere la migliore idea per memorizzare java o mysql nel controllo della versione, ma come accennato in precedenza, questa sarebbe una gestione della configurazione efficace per i componenti indipendenti dal progetto.

Se vuoi tenere traccia di Java, MySQL, ecc., "A)" fornisce un buon meccanismo per affermare tale configurazione.

Il repository "project_x" può avere un ramo di sviluppo e un ramo di produzione in cui tiene traccia di configurazioni di componenti differenti.

In sintesi

Avere un manifest a cui è possibile eseguire il codice e dichiarare la propria configurazione, e per i componenti indipendenti del progetto è possibile utilizzare i sotto-campi Mercurial (o i sottomoduli git) per tenere traccia della configurazione della versione tra di essi.

Risposta rapida : il modo più semplice sarebbe l'impostazione di tag / valore di build (codice dell'applicazione, versione dello schema del database, dipendenze, ecc.) nel Database o app.configuration e direttamente dalla lettura di lì quando inizia l'applicazione.

Ogni build deve avere un'etichetta pre-generata allegata alla build.

• Esempio di versioning delle applicazioni dal punto di vista VS - Versioning Controlled Build
• Esempio di processo di compilazione per il progetto Python - I sistemi di controllo e generazione della versione non vengono ridimensionati

In che modo la gestione della configurazione si differenzia dall'ambiente all'ambiente, dalla lingua alla lingua. Posso dare un esempio concreto di come vengono gestite le cose nelle distribuzioni che gestisco, dove la maggior parte del software è scritta in python.

Nel mondo Python, le singole librerie sono distribuite come uova ed elencano le loro dipendenze nei metadati del pacchetto:

  install_requires=[
      'setuptools',
      'PyRTF',
      'pisa >= 3.0.29',
      'reportlab >= 2.2',
      'html5lib == 0.11.1',
      'pyPdf == 1.12',
  ],

Nell'esempio precedente alcune versioni del pacchetto non sono bloccate, altre specificano un minimo e le ultime due sono bloccate solo alle versioni esatte. Lo strumento di distribuzione ha quindi la responsabilità di scegliere versioni in cui non è stata specificata alcuna versione esatta per soddisfare i vincoli impostati per questo uovo.

Utilizziamo buildout per gestire le nostre implementazioni; è un sistema di compilazione che usa pacchetti Python chiamati ricette per costruire software per noi. I file di configurazione consentono di includere facilmente altri file di configurazione che consentono di delegare responsabilità e specificare configurazioni diverse per diversi scenari di distribuzione con facilità.

All'interno di buildout, generalmente definiamo le versioni esatte per una versione in un elenco di versioni:

[buildout]
versions = versions

[versions]
setuptools = 0.6c11
PyRTF = 0.45
pisa = 3.0.33
# etc.

Una configurazione development.cfg potrebbe sovrascrivere versioni specifiche, cancellare i pin per gli altri o inserire un nuovo set di versioni includendo anche la configurazione per un aggiornamento della versione di framework di grandi dimensioni. Spesso usiamo un staging.cfg per distribuire le configurazioni di test al server di staging in modo che il cliente possa sottoscrivere i piani di test prima che le modifiche vengano portate in produzione.

Aiuta enormemente il fatto che framework di grandi dimensioni come Plone pubblicano elenchi di versioni per i pacchetti python che costituiscono il framework; questo ti permette di aggiornare la tua applicazione per usare una nuova versione del framework, o semplicemente di aggiornare singoli pacchetti usando un override locale.

Infine, come scopriamo le nuove versioni dei pacchetti dipende anche da chi rilascia i pacchetti; l'indice del pacchetto Python ( PyPI ) pubblica un feed RSS di nuovi pacchetti, vari progetti hanno i loro canali di notizie e per gli aggiornamenti interni usa meccanismi simili.

È importante per noi mantenere i nostri buildout ripetibili e prevedibili, quindi aggiorniamo solo i pacchetti quando abbiamo effettivamente bisogno delle modifiche nelle versioni più recenti e abbiamo testato l'aggiornamento; ma grazie alle configurazioni buildout, l'installazione di un server CI come Jenkins per varie configurazioni (produzione, staging, milestone di progetto, ecc.) è molto semplice. Finché la tua suite di test ha una buona copertura di test, puoi persino automatizzare l'estrazione di nuove versioni di pacchetti da altri team all'interno della tua organizzazione.

Usavo una pagina wiki per tenere traccia di queste cose, ma nessuno lo teneva. L'unico modo per farlo funzionare è fare in modo che la pagina esegua del codice per capire da solo le risposte. Ho iniziato con un codice php scritto da un collega, quindi ho continuato con PHP. Ma praticamente qualsiasi linguaggio che puoi eseguire su un server può funzionare.

La cosa più semplice sarebbe avere una pagina di amministrazione nella tua applicazione che elenca tutte le informazioni e poi avere una pagina di riepilogo (in un'altra app) che genera una linea per installazione. La pagina di riepilogo ottiene tutte le informazioni dalle pagine di amministrazione delle tue installazioni. L'unica cosa che devi aggiornare nella pagina di riepilogo sono gli URL delle installazioni.