Fermare gli sviluppatori che si impegnano nel ramo sbagliato su DVCS

Il problema

Sono su un progetto software che ha circa 10 sviluppatori, condividiamo il codice sorgente tramite Mercurial. Abbiamo un ramo di sviluppo e produzione per versione. Nel corso del progetto abbiamo ripetutamente avuto il codice sorgente di un ramo, cioè v1, che entrava nei rami patch e manutenzione per le versioni precedenti del software, cioè v2.

Ciò comporta sia il tempo impiegato per il backup del commit errato, sia il codice errato (possibilmente non-QAd) che raggiunge e viene distribuito nel ramo sbagliato se non notiamo che il codice è andato nel ramo sbagliato.

La nostra filiale e uniamo il design / metodo

               v1-test   v1-patch1   v1-patch2
               ^---------^-----------^                v1-prod
              /         / \           \
-----------------------/   \           \              v1-dev
              \             \           \
               --------------------------\            v2-dev
                             \       \    \ 
                              ^-------^-------------  v2-prod
                              v2-test v2-patch1      

Quindi lavoreremo su un ramo di sviluppo delle versioni , fino a quando non sarà ritenuto pronto , diramandolo per un singolo ramo testing / UAT / Produzione, dove vengono eseguite tutte le versioni e la manutenzione. I tag vengono utilizzati per creare versioni di questo ramo. Mentre v1 è in fase di test, sarà stato creato un ramo per v2 e gli sviluppatori inizieranno a lavorare su nuove funzionalità.

Ciò che tende a succedere è che uno sviluppatore commette lavoro a causa del ramo v2-dev in v1-dev o v1-prod, o peggio, uniscono v2-dev in v1-prod (o simili errori simili).

Diciamo alla maggior parte degli sviluppatori di non accedere ai rami -prod , tuttavia il codice si insinua ancora. Un gruppo di sviluppatori più anziani si occupa del ramo -prod.

Va notato che mentre v2 ha appena iniziato lo sviluppo, potrebbero esserci ancora alcune patch piuttosto pesanti che vanno in v1 per risolvere i problemi. Vale a dire v1 potrebbe non essere solo ottenere la piccola patch dispari.

Quello che abbiamo provato finora

• Avere un ramo di prodotto separato, con gatekeeper. Un ramo -prod dovrebbe generare avvisi attraverso il suo nome e la maggior parte degli sviluppatori non deve mai trovarsi in quel ramo. Questo non ha davvero ridotto il problema.
• Aumentare la consapevolezza di questo problema tra gli sviluppatori, per cercare di renderli più vigili. Ancora una volta questo non ha avuto molto successo.

Possibili ragioni che vedo per gli sviluppatori che si impegnano nella filiale sbagliata

• Un design del ramo troppo complesso
• Avere sviluppo attivo in più rami in parallelo. (Il progetto mostra i sintomi dell'uso del modello valanghe .)
• Gli sviluppatori non comprendono abbastanza bene il DVCS

Domande che ho letto che erano in qualche modo pertinenti

Ho letto questa domanda sul non impegnarmi nel ramo sbagliato e sento che le risposte relative agli indizi visivi potrebbero essere utili. Tuttavia non sono del tutto convinto che i problemi che stiamo vivendo non siano sintomi di un problema più fondamentale.

Con gli indizi visivi, possiamo incorporarli facilmente nella riga di comando, tuttavia circa la metà del team usa eclissi che non sono sicuro di come integrare gli indizi visivi.

Domanda

Quali metodi, sotto forma di software, gestione del progetto o governance, possiamo usare per ridurre (fermare idealmente) gli impegni con il ramo sbagliato che richiede tempo o sporca il nostro codice distribuito?

Un commento specifico sui motivi che ritengo possano contribuire, come indicato sopra, sarebbe apprezzato, ma ciò non dovrebbe limitare la tua risposta.

Il problema è che stai cambiando il significato di un ramo a metà del processo.

Inizialmente, il v1 devramo è per lo sviluppo. Tutte le nuove funzionalità vanno lì. Ad un certo punto in futuro, diventa un ramo di manutenzione per il v1 releaseramo. Questo è il nocciolo 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 il ruolo di ciascun ramo e mantenerlo. Se il ruolo cambia, ramo.

Per 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 sviluppare. Se si sta creando una patch, si controlla la patch nel ramo di quella versione (o meglio ancora, si ramifica il ramo di rilascio per una patch e poi si unisce nuovamente nel ramo di rilascio).

Un articolo che dovresti leggere (ed è probabilmente un eufemismo per 'dovrebbe') è Advanced SCM Branching Strategies di Stephen Vance.

^{In questo documento, per prima cosa definisco la ramificazione in senso generale. Discuto poi varie strategie per la ramificazione, a partire dall'ovvio e passando a diverse che sono più appropriate per maggiori sforzi di sviluppo. Lungo la strada, discuto i pro e i contro di ogni strategia, usandoli per motivare i cambiamenti che compongono le strategie più complesse ...}

In questo articolo, identifica cinque ruoli che possono avere le filiali. A volte un ramo può ricoprire due ruoli e i ruoli non necessitano necessariamente di un nuovo ramo a condizione che le politiche del ruolo non cambino a metà del ramo (a volte vedrai la menzione di "ramo sulla politica incompatibile").

Questi ruoli sono:

1. Linea principale. È da qui che derivano i rami. Ramificare sempre dalla linea principale rende le fusioni più facili poiché i due rami avranno un antenato comune che non è ramo su ramo su rami.
2. Sviluppo. Qui è dove gli sviluppatori registrano 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 in un ambiente di produzione esistente.
4. L'accumulo. Quando si uniscono due filiali, si potrebbe non voler rischiare di destabilizzare la linea principale. Quindi diramare la linea principale, unire i rami nell'accumulatore e fondere nuovamente sulla linea principale una volta sistemate le cose.
5. Confezione. Confezionamento avviene un rilascio nei rami dell'imballaggio. Questo spesso diventa il rilascio e serve a isolare lo sforzo di rilascio dallo sviluppo. Vedi Come gestire i commit indesiderati che interrompono le build di versioni a lungo termine? per un esempio di dove l'imballaggio è in conflitto con lo sviluppo.

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

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

Vediamo il modello git-flow e vediamo come si applica.

Il ramo principale (blu) è il ramo di rilascio - per la codifica. Non è la linea principale. La linea principale è in realtà il ramo di sviluppo (giallo). I rami di rilascio (verde) sono il ruolo dell'imballaggio. Lo sviluppo a basso rischio avviene nella linea principale, lo sviluppo ad alto rischio avviene nei rami delle caratteristiche (rosa). In questo modello, l'accumulo viene effettuato nel ramo di sviluppo. Gli interventi di manutenzione sono considerati "hotfix" rossi.

Sebbene le politiche dei ruoli non corrispondano esattamente (ogni prodotto ha un proprio ciclo di vita leggermente diverso), sono una corrispondenza.

Ciò dovrebbe semplificare la vostra politica di ramificazione e renderla più semplice per tutti i soggetti coinvolti.

Mentre hai provato a usare un ramo -prod separato con gatekeeper, sembra che l'unico repository sia usato per eseguire effettivamente le build di produzione. Se le build di produzione fossero eseguite solo da un repository di produzione, scrivibile solo dal suo gatekeeper, gli sviluppatori non sarebbero in grado di spingerlo. Ciò comporta un carico sul gatekeeper, che dopo la revisione invierebbe il repository di produzione. Naturalmente le persone sarebbero comunque 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 la comprensione o la cura più profonde che sembrano mancare.

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

Vedi anche il commento di Sean.

È possibile che gli sviluppatori semplicemente non riescano a ottenere DVCS abbastanza bene, ma penso che sia molto più probabile che tu abbia semplicemente fatto troppo, e gli sviluppatori non possono tenere traccia di ciò che stanno facendo di momento in momento. Dimenticano in quale ramo dovrebbero lavorare e i loro cambiamenti finiscono nel posto sbagliato.

Suggerirei che hai un problema con il fatto che tutti lavorano regolarmente in tutti questi settori.

Il suggerimento di @ andy256 di un repository separato per prod sarebbe sicuramente di aiuto, ma potresti dover considerare di distribuire il lavoro in modo diverso, o magari organizzare le cose in modo che nessun sviluppatore stia lavorando su più di un ramo in una determinata settimana.

Sembra che tu abbia identificato uno dei miei principali orsi da insetto. La maggior parte degli strumenti di controllo del codice sorgente sono esattamente questi, 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, mercural ecc. Tutti offrono questo.

Quindi hai il passaggio successivo, quando è necessario stabilizzare il codice per il rilascio e si introduce la ramificazione. È qui che gli strumenti iniziano a fallire gli sviluppatori. Gli strumenti sono in grado di creare il ramo e persino di identificare le serie di modifiche che si sono accumulate sui rami dopo che sono state ramificate, ma non è questo il problema che avete subito.

Gli strumenti sono davvero scarsi nel selezionare quali modifiche devono essere copiate in altri rami e quando ciò deve avvenire. 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 sensate su quando e quali rami vengono uniti.

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

L'ambiente complesso è quello in cui si hanno più team responsabili di 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 squadra è responsabile della definizione delle proprie versioni e del controllo del cambiamento delle proprie dipendenze. Solo perché la squadra A ha rilasciato la versione 1.3, la squadra B inizia a utilizzare la versione 1.3 della squadra A solo quando la squadra B sceglie.

In effetti un team di sviluppatori definisce i gruppi di modifiche che devono essere spostate 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 davvero questo è accurev - e anche in questo caso, la maggior parte dei tuoi sviluppatori si lamenterà perché la GUI è troppo confusa per loro e non si comporta come una sovversione ...