Introduzione di una politica di diramazione del controllo della versione a un piccolo team

Per un team di 3-4 sviluppatori, stai proponendo troppe filiali.

Ogni ramo che crei è un overhead aggiuntivo che viene fornito con un costo (tempo trascorso a unire, tenere traccia di cosa è dove, ecc.). È necessario assicurarsi che il vantaggio derivante dall'avere un ramo superi il costo.

Ricorda che l'unico vero vantaggio per un ramo è l'isolamento del codice. Ciò significa che hai bisogno di un motivo concreto per voler avere il codice isolato.

Avere un ramo di rilascio separato per lo sprint ogni è folle. Perché hai bisogno del codice da uno sprint isolato dal codice per il prossimo? Perché non avere un singolo ramo di rilascio stabile che viene portato avanti con ogni sprint?

If a change is estimated to take more than a week then it should be done on a branch, with regular merges from the trunk into the branch to stop the two going out of sync.

Quasi tutte le nuove funzionalità non banali impiegano almeno una settimana in tempo reale dopo aver tenuto conto dello sviluppo, dei test degli sviluppatori, delle interruzioni giornaliere e di altre attività, ecc.

Inoltre, cos'è una "unione regolare"? Quotidiano? Settimanalmente? Ogni unione che fai richiede tempo: devi assicurarti che il target unisca le build del ramo & corre dietro alle tue modifiche. In una piccola squadra, la fusione frequente è molto onerosa.

Abbiamo un team di 4 sviluppatori che lavorano su una base di codice di oltre 1 milione di linee e questo è il modo in cui operiamo:

• Ramo principale in cui viene eseguito tutto lo sviluppo
• Un ramo per versione principale (fatto circa una volta all'anno)

L'unica regola principale è: non controllare il codice che non genera.

Questo è tutto. Semplice, facile da capire, ottiene l'isolamento di cui abbiamo bisogno (in qualsiasi momento possiamo creare una versione di rilascio per qualsiasi versione).

Il vantaggio di avere tutto il lavoro di sviluppo svolto su un ramo:

1. Gli sviluppatori sono sempre sincronizzati l'uno con l'altro. Nessuna fusione dolorosa perché due sviluppatori sono rimasti fuori per le proprie filiali per settimane creando modifiche incompatibili.
2. Le build rotte vengono trovate nello stesso giorno. Abbiamo una build notturna che esegue l'ultimo codice su main. Se qualcuno controlla il codice che non viene generato per qualche motivo, lo sapremo subito.
3. Con tutti che lavorano sempre sullo stesso codice, aumentano le possibilità che un bug venga trovato prima piuttosto che dopo.
4. Nessun overhead di integrazione oltre alle correzioni mirate per rilasciare i rami. In una piccola squadra, questo è il grande.

Hai scritto alcune indicazioni per loro, ma non hai spiegato perché il tuo approccio migliore di quello che già usano . Questo potrebbe essere problematico. Se sei in uno spirito "Lo faremo a modo mio, perché ho sei anni di esperienza professionale, e tu no" (e leggendo la tua domanda, sembra esattamente in questo modo), sii pronto ad essere odiato da i membri del tuo team che cercheranno di fare tutto il possibile per applicare i tuoi concetti.

Hanno un problema che deve essere risolto? È fondamentale rispondere a questa domanda prima, perché in realtà hanno un problema e accolgono con favore i tuoi suggerimenti, oppure funzionano perfettamente come attualmente lo fanno, e tu stai solo spingendo verso di loro il tuo modo di lavorare , solo perché preferisci lavorare in questo modo.

Alla fine, forzandoli a utilizzare le filiali può avere un impatto estremamente negativo . Lavorare con un tronco è facile, specialmente in ambiente Agile. Uno sviluppatore commette modifiche al trunk, eventualmente gestendo piccoli conflitti e tali modifiche vengono immediatamente utilizzate dalla piattaforma di integrazione continua. Con rami:

• Uno sviluppatore deve pensare dove dovrebbe essere collocata la modifica,

• Qualcuno deve gestire i rami e fondersi dai rami al tronco,

• Le fusioni tra i rami vengono eseguite meno frequentemente rispetto ai commit, il che significa che qualcuno deve affrontare conflitti più grandi e più difficili da gestire rispetto a un conflitto tra due commit,

• Ogni commit non trova necessariamente la sua strada in Continuous Integration, che ritarda le informazioni che gli sviluppatori hanno sugli effetti che un commit può avere (specialmente regressioni).

Il fatto che:

The existing team are not familiar with branching

rende le cose ancora peggiori. Ho lavorato in un team di programmatori inesperti, in cui un manager inesperto ha deciso di giocare con le filiali. Ciò ha comportato un sacco ( molto ) di tempo sprecato ed è esattamente la cosa che vuoi evitare per un progetto che ha scadenze.

Come dice Mainma, fai attenzione alla ramificazione. Hai parlato di branching ogni poche settimane, è davvero necessario avere molti rami?

In alternativa, potresti anche avere un modello 'pull' invece di un modello push. Se si stesse utilizzando Git o Mercurial, è possibile che un server di integrazione convalidi le proprie modifiche prima di inviare al server centrale. In TFS, puoi fare qualcosa di simile usando check-in con gating . In questo modo, puoi avere la convalida ed evitare la complessità dei rami.