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

16

Il nostro team ha appena effettuato il passaggio da FogBugz & Forno / Mercurial a Jira & Stash / Git. Stiamo utilizzando il modello Git Flow per il branching, aggiungendo branch subtask al di fuori dei branch delle feature (relativi alle sottoattività Jira delle funzionalità di Jira). Stiamo utilizzando Stash per assegnare un revisore quando creiamo una richiesta di pull per unire nuovamente il ramo principale (di solito si sviluppano ma per le sub-attività nel ramo della funzione).

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

Abbiamo provato a tirarci tra i rami degli altri mentre ci sviluppiamo. Abbiamo anche provato a creare rami di integrazione locali che ogni sviluppatore può estrarre da più filiali per testare l'integrazione man mano che si sviluppano. Infine, e questo sembra funzionare probabilmente il meglio per noi finora, anche se con un po 'più di overhead, abbiamo provato a creare un ramo di integrazione al di fuori del ramo delle funzionalità. Quando un ramo secondario (al di fuori del ramo della funzione) è pronto per una richiesta pull e una revisione del codice, uniamo manualmente questi gruppi di modifiche in questo ramo di integrazione delle funzionalità. Quindi tutti gli sviluppatori interessati sono in grado di passare da quel ramo di integrazione ad altri rami secondari dipendenti. Ciò impedisce a chiunque di attendere qualsiasi ramo da cui dipende per passare la revisione del codice.

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

In conclusione, in questi casi ci troviamo in un approccio molto più seriale piuttosto che parallelo, a seconda di quale percorso andiamo, e vorremmo trovare un processo da usare per evitare questo.

L'ultima cosa che menzionerò è che realizziamo condividendo il codice tra le filiali che non sono state esaminate e finalizzate dal codice, ma in pratica stiamo utilizzando il codice beta di altri. In una certa misura, non penso che possiamo evitarlo e siamo disposti ad accettarlo fino a un certo punto.

    
posta fogwolf 27.05.2014 - 23:02
fonte

4 risposte

10

Il problema potrebbe risiedere in una separazione troppo rigida del compito tra lo 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 (restituendo sempre lo stesso valore per esempio) per convalidare il layout? Quindi esegui l'implementazione parziale con uno stub e in un secondo tempo uno sviluppatore back-end implementerà la funzione reale.

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

    
risposta data 28.05.2014 - 10:43
fonte
4

Il tuo problema: lo sviluppatore Un ramo dal master, i rami dello sviluppatore B dal master, entrambi lavorano su funzionalità strettamente correlate e il fatto inevitabile che le fusioni nel ramo principale siano difficili a causa di inevitabili conflitti è ciò che trattiene tutti.

Se questo è prevedibile, A e B potrebbero prima creare un ramo comune, quindi ogni ramo per il lavoro separato da questo ramo comune, unire ciascuna delle loro attività separate nel ramo comune, e ora hai un ramo libero da conflitti è molto più facile da integrare.

    
risposta data 21.07.2015 - 22:42
fonte
0

Se lo sviluppatore 1 funziona sulla funzione A e lo sviluppatore 2 ha finito di lavorare sulla funzione B che dipende dalla caratteristica A, allora non c'è modo di aggirarlo: la funzione di fusione B è in attesa. Non è possibile testarlo senza la caratteristica A, e non c'è motivo di rivederlo ancora poiché ulteriori progressi nella funzione A potrebbero portare a cambiamenti nella caratteristica 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 recensioni della funzione B quando la funzione A è completa. 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 è che cattivo (non li stai tirando fuori da "The Zone" per un compito laterale di 15 minuti)

    
risposta data 28.05.2014 - 02:12
fonte
0

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

Nel caso in cui uno sviluppatore stia aspettando una funzione di un altro sviluppatore, c'è un modo in cui una parte dei primi sviluppatori può lavorare attraverso la revisione e l'integrazione prima dell'intera funzionalità per liberare il blocco?

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

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

    
risposta data 28.05.2014 - 02:46
fonte

Leggi altre domande sui tag