consegna continua: passaggio a versioni diverse [chiuso]

Dipende da dove si memorizza la configurazione.

• Puoi memorizzarlo nel controllo della versione, affiancato al tuo codice sorgente . Ciò rende la domanda di accoppiamento irrilevante, poiché la configurazione è necessariamente sincronizzata con la sorgente.

  Quando si tratta di dati sensibili, i sistemi di controllo della versione come SVN rendono possibile (e facile) definire in modo granulare chi può accedere a ciò, garantendo che solo un team che lavora al progetto possa visualizzare e modificare le chiavi private e password.

  Il problema principale che ho riscontrato con questo approccio è quando devi accedere alla configurazione da una posizione in cui non puoi accedere al controllo della versione (specialmente se non ti piace l'idea di creare account di sistema per il tuo server SVN). Ho risolto il problema con creando un prodotto che mi consente di configurare e controllare gli accessi a informazioni sensibili, ma semplicemente di fornire un accesso in sola lettura a l'SVN può essere più semplice nella maggior parte delle situazioni.

• Puoi memorizzarlo da qualche altra parte in un database MongoDB, ad esempio. In questo caso, dovrai accoppiarlo manualmente con il controllo della versione. Dato che stai parlando di consegne continue, non sono sicuro del perché parli di versioni; in tutti i casi, ogni documento all'interno del database può contenere, tra la configurazione stessa, il numero minimo di revisione. In questo modo, se hai una configurazione per le revisioni 2789, 2801, 2816 e 2817, puoi dire che una revisione 2804 dovrebbe usare la configurazione associata alla revisione 2801, non le altre tre.

  Può anche essere il contrario. È possibile che nel database sia presente un identificatore della versione di configurazione e utilizzarlo nel codice sorgente per identificare la configurazione da applicare. Questo è particolarmente utile per i sistemi di controllo delle versioni distribuite , poiché i loro numeri di revisione non sono incrementali.

  Lo svantaggio di mantenere la configurazione separata dal codice sorgente è che è molto facile dimenticare di modificare il numero di revisione / l'identificatore della versione di configurazione, introducendo bug che potrebbero essere difficili da eseguire il debug. A mio parere, l'approccio ha senso solo se la configurazione è gestita da persone diverse dagli sviluppatori, in genere amministratori di sistema. Se questo è il tuo caso, ti suggerisco di esaminare DevOps, dove gli sviluppatori sono anche responsabili della distribuzione della loro app; in questo contesto, memorizzare la configurazione insieme all'origine in un controllo di versione ha perfettamente senso.

do people generally make associations between app version and config set V->C?

how do people choose the right combination of (application version, config version/set) when roll back to some earlier version is required in any one environment?

"Le persone" non fanno cose del genere "in generale" nello sviluppo del software. Ci sono dozzine di modi in cui questo può essere implementato nel software, e il modo "giusto" dipende da un sacco di cose. Ad esempio,

• quante installazioni hai per la tua applicazione?
• ogni tipo di installazione ha una configurazione diversa?
• ogni tipo di installazione consentirà a molti utenti con diverse configurazioni?
• quale ciclo di vita ha la tua applicazione e in che modo la struttura di configurazione cambia durante l'intero ciclo di vita (è retrocompatibile o compatibile verso l'alto?)
• che tipo di infrastruttura di backup / ripristino è disponibile e le configurazioni possono essere facilmente copiate insieme all'applicazione?
• È un'applicazione di database, un'app di destinazione, un'app server, un'app per smartphone, un'app incorporata?
• possono essere installate più versioni in parallelo in un ambiente?
• Cosa succede quando una configurazione viene persa, può essere facilmente ripristinata / ricreata?

Solo per darti un esempio: MS Office è disponibile nelle versioni "2003", "2007", "2010", "2013" ecc. Puoi installarli per lo più in parallelo, ciascuna versione con una configurazione separata, per ogni utente, e probabilmente anche una configurazione specifica per macchina. Le configurazioni specifiche dell'utente sono memorizzate in cartelle diverse per versione, si potrebbero teoricamente eseguire il backup e ripristinarle individualmente (sebbene suppongo che la maggior parte degli utenti di Office non lo faccia, se la macchina fallisce, installare nuovamente il programma e ricreare manualmente la configurazione originale). Come si vede, per questo tipo di applicazione entrambi i suggerimenti di @MainMa sono completamente inadatti: non esiste né un "sistema di controllo della versione" né un database in cui la configurazione dell'utente possa essere memorizzata .

Altri programmi potrebbero funzionare in modo completamente diverso, perché se una configurazione viene persa, un sistema di produzione critico potrebbe fallire, il che potrebbe avere un serio impatto finanziario per la loro attività. Quindi devi guardare il tuo tipo di applicazione, accendere il cervello e decidere in base a quale categoria cade.