Come gestisci l'integrazione del codice da più rami / sviluppatori ogni sprint?

Sono appena uscito da una chiamata retrò in cui gli sviluppatori hanno espresso preoccupazione per l'integrazione delle loro storie nel ramo principale ogni sprint. Tutti gli sviluppatori codificano tutti all'interno del proprio ramo e verso la fine dello sprint si uniscono tutti in un ramo principale.

Quindi, uno sviluppatore (di solito lo stesso) ha il compito di assicurarsi che tutto sia ben integrato con il codice di altri sviluppatori (la maggior parte delle modifiche si trovano nella stessa pagina. Ad esempio, una storia di visualizzazione dei dati, una storia di filtro dei dati e un indicatore SLA).

Come possiamo ridurre questo onere e semplificare l'unione del nostro codice? Dal mio punto di vista, se l'OP o l'SM danno priorità alle storie in modo più efficiente, quindi non abbiamo questo tipo di dipendenze nello stesso sprint, potremmo risolvere alcuni dei problemi. Come lo affrontano tutti gli altri? O è solo una parte del processo?

Se stai usando Git, ogni sviluppatore trarrebbe dal developramo nel proprio ramo di funzionalità in modo da assicurarsi che non si allontanino troppo dalla linea di base corrente. Possono farlo quotidianamente, in modo che le attività che richiedono più di un paio di giorni rimangano sincronizzate e uniscano i problemi mentre sono ancora piccoli.

Quando lo sviluppatore ha terminato il proprio lavoro, crea una richiesta pull . Una volta approvato, viene unito al developramo.

Il developramo dovrebbe sempre avere un codice funzionante ed essere pronto per il rilascio in qualsiasi momento. Quando si effettivamente fare un comunicato, si uniscono developin mastere tag esso.

Se si dispone di un buon server di integrazione continua, verrà creato ogni ramo quando vengono archiviate le modifiche, in particolare per le richieste pull. Alcuni server di compilazione si integrano con il tuo server Git per autorizzare automaticamente o disapprovare una richiesta pull se la compilazione fallisce o i test automatici falliscono. Questo è un altro modo per trovare potenziali bug di integrazione.

Ho lavorato in una squadra in cui abbiamo lottato con lo stesso problema. Abbiamo scoperto che meno tempo abbiamo trascorso prima dell'integrazione, meno è diventato difficile. So che la maggior parte delle persone che insegnano l'integrazione continua parlano di impegni ogni pochi minuti - probabilmente ci siamo impegnati circa ogni ora.

Abbiamo anche scoperto che il solo edificio non era abbastanza. Avevamo bisogno di un buon livello di copertura dei test per assicurarci di non infrangere accidentalmente il codice degli altri.

• Mantieni i tuoi rami di breve durata (sembra che tu lo stia già facendo).
• Lascia che i risultati dei test parlino da soli.
• Non aspettare la fine dello sprint.

Non è nemmeno necessario abbonarsi a TDD per questo. Tutto ciò di cui hai bisogno sono alcuni test che dimostrano che le funzionalità dei tuoi sviluppatori funzionano correttamente. Questi potrebbero includere test unitari e test di integrazione, ma idealmente saranno un paio di test end-to-end automatizzati delle caratteristiche critiche. Elementi del pacchetto di regressione standard.

Quindi, una volta completata l'unione, è possibile controllare insieme il rapporto del test di automazione e verificare che tutto sia stato integrato correttamente.

Concordo con una delle altre risposte in cui l'autore ha dichiarato che Git PRs avrebbe risolto questo problema facendo in modo che ogni sviluppatore unisse il proprio lavoro.

Un altro punto che ritengo sia abbastanza importante da lasciare fino all'ultimo paragrafo. Ti suggerisco di eseguire test manuali sulle tue build notturne, piuttosto che aspettare fino alla fine dello sprint. Gli sviluppatori dovrebbero unirsi non appena la funzionalità è completa in modo che possa essere integrata, distribuita e testata il più presto possibile.

non

A seconda della lingua e dei file che stai modificando, potrebbe non avere senso per ogni sviluppatore modificarli nel proprio ramo. Ad esempio, in C # ho scoperto che è meglio che una sola persona modifichi qualsiasi file del designer dell'interfaccia utente alla volta. Si tratta di file generati automaticamente, quindi a volte il codice viene spostato senza motivo apparente, e questo causa il caos della maggior parte degli strumenti di fusione.

Ciò significa che alcune storie potrebbero bloccare altre storie fino a quando il lavoro dell'interfaccia utente non viene completato. E / o, viene creata una nuova storia per il layout dell'interfaccia utente, mentre le altre storie implementano funzionalità. Oppure, forse uno sviluppatore fa funzionare l'intera UI mentre altri implementano le funzionalità di quella UI.

In una nota correlata, se sai che più storie toccheranno tutti gli stessi file, potresti voler evitare di lavorarci tutti contemporaneamente. Non trascinarli tutti nello stesso sprint o non iniziare a lavorarli tutti fino a quando uno o più non sono stati completati.

Un altro possibile approccio per evitare fusioni tardive e di grandi dimensioni sono i flag delle funzionalità : proteggi le tue modifiche con un flag configurabile (idealmente dinamicamente) che impedisce loro di diventare attivi prima del previsto.

Ciò consente di unire le modifiche all'inizio mastero al ramo di sviluppo congiunto senza interrompere nulla. Altri sviluppatori possono quindi ricollegare questi cambiamenti ai loro rami delle caratteristiche (o ridisporre i loro rami di conseguenza).

Come hanno già sottolineato le altre risposte, questo dovrebbe essere combinato con una soluzione di integrazione continua.

I flag delle caratteristiche offrono ulteriori vantaggi (ad esempio, semplificano l'esecuzione dei test A / B). Vedi questo articolo di Martin Fowler per maggiori informazioni.

Stiamo seguendo un approccio di ramo di sviluppo separato per ciascuna funzionalità, quindi uniamo i rami a un ramo di controllo qualità per testare in un ambiente di test di integrazione.

Una volta completati i test di regressione e integrazione, spostiamo facilmente le funzioni pronte per essere avviate nel ramo di rilascio.

Se tutto va bene, uniamo il ramo di rilascio al ramo principale.

Per dirla semplicemente, impegnarsi e fondersi spesso riduce la finestra di opportunità per unire i conflitti e ridurrà notevolmente i conflitti. L'altra parte è infatti pianificata dal responsabile, che può ulteriormente garantire che il lavoro scorra senza intoppi.

Le altre risposte forniscono alcune informazioni dettagliate sulle migliori pratiche per gli commit e semplicemente seguendo quelle probabilmente ridurrete la stragrande maggioranza dei problemi di unione. Un maggior numero di fusioni è quasi certamente una necessità, ma per un team più piccolo, il tuo approccio filiale per persona probabilmente funziona abbastanza bene. Ovviamente, non fa male (molto) entrare in pratiche più estensibili!

Tuttavia, nessuno sembra aver affrontato una delle domande più significative: cosa fare quando si toccano tutti le stesse aree di codice. È qui che è utile avere un lead che abbia familiarità con la base di codice e in grado di riconoscere le dipendenze di diverse attività. Se non orchestrano i tempi del lavoro e gli impegni, probabilmente finirai per unire i conflitti e la risoluzione riga per riga. Organizzare i compiti \ i tempi è molto più difficile con una squadra più grande, ma con una squadra piccola è possibile identificare questi compiti in conflitto. Il lead potrebbe quindi spostare tutte le attività correlate allo stesso ingegnere, per evitare del tutto il conflitto.