Quale è più importante in una gerarchia di promozione del codice di un'applicazione Web? ambiente di produzione per riprendere la somiglianza o la propagazione unidirezionale?

Se l'applicazione sta creando i propri file, separati da quelli creati dagli sviluppatori, si sta essenzialmente parlando dell'utilizzo del controllo origine dello sviluppo come sistema di backup. Non ci sono vantaggi rispetto a nessun altro tipo di sistema di backup e si consente ai file di essere modificati da persone che non capiscono il controllo del codice sorgente. Questo mi sembra pericoloso.

Questo non significa che non si dovrebbe prendere una copia di questi file ogni tanto e distribuirli a dev, solo per mantenere i sistemi sincronizzati, in modo che i test siano una riproduzione più valida della produzione. Basta non farlo attraverso il controllo del codice sorgente e il normale processo di compilazione. Se lo hai fatto, cosa succederebbe se avvii una build e poi l'applicazione modifica un file che viene poi sovrascritto dalla distribuzione?

Un'altra opzione, naturalmente, è metterli nel proprio controllo del codice sorgente e dare un controllo bidirezionale all'applicazione (in pratica, utilizzare VCS come database per l'applicazione). In questo modo puoi gestire la cronologia delle revisioni e simili senza doverli confondere con le modifiche degli sviluppatori. DVCS andrebbe bene per questo, in modo che tu possa apportare modifiche a un ambiente e poi inviarlo a un altro, magari persino un ambiente di test del contenuto in cui puoi apportare modifiche, testarle e poi inviarle sia alla produzione che all'applicazione -test environment.

Anche se i file modificati dall'applicazione sono gli stessi file modificati dagli sviluppatori, e quindi devono essere uniti, se i file sono binari e modificati spesso, dovrei pensare molto sulle conseguenze rispetto a la dimensione del mio database di controllo del codice sorgente.

Se fossero testo allora abbastanza equo ma, a meno che non fossi molto sicuro delle persone che apportano modifiche, vorrei di nuovo usare un DVCS e assicurarmi che l'applicazione si impegni su un clone del database, solo così posso tirare li invia al computer di uno sviluppatore e li controlla prima di eseguire il commit nel database di master build.

Vado con "Salva in anticipo, salva spesso". Oppure, in questo caso, "Impegnati presto, commetti spesso".

Il tuo approccio # 1 sembra ragionevole, a patto di avere la granularità giusta. In qualsiasi contesto di codifica, i check-in vengono eseguiti quando hanno senso. Potrebbe non avere senso creare sei nuove revisioni di controllo per errori di ortografia minori, nel nome della fedeltà quasi in tempo reale.

D'altra parte, il tuo approccio # 2 sembra destinato a fallire, se non altro per il fatto che contiene le parole "fiducia nei backup". [shudder] Sembra anche che si scontrino con l'istinto del decisore di mettere questi file nel controllo del codice sorgente in primo luogo.

Vorrei andare con l'opzione 2.

La separazione delle preoccupazioni mi fa pensare che le funzionalità e le funzionalità dovrebbero essere il più possibile indipendenti dal contenuto.

Anche i backup sono per il ripristino di un ambiente in uno stato di produzione, ad esempio un disco rigido ect .. Se il backup è l'ambiente di sviluppo (o anche test / staging) e qualcuno ha commesso una funzione semi-cotta .. non è possibile ripristinare il tuo ambiente di produzione.