Gestione della configurazione memorizzata nel database

Se ti ho ragione, hai dati per i quali potresti essere modificato dai tuoi utenti (almeno, in una certa misura), ma questi dati sono "richiesti per il corretto funzionamento del sistema" e "se diventano malformati o mancante, la funzionalità sottostante probabilmente smetterebbe di funzionare ". Ci sono alcune cose che puoi fare qui:

• proibisci ai tuoi utenti finali di manipolare tali dati. È possibile memorizzare tali dati nel database, ma il programma non offre alcuna funzionalità per modificarlo. L'unico a cui è consentito modificare tali dati è, ad esempio, un programma di installazione degli aggiornamenti fornito dall'utente quando viene distribuito un nuovo rilascio del software. Oppure, permetti al tuo utente finale di copiare quei dati e fargli manipolare la copia, ma mai la cosa originale
• consente solo ad alcuni utenti speciali (amministratori) di modificare i dati nel database (ma attenzione, anche gli amministratori possono commettere errori)
• aggiungi una funzionalità nella tua applicazione (o solo per gli amministratori) per ripristinare i dati allo stato originale a condizione che non siano corretti o mancanti
• fornisce una funzionalità per verificare se i dati sono malformati o mancanti; esegui questo controllo dopo che qualcuno ha modificato i dati e (cosa più importante): eseguilo ogni volta che il tuo programma tenta di usare quei dati
• separare le parti dei dati che possono essere tranquillamente modificate dall'utente finale in modo chiaro dalle parti che non possono (e non consentono agli utenti di modificare quest'ultima)
• cerca di rendere i tuoi aggiornamenti "intelligenti": quando fornisci una nuova versione, incluso un programma di installazione degli aggiornamenti per il tuo database, il programma di installazione dovrebbe aspettarsi la manipolazione dei dati, ad esempio nella tabella dei modelli, e agire di conseguenza

Dovrebbe essere ovvio che ognuno di questi suggerimenti può essere combinato l'uno con l'altro.

È meglio mantenere i modelli in DB per il motivo che hai elencato nella tua domanda e anche perché potresti avere un numero enorme di modelli che non devono essere caricati contemporaneamente.

Un modo semplice per legare i modelli con le versioni di app è taggarli. L'app dovrebbe avere un campo statico che indica quale versione del modello è aggiornata. Quel campo potrebbe essere un numero, stringa, data, qualunque (il numero è il migliore, è più facile cercare con DB). La tabella Modello nel DB dovrebbe anche avere una colonna per il tag dello stesso tipo. Pertanto, quando si richiede un modello, l'app può aggiungere un'altra condizione specificando il tag.

Potrebbe anche esserci un modello predefinito (il più recente, ad esempio), se la nuova versione dell'app non ha bisogno di un modello aggiornato. Oppure la nuova versione potrebbe avere lo stesso tag della precedente.

In realtà abbiamo portato importanti tabelle di configurazione sotto il controllo del codice sorgente. Stiamo utilizzando Red Gate Data Compare che funziona alla grande. Ma se è troppo costoso, è facile scrivere uno strumento personalizzato che esporta le tabelle di configurazione in un file di testo. Quei file di testo possono quindi essere versionati con il controllo del codice sorgente.

Un lavoro orario controlla se ci sono cambiamenti nel database che non sono nel controllo del codice sorgente, quindi siamo consapevoli che qualcosa cambi al di fuori del processo regolare.

Crea una tabella ::: Templet Table (Templet, ModifiedDate, Version, UserName, Published (Y / N)).

Pubblicato: leggi il templet nell'app solo quando pubblicato = Y, versione: per mantenere la versione del documento.

E crea sull'interfaccia utente dell'amministratore per gestire i templet. Mantieni il tuo codice amministratore in modo che solo un templet pubblicato dovrebbe essere lì per un templet.

Molti sistemi possono essere suddivisi altrettanto facilmente con impostazioni di configurazione sbagliate come con cattiva sorgente / logica: Config è sorgente (o almeno altrettanto importante), quindi le impostazioni di configurazione dovrebbero essere archiviate sotto controllo di versione come sorgente / logica.

È possibile utilizzare meccanismi di automazione comuni per sincronizzare i sistemi di produzione con le modifiche di configurazione e origine.

Ad esempio:

Mantieni codice e amp; config che è attualmente in produzione in una particolare area del repository. (Chiamalo "prod" e posiziona le restrizioni su chi può impegnarsi in quella posizione).

Per modificare la configurazione, apportare le modifiche e confermare i file modificati su prod. Il tuo processo di sviluppo probabilmente imporrà un certo livello di test prima che le modifiche siano effettivamente applicate a prod.

Una volta che questo accade, lascia che il tuo sistema di integrazione continui a estrarre i file da prod e, dopo aver eseguito alcuni controlli automatici, spinga la configurazione modificata al sistema di produzione attuale. Un database potrebbe essere il meccanismo utilizzato per modificare la configurazione senza riavvii.

L'importante è che l'automazione sia utilizzata per garantire che il ramo "prod" nel repository contenga il codice e la configurazione che è realmente in produzione in qualsiasi momento. (In questo modo, se qualcosa va storto, non sarai portato fuori strada da configurazioni obsolete o inconsistenti e / o file sorgente).

Per il tuo esempio particolare, sarei tentato di definire con cura la misura in cui i clienti possono personalizzare o altrimenti modificare la funzionalità del tuo sistema. La gente è diabolicamente intelligente nel trovare nuovi modi per espandere una tecnologia al di là delle intenzioni del suo creatore.