Una migliore strategia di gestione dei rilasci?

Question

Lavoro per un'azienda che realizza uno strumento basato sul web. Come parte del mio lavoro, mi è stato affidato il compito di rilasciare l'ingegneria per questo prodotto (qualcosa che non avevo mai fatto prima). Ho configurato il seguente sistema usando SVN (Ci scusiamo, non possiamo usare un altro repository prima che qualcuno suggerisca di passare a GIT o perfora o una delle tante altre opzioni!)

Trunk è ciò che è nei server di produzione in tutte le volte Ci sono 2 sportelli aperti in qualsiasi momento 1) Versione di manutenzione. Questo è rilasciato ogni mercoledì 2) Sprint branch. Questo è pubblicato settimanalmente (il mercoledì con quella settimana di maint branch)

Prima del rilascio unisco le filiali della settimana nel bagagliaio.

Ho scoperto che quando si esegue svn merge, di solito crea un sacco di problemi quando si unisce. Siamo quindi passati a una riunione di unione manuale una volta alla settimana, che richiede da 10 minuti a 1 ora, dove letteralmente vinco le 2 directory sul mio sistema e chiedo a ogni sviluppatore "era questa la tua modifica? Quale versione di questo codice dovremmo conservare?"

Questo sistema non è assolutamente l'ideale.

Qualcuno può suggerire qualcosa di meglio?

Answer 1

Prima di tutto, SCUSA! Non invidio la tua posizione.

Ho lavorato per una banca internazionale effettuando riprogettazioni web per la legge sulle carte federali. Stessa situazione come te, probabilmente solo su una scala molto più ampia. Abbiamo avuto 3 persone che non hanno fatto altro che rilasciare la gestione su un programma molto simile. La cosa che lo rendeva in grado (in alcune settimane ho lavorato con un paio di centinaia di file alla volta) era il fatto che gli sviluppatori si fondevano in trunk, quindi il trunk veniva distribuito in produzione come copia .... non lo facevamo controllare direttamente nella produzione. Quindi, dal punto di vista del rilascio, potresti aiutare gli sviluppatori di corral a fare il check-in (qual è la differenza tra fare un "aggiornamento" o rispondere "è questa la versione giusta?" In realtà) Ma allora non stai scegliendo ciecamente quale gli aggiornamenti dovrebbero essere pubblicati, il che sembra un grosso problema. Certo, gli sviluppatori potrebbero lamentarsi un po ', ma essere stati in quella posizione non è poi così male. E se ti rendi disponibile per rispondere a qualsiasi domanda che potrebbe sorgere, dovrebbe essere ok. Ha funzionato per i 1.200 sviluppatori dispari che avevamo lavorato in 4 sedi in tutta la nazione.

L'altra cosa che questo ti compra è il momento di testare. Se il codice non viene unito prima di essere pubblicato, come può essere testato nel contesto del sistema più grande? Spero davvero che la risposta non sia che non è stato testato!

Answer 2

L'affermazione "ci sono 2 sportelli aperti in qualsiasi momento" mi è problematica. Almeno nella mia pratica i rami vengono creati per la stabilizzazione prima di un rilascio o per la risoluzione dei bug, e di solito sono di breve durata.

La mia domanda è: per cosa usi il baule? Non dovrebbe essere ciò che è in produzione, piuttosto la produzione dovrebbe essere in esecuzione una versione taggata (quindi rilasciata).

I problemi di unione sono autoinflitti, per quanto posso vedere.

Answer 3

La strategia di diramazione ideale per questo scenario è. Lo sviluppo più recente nel trunk e per ogni release ne taglia un ramo e lo chiama ramo di rilascio di mantenimento. Tuttavia nel tuo caso il rilascio di manutenzione avviene nel bagagliaio. L'ultimo sviluppo avviene nel ramo.

Tenere da parte la strategia di ramificazione. Ecco alcuni suggerimenti per migliorare la situazione attuale.

1. Come si dice che le modifiche relative alla produzione avvengono per prima cosa nel bagagliaio, presumo che sarebbe minima. Quindi perché non unire ogni cambiamento relativo alla produzione in queste coppie di altre filiali aperte su base frequente. Direi una volta al giorno, può anche essere più frequente o meno frequente. sarai in grado di giudicare meglio. Ciò darebbe anche migliori consigli agli sviluppatori sui cambiamenti che si verificano nella produzione, riducendo i conflitti. Inoltre, se c'è un conflitto questo sarebbe gestito dagli sviluppatori stessi sul ramo.

2. Si può pensare di venire con una sorta di quadro

   • Dovrebbe essere in grado di definire quali sono i rami che richiede i commit fatti in tronco.

   • Ci può essere uno script di post-commit hook che controllerà se il commit è in trunk e fa un svn unire subito con il branch e vedere se il loro è un conflitto.

   • Se l'unione ha esito positivo, quindi confermare le modifiche. Altrimenti invia le informazioni a te e allo sviluppatore appropriato che l'ha commesso (dipende da come vorresti affrontarle).

Answer 4

Il vostro ramo tronco dovrebbe contenere tutte le più recenti codice di sviluppo, che include nuove e non sperimentate caratteristiche e tutto il codice da altri rami. È molto importante che tutto il codice venga unito in questo ramo.

Quando si è pronti (o si pensa di essere pronti) per i test, creare un ramo stabile staccato dal ramo del tronco. Usa questo ramo per testare e correggere solo i bug. Non aggiungere nuove funzionalità o miglioramenti alla tua applicazione qui, o potrebbe destabilizzare il tuo codice esistente. Non dimenticare di unire le modifiche apportate in questo ramo nel ramo del bagagliaio.

Quando si è pronti per il rilascio (il test è completo), creare un ramo di rilascio fuori dal ramo stabile. Questo è il ramo che si rilascia in produzione e si mantiene/supporto se si riscontrano bug/problemi nella produzione. Come con il ramo stabile, non aggiungere nulla di nuovo a questo ramo. Questo ramo viene solitamente taggato per identificarlo in produzione. Non dimenticare di unire le modifiche apportate in questo ramo al ramo stabile, in modo che gli altri rami di rilascio creati dal ramo stabile ottengano il vantaggio di eventuali correzioni di bug apportate.

La gerarchia ramo sarà simile alla seguente:

trunk 
|-- stable 1.0 
    |-- release 1.0 
    |-- release 1.1 
|-- stable 2.0 
    |-- release 2.0 

Utilizzando questa gerarchia, il team di sviluppo è libero di sviluppare nel vostro ramo tronco, mentre la stalla e rilasciare rami permettono di mantenere le versioni attuali e precedenti di la tua applicazione.