Arresto degli sviluppatori che si impegnano nel ramo sbagliato su DVCS

Il problema è che stai cambiando ciò che il significato di un ramo è parte del processo.

Inizialmente, il ramo v1 dev è destinato allo sviluppo. Tutte le nuove funzionalità vanno lì. Ad un certo punto nel futuro, diventa un ramo di manutenzione per il ramo v1 release . Questo è il punto cruciale del problema.

Non è che gli sviluppatori siano sciatti, è che le autorizzazioni e i ruoli del ramo sono sciatti e soggetti a modifiche.

Quello che devi fare è stabilire quale sia il ruolo di ogni ramo e mantenere quel ruolo. Se il ruolo cambia, diramazione.

Ad esempio:

 developer
  commits    |   |  |   |    |     |   |     |
             v   v  v   v    v     v   v     v
 dev  +--+---------------------+------------------->
         |           ^    ^    |           ^    ^
         |           |    |    |           |    |
 v1      +----+------+----+    |           |    |
           prod  patches       |           |    |
                               |           |    |
                               |           |    |
 v2                            +-----+-----+----+
                                  prod  patches

In questo modello, gli sviluppatori si impegnano sempre a dev. Se si sta creando una patch, si controlla la patch nel ramo di quella release (o, meglio ancora, si dirama il ramo di rilascio per una patch e quindi la si unisce nuovamente al ramo di rilascio).

Un articolo da leggere (e probabilmente un eufemismo per "dovrebbe") è Strategie di ramificazione avanzata di SCM di Stephen Vance.

^{In this paper, I first define branching in a general sense. I then discuss various strategies for branching, starting with the obvious and moving up to several that are more appropriate for larger development efforts. Along the way, I discuss the pros and cons of each strategy, using them to motivate the changes that compose the more complex strategies...}

In questo articolo, identifica cinque ruoli che possono avere i rami. A volte una succursale può riempire due ruoli e i ruoli non hanno necessariamente bisogno di una nuova diramazione se le politiche del ruolo non cambiano a metà ramo (di tanto in tanto vedrai menzione di "ramo su criteri incompatibili").

Questi ruoli sono:

1. Mainline. Questo è da dove sono fatti i rami. Il ramificare sempre dalla linea principale rende più semplici le fusioni poiché i due rami avranno un antenato comune che non è ramo su ramo su rami.
2. Sviluppo. Qui è dove gli sviluppatori controllano il codice. Uno può avere più rami di sviluppo per isolare i cambiamenti ad alto rischio da quelli che sono di routine e banali.
3. Manutenzione. Correzioni di bug su un ambiente di produzione esistente.
4. L'accumulo. Quando si uniscono due rami, si potrebbe non voler rischiare di destabilizzare la linea principale. Quindi diramazione della linea principale, unire i rami nell'accumulatore e unirli nuovamente alla linea principale una volta che le cose sono state sistemate.
5. Packaging. Il confezionamento di un rilascio avviene nei rami della confezione. Questo spesso diventa il rilascio e serve a isolare lo sforzo di rilascio dallo sviluppo. Vedi Come comportarsi con indesiderati si impegna a interrompere i build di rilascio di lunga durata? per un esempio di dove la confezione è in conflitto con lo sviluppo.

Nel tuo esempio, hai una linea principale a cascata (questo è un problema - rende le unioni più difficili - cosa succede se vuoi unire una correzione per v1 a v2 e v3?), un ramo dev che diventa un ramo di manutenzione (cambio di politica, questo è un problema).

Ok, dici, è fantastico, ma questo è stato scritto per perforce che è un VCS centralizzato - Sto usando DVCS.

Diamo un'occhiata al modello git-flow e vediamo come si applica.

Il ramo principale (blu) è il ramo di rilascio - per il tagging. Non è la linea principale. La linea principale è in realtà il ramo di sviluppo (giallo). I rami di rilascio (verdi) sono il ruolo di imballaggio. Lo sviluppo a basso rischio avviene nella linea principale, lo sviluppo ad alto rischio si verifica nelle filiali di funzionalità (rosa). In questo modello, l'accumulo è fatto nel ramo di sviluppo. Le manutenzioni sono considerate 'hot fix' che sono rosse.

Sebbene le norme sui ruoli non corrispondano esattamente (ogni prodotto ha il suo ciclo di vita leggermente diverso), sono una corrispondenza.

Fare questo dovrebbe semplificare la tua politica di ramificazione e renderla più facile per tutti i soggetti coinvolti.

Sebbene tu abbia provato a utilizzare un ramo -prod separato con gatekeeper, sembra che l'unico repository sia utilizzato per realizzare effettivamente le build di produzione. Se le build di produzione sono state fatte solo da un repository di produzione, scrivibile solo dal suo gatekeeper, gli sviluppatori non sarebbero stati in grado di inviarlo. Questo mette un carico sul gatekeeper, che dovrebbe solo spingere al repository di produzione dopo la revisione. Naturalmente le persone sarebbero ancora in grado di estrarre dal repository di produzione quando necessario.

Man mano che le persone acquisiscono esperienza, dovrebbero essere ruotate attraverso il ruolo di gatekeeper, per ottenere una comprensione o un'assistenza più profonde che sembrano mancare.

E come regola generale, applica Occam's Razor: l'intera struttura del repository dovrebbe essere il più semplice possibile per fare il suo lavoro.

Vedi anche il commento di Sean.

È possibile che gli sviluppatori semplicemente non ottengano il DVCS abbastanza bene, ma penso che sia molto più probabile che tu abbia semplicemente avuto troppo da fare, e gli sviluppatori non possono tenere traccia di ciò che stanno facendo dal momento al momento. Dimenticano in quale ramo dovrebbero lavorare, e le loro modifiche finiscono nel posto sbagliato.

Suggerirei di avere un problema con il fatto che tutti lavorano regolarmente in tutte queste filiali.

Il suggerimento di @ andy256 di un repository separato per prod sarebbe sicuramente di aiuto, ma potrebbe essere necessario considerare la parcellizzazione del lavoro in modo diverso, o magari organizzare le cose in modo che nessun dev lavori su più di un ramo in una determinata settimana. p>     

Sembra che tu abbia identificato uno dei miei principali orsi. La maggior parte degli strumenti di controllo del codice sorgente sono esattamente questo, strumenti di controllo del codice sorgente. Consentono a un gruppo di sviluppatori di lavorare sulla stessa directory di origine, apportando modifiche e gestendo i conflitti. Ci sono stati alcuni spigoli lungo la strada, ma cvs, sovversione, git, mercurio ecc. Tutto ciò si ottiene.

Quindi hai il passo successivo, quando è necessario stabilizzare il codice per il rilascio e si introduce la ramificazione. Questo è dove gli strumenti iniziano a fallire gli sviluppatori. Gli strumenti sono in grado di creare il ramo e persino di identificare i set di modifiche che si sono accumulati sui rami dopo che sono stati ramificati, ma non è questo il problema che hai affrontato.

Gli strumenti sono davvero scarsi nel selezionare quali modifiche devono essere copiate in altri rami e quando ciò deve accadere. Git-flow tenta di risolvere questo problema creando una strategia di ramificazione che significa che quando i rami vengono uniti, le sue TUTTE le modifiche vengono unite, e quindi richiede al programmatore di fare scelte ragionevoli su quando e quali rami vengono uniti.

Su un singolo repository in cui tutti gli sviluppatori stanno lavorando su un progetto con un singolo thread di rilascio, git flow risolve il problema, ma la vita non è così semplice per molte aziende.

L'ambiente complesso è il luogo in cui più team sono responsabili per diversi aspetti della soluzione totale, eseguendo rilasci interni ad altri team. git-flow non è in grado di risolvere questo tipo di problema.

L'unico modo in cui ho visto questo lavoro è se ogni team è responsabile della definizione delle loro versioni e del controllo quando le loro dipendenze cambiano. Solo perché la squadra A ha rilasciato la versione 1.3, la squadra B inizia a utilizzare solo la versione 1.3 del team A quando la squadra B sceglie.

In effetti un team di sviluppatori definisce i gruppi di modifiche che devono essere spostati e gli sviluppatori che ricevono le modifiche definiscono quando ricevono il gruppo di modifiche.

L'unico strumento di controllo del codice sorgente che ho visto che offre veramente questo è accurev - e anche allora, la maggior parte dei tuoi sviluppatori si lamenterà perché la GUI è troppo confusa per loro, e non si comporta come sovversione ...