Come gestire un singolo ramo

Naviga le tue risposte
2

Ho letto la consegna continua: rilasci di software affidabili attraverso l'automazione di compilazione, test e distribuzione di Jez Humble e David Farley . La parte che mi ha sbilanciato maggiormente è stata la loro insistenza nell'usare un singolo ramo.

Pensandoci su ciò che stanno predicando, ha senso. Ma la domanda è: come raggiungerla?.

Nella mia azienda stiamo lavorando su C # con TFS come controllo del codice sorgente. E le idee seguenti mi sono venute in mente su come ottenere l'idea di apportare modifiche che non si desidera ancora rilasciare, ma si desidera mantenere lo strumento vcs:

  • Iniezioni per poter selezionare la classe che si desidera utilizzare. Quindi puoi riscrivere alcune funzionalità senza influire sul codice che deve essere rilasciato.

  • Relativo, un contenitore IoC per rendere facile quanto sopra. Quindi puoi selezionare alla compilation (o anche al runtime) quelli che vuoi usare.

  • Motivo decoratore per aggiungere funzionalità in un modo molto semplice (che si applica solo agli altri due sopra)

In un altro simile domanda parla della linea di rilascio di Modelli di gestione della configurazione del software (che devo ancora leggere). Ma l'esempio che stanno usando riguarda i tag e la creazione di rami da essi, che non sembra essere la stessa cosa di cui parlano Humble e Farley.

  1. Le tecniche che ho descritto sembrano corrette per il raggiungimento di una singola strategia di branca?
  2. C'è qualcos'altro che potrebbe essere fatto per gestire il tuo codice su un singolo ramo?
posta Miyamoto Akira 01.04.2014 - 13:45
fonte

1 risposta

4

Più filiali di sviluppatori funzionano altrettanto bene come una singola filiale, meglio in molti casi. Potrebbe essere necessario utilizzare uno strumento migliore per il lavoro che TFS, ma ora ha git backing che dovrebbe fare bene.

Non proverei a cambiare l'architettura del software per adattarla al tuo processo di compilazione, è l'approccio sbagliato - il software è la cosa che conta, mantenerlo facilmente gestibile è molto più importante che adattarsi a qualche processo che è lì per servire il software (non viceversa)

Il trucco con i rami è quello di unirli nel bagagliaio il prima possibile, e di non ramificare il nuovo lavoro finché non sono veramente necessari. L'altra cosa da fare è quella di unire in senso inverso il tronco sulle diramazioni (cioè quando i cambiamenti dei rami vengono uniti nel tronco, gli sviluppatori che lavorano sui loro rami devono unire queste modifiche al loro ramo, quindi sono molto strettamente aggiornati) Quindi la fusione di un ramo in tronco diventa un compito banale.

Anche con un codice che siederà attorno a un non essere unito per un lungo periodo, questo è ancora ok - ciò che significa è che l'unione diventerà più difficile da realizzare col passare del tempo, ma nessuna quantità di modifiche architettoniche al tuo il codice aiuterà qui - qualcuno apporta una modifica al codice base e un anno dopo decidi che hai bisogno di quel codice ... Garantisco che non funzionerà correttamente senza l'intervento manuale e il refactoring del codice in quello che ora sembra il tronco. Quello che devi fare con questo vecchio codice è un diff di 3 vie, così puoi vedere le modifiche apportate al codice originale e applicare quelle modifiche (o le parti importanti di esse) al nuovo ramo. Pensa di portare il vecchio codice al nuovo come attività di sviluppo piuttosto che come operazione di fusione del gestore di build.

    
risposta data 01.04.2014 - 14:21
fonte

Leggi altre domande sui tag

Quali endpoint devo fornire, se esistono, per consentire il test di connettività per i miei servizi web? Come strutturare un programma in classi [chiuso]