Gli sviluppatori si sono bloccati aspettando che il codice si unisse da un altro ramo usando GitFlow

Il nostro team è appena passato da FogBugz & Kiln / Mercurial a Jira & Stash / Git. Stiamo usando il modello Git Flow per la ramificazione, aggiungendo i rami delle attività secondarie dai rami delle funzioni (relativi alle attività secondarie di Jira delle funzioni di Jira). Stiamo usando Stash per assegnare un revisore quando creiamo una richiesta pull per ricollegarla al ramo padre (di solito si sviluppa ma per attività secondarie nel ramo funzione).

Il problema che stiamo riscontrando è che anche con la migliore pianificazione e suddivisione dei casi di funzionalità, quando più sviluppatori lavorano insieme sulla stessa funzionalità, dicono sul front-end e sul back-end, se stanno lavorando su codice interdipendente che è in rami separati uno sviluppatore finisce per bloccare l'altro.

Abbiamo provato a metterci in contatto tra loro mentre ci sviluppiamo. Abbiamo anche provato a creare filiali di integrazione locale che ogni sviluppatore può estrarre da più filiali per testare l'integrazione mentre si sviluppano. Finalmente, e questo sembra funzionare probabilmente meglio per noi finora, anche se con un po 'più di sovraccarico, abbiamo provato a creare un ramo di integrazione al di fuori del ramo di funzionalità immediatamente. Quando un ramo delle attività secondarie (al di fuori del ramo della funzione) è pronto per una richiesta pull e la revisione del codice, uniamo anche manualmente questi set di modifiche in questo ramo dell'integrazione della funzione. Quindi tutti gli sviluppatori interessati sono in grado di estrarre da quel ramo di integrazione in altri rami di sottoattività dipendenti. Ciò impedisce a chiunque di attendere qualsiasi ramo da cui dipendono per passare la revisione del codice.

So che questo non è necessariamente un problema di Git: ha a che fare con il lavoro su codice interdipendente in più rami, mescolato con il nostro processo di lavoro e cultura. Se non avessimo la rigorosa politica di revisione del codice per lo sviluppo (vero ramo di integrazione), lo sviluppatore 1 potrebbe unirsi allo sviluppo per lo sviluppatore 2 da cui estrarre. Un'altra complicazione è che ci viene anche richiesto di fare alcuni test preliminari come parte del processo di revisione del codice prima di passare la funzionalità al QA, il che significa che anche se lo sviluppatore front-end 1 sta estraendo direttamente dal ramo dello sviluppatore back-end 2 mentre andare, se lo sviluppatore back-end 2 termina e la sua richiesta pull è in attesa di revisione per una settimana, quindi lo sviluppatore front-end 2 non può tecnicamente creare la sua richiesta pull / revisione codice perché il suo revisore codice non può test perché sviluppatore back-end 2 '

In conclusione, in questi casi ci troviamo in un approccio molto più seriale piuttosto che parallelo, a seconda del percorso da seguire e vorremmo trovare un processo da utilizzare per evitarlo.

L'ultima cosa che menzionerò è che ci rendiamo conto condividendo il codice tra i rami che non sono stati rivisti e finalizzati, ma in sostanza stiamo usando il codice beta di altri. In una certa misura non credo che possiamo evitarlo e siamo disposti ad accettarlo in una certa misura.

Il problema potrebbe anche risiedere in una separazione dei compiti troppo rigida tra sviluppo back-end e front-end.

Se uno sviluppatore front-end ha bisogno di una nuova API, non è possibile consentirgli di creare un'API fittizia sul back-end (ad esempio restituendo sempre lo stesso valore) per convalidare il layout? Quindi impegna tale implementazione parziale con uno stub e, in una seconda volta, uno sviluppatore back-end implementerà la funzionalità reale.

Interrompendo la dipendenza, otterrai un flusso migliore e non dovrai fermare tutto in attesa di una singola attività che funge da collo di bottiglia.

Il tuo problema: lo sviluppatore A delle filiali Master, lo sviluppatore B delle filiali Master, lavorano entrambi su funzionalità strettamente correlate e l'inevitabile fatto che le fusioni nella filiale Master siano difficili a causa di inevitabili conflitti è ciò che trattiene tutti.

Se ciò è prevedibile, allora A e B potrebbero prima creare un ramo comune, quindi ogni ramo per il loro lavoro separato da questo ramo comune, unire ciascuno dei loro lavori separati nel ramo comune, e ora hai un ramo libero da conflitti che è molto più facile da integrare.

Se lo sviluppatore 1 funziona sulla funzione A e lo sviluppatore 2 ha finito di lavorare sulla funzione B che dipende dalla funzione A, allora non c'è modo di aggirarla: la fusione della funzione B è in attesa. Non è possibile testarlo senza la funzione A e non ha senso rivederlo poiché ulteriori progressi nella funzione A potrebbero portare a modifiche nella funzione B.

Ciò non significa, tuttavia, che lo sviluppatore 2 sia in attesa! Lo sviluppatore 2 può iniziare a lavorare sulla funzione C e tornare al ciclo di correzione delle revisioni della funzione B una volta completata la funzione A. So che il cambio di contesto non è ottimale, ma dal momento che il tempo necessario per completare la funzione A è probabilmente misurato in giorni non è poi così male (non li stai tirando fuori da "The Zone" per un compito secondario di 15 minuti)

Una cosa che puoi fare per aiutare la situazione è dare un'occhiata ai modi per accorciare il ciclo di sviluppo.

Nel caso in cui uno sviluppatore sia in attesa di una funzionalità di un altro sviluppatore, esiste un modo in cui una parte del primo sviluppatore può eseguire la revisione e l'integrazione prima dell'intera funzionalità per liberare il blocco?

Esistono modi per suddividere le funzionalità in unità di lavoro più piccole per mantenere attivo il ciclo di integrazione?

Inoltre, quanto tempo richiede l'integrazione? Se c'è una lunga svolta su una build o integrazione, ciò può rallentare l'intera coda. Verifica se c'è qualcosa che puoi fare per accelerare i tempi di costruzione in modo che le code vengano liberate più velocemente.