Esiste una best practice consolidata o definita per il branching del controllo del codice sorgente tra lo sviluppo e i build di produzione?

Question

Esiste una best practice consolidata o definita per il branching del controllo del codice sorgente tra lo sviluppo e i build di produzione?

#1 da (2 voti)

6

Ho faticato su come esprimere la mia domanda, quindi lasciatemi fare un esempio nella speranza di rendere più chiaro ciò che sto cercando:

Attualmente lavoro su un team di sviluppo responsabile della gestione e aggiunta di funzionalità a un'applicazione Web. Abbiamo un server di sviluppo e usiamo il controllo del codice sorgente (TFS). Ogni giorno tutti controllano il loro codice e quando il codice (in esecuzione sul server di sviluppo) passa il nostro programma QA / QC, va in produzione.

Recentemente, tuttavia, abbiamo riscontrato un bug nella produzione che richiedeva una correzione immediata della produzione. Il problema era che molti di noi sviluppatori avevano il codice controllato che non era pronto per la produzione, quindi dovevamo completare rapidamente e QA il codice, o ripristinare tutto, annullare le modifiche in sospeso, ecc. parole, era un casino.

Questo mi ha fatto meravigliare: esiste un modello di progettazione stabilito che previene questo tipo di scenario. Sembra che ci debba essere una risposta "da manuale" a questo, ma non sono sicuro di quale sarebbe. Forse un ramo di sviluppo del codice e un "release-ready" o ramo di produzione del codice?

testing version-control branching architecture web-applications

posta Matt Cashatt 22.10.2013 - 18:57

fonte

1 risposta

Leggi altre domande sui tag testing version-control branching architecture web-applications

"Tutto il software ha una data di scadenza entro la quale deve essere riscritto da zero." [chiuso] Architettura del sottosotto rispetto alla teoria del controllo percettivo

score 2 · Answer 1

Nella mia organizzazione, etichettiamo sempre ogni distribuzione di produzione nel repository. Poiché utilizziamo SVN, questo tag può diventare un ramo, se necessario, semplicemente applicando le modifiche ad esso. Questo è esattamente ciò che facciamo se c'è un bug nella produzione che ha bisogno di una correzione immediata. In tale situazione, eseguiamo il check-out di una copia pulita di quella particolare revisione (la versione di produzione) su una delle workstation degli sviluppatori, eseguiamo la correzione, eseguiamo tutti i test e, se tutto va bene, distribuiamo l'applicazione. Quindi riportiamo le modifiche al repository trasformando il tag di produzione in un ramo. Questo commit diventa l'ultimo tag di produzione.

Una volta risolta l'emergenza, uniamo la correzione alla linea principale e uccidiamo il ramo di produzione. Il ramo di produzione diventa nuovamente un tag di produzione regolare. Può diventare un ramo solo se una tale emergenza si ripresenta.

Non sono sicuro di quanto sarebbe facile ottenere lo stesso usando TFS, ma la lezione importante qui è che hai bisogno di una revisione stabile da distribuire alla produzione. Le attuali revisioni di produzione sono stabili per definizione, quindi è sufficiente taggarle per poterle lavorare quando si verifica un'emergenza. È inoltre importante poter configurare facilmente copie di lavoro pulite da eventuali revisioni nel repository di origine.

Ciò che è importante sottolineare è che non devi mai distribuire il codice che non è pronto per la produzione. Nel caso che hai descritto, dovresti lavorare sulla versione attualmente in produzione per risolvere solo il problema specifico che ha creato l'emergenza, e non usare il codice che si trova nelle copie di lavoro correnti dello sviluppatore.

Infine, per rispondere alla tua domanda, il modello di configurazione del software principale che penso tu debba seguire, che è la base del metodo che ho descritto sopra, è chiamato Release Line , seguendo il grande libro di Stephen Berczuk intitolato Modelli di gestione della configurazione del software .

Modifica: dovrei anche dare il giusto credito a Marjan Venema che ha menzionato un approccio simile in un commento che non avevo letto fino ad ora.