Quando si distribuiscono gli aggiornamenti, si distribuiscono tutti gli assiemi selezionati o modificati?

Question

Quando si distribuiscono gli aggiornamenti, si distribuiscono tutti gli assiemi selezionati o modificati?

#1 da (4 voti)
#2 da (0 voti)
#3 da (0 voti)

4

Sono uno sviluppatore e ho avuto diverse esperienze nella distribuzione di applicazioni web che sono le seguenti:

Distribuisci tutti i file quindi applica i valori di configurazione appropriati per l'ambiente. Abbiamo utilizzato questo stile di implementazione per i software più grandi con lunghi cicli di sviluppo e le versioni rapide non sono necessarie o permesse a meno che non si tratti di situazioni di emergenza.
Distribuisci solo ciò che è cambiato; aggiornare manualmente i file di configurazione con la configurazione nuova o aggiornata in base all'ambiente. Abbiamo usato questo stile per le applicazioni web che tendono ad essere più agili, ad esempio la correzione e le release delle funzionalità sono quasi quotidianamente eseguite. Ho riscontrato problemi con ciò in cui non sono stati identificati tutti gli assembly dipendenti da un assembly che è stato modificato (Un valore costante era cambiato nell'assembly A e veniva utilizzata la stessa costante nell'assembly B e solo l'assembly A identificato come modificato).

Quale delle 2 è una pratica migliore (o migliore)? Sto iniziando un nuovo progetto di medie dimensioni in cui le implementazioni avverranno su base mensile e vorrei stabilire questo processo in anticipo.

deployment

posta rro 04.07.2013 - 04:43

fonte

3 risposte

Leggi altre domande sui tag deployment

Esiste una rappresentazione per mixin o tratti su UML? Quando dovremmo ripulire vecchi rami GIT non più usati? [duplicare]

score 4 · Answer 1

Mi piace distribuire tutto. Per me garantisce che sia la distribuzione che la configurazione siano completamente ripetibili e, se si utilizza questo processo per popolare gli ambienti DEV e QA, lo si verifica su base molto regolare.

Come hai visto, se si implementa solo ciò che è cambiato o il modo in cui il processo di distribuzione è stato modificato, c'è il rischio che aggiornamenti di codice e aggiustamenti della configurazione non siano sincronizzati. Ciò potrebbe rendere difficile riprodurre l'ambiente di processo esatto se necessario. (pensa ai backup falliti, ai server bloccati o semplicemente al debug di problemi complessi)

Il tuo chilometraggio può variare, ma ho usato qualche forma del metodo n. 1 per molto tempo con un buon successo.

score 0 · Answer 2

La distribuzione di tutto va bene quando il codebase è piccolo, ma non si ridimensiona man mano che diventa più grande.

Puoi ottenere il controllo al di sopra e al di là dei tuoi due punti utilizzando una pipeline di distribuzione per inviare modifiche ai diversi ambienti. La pipeline viene attivata dalle modifiche, pertanto è possibile mantenere la tracciabilità rispetto alle modifiche, mentre la distribuzione viene eseguita solo quando necessario.

score 0 · Answer 3

Dispongo tutto. È molto più sicuro, non ti costa molto e ti risparmia un sacco di mal di testa. Quando esegui il debug dei problemi su un server di test, la cosa last a cui vuoi pensare è "aggrappati a questo codice nella DLL # 3 aggiornata".

Se ci si trova in .NET land, ho riscontrato problemi in cui la distribuzione di una DLL .NET (l'unica che era stata modificata) che dipendeva da un controllo di terze parti ha smesso di funzionare. La distribuzione dell'intero lotto ha risolto tutto.