Qual è la proposta di valore di "build, release, run"?

Penso che questo sia probabilmente meglio descritto affermando le cattive pratiche che sembra voler evitare. Ricordo i vecchi tempi in cui erano pratiche comuni. Ma con gli strumenti moderni di 'dev ops' che sono così facili da usare in questi giorni dubito che vengano visti più.

Correzioni di codice in tempo reale. (Esegui e Costruisci fasi sono uniti) Viene segnalato un bug, lo aggiusto sulla mia macchina di sviluppo, costruisco localmente e ftp la nuova dll / exe sulla scatola live. Copialo sopra la parte superiore di quello esistente. Nessun controllo per il controllo del codice sorgente. La mia casella di sviluppo è l'unico posto in cui è memorizzato il codice, se un altro sviluppatore fa lo stesso con un altro bug, il primo bug viene reintrodotto. Non è possibile eseguire il rollback

Modifiche alla configurazione live. (Esegui e rilascia gli stadi sono uniti) Vado su una scatola live e cambio manualmente la configurazione con notepad / vi e riavvia l'app e riprende le nuove impostazioni. Ancora nessuna memoria centrale della configurazione, nessun backup della vecchia configurazione, nessuna documentazione. Se la casella si interrompe, le modifiche andranno perse, se avrò più nodi finiranno tutti con configurazioni diverse.

Nessuna build centrale. (La fase di creazione non è definita) Sebbene sia utilizzato il controllo del codice sorgente, la compilazione viene eseguita localmente da qualsiasi versione che si trova in quella casella al momento. Sebbene la versione sia statica, non puoi legarla a una versione definitiva del codice. Le differenze locali, come le librerie installate e le impostazioni globali, come i percorsi e il registro, influiscono sulla versione finale. Quindi, ciò che funziona questa volta, potrebbe non funzionare la prossima volta.

Un altro relativo a nessuna build centrale

Nessuna archiviazione di versioni. (La fase di rilascio non è definita) la compilazione è completata e distribuita per la vita. Ma i file binari non sono versionati e archiviati. La domanda "quale versione è attiva" è difficile da rispondere e i rollback / re-deployment si basano sui backup delle macchine attive anziché sulla distribuzione "da zero"

Penso che quello che stai chiedendo sia spiegato (anche se non molto chiaramente) nel link che hai postato. Il bit più rilevante:

The twelve-factor app uses strict separation between the build, release, and run stages. For example, it is impossible to make changes to the code at runtime, since there is no way to propagate those changes back to the build stage.

Se apporti modifiche all'app distribuita, rendi la vita più difficile. La tua build non è più riproducibile (dato che ha dei passaggi post-build fatti in fase di esecuzione e che non vengono tracciati da nessuna parte). Potresti perdere patch e modifiche, poiché non vengono tracciati da nessuna parte. Se si desidera eseguire la distribuzione su un altro server, è necessario copiare manualmente ogni modifica apportata al primo server.

Nello scenario migliore, sei costretto a copiare manualmente ogni modifica apportata alla produzione sul tuo build di origine, che è molto soggetta a errori.