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

Se utilizzi Git, ogni sviluppatore estrarrà dal ramo develop nel proprio ramo della funzione in modo che si assicurino 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 siano sincronizzate e unite ai problemi vengano risolte mentre sono ancora piccole.

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

Il ramo develop deve sempre avere un codice funzionante ed essere pronto per il rilascio in qualsiasi momento. Quando realizzi una versione, unisci develop in master e taggalo.

Se hai un buon Continuous Integration Server, allora costruirà ogni ramo al momento del check-in, in particolare per le richieste pull. Alcuni server di compilazione si integrano con il server Git per approvare o disapprovare automaticamente una richiesta di pull se la compilazione fallisce o se 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 avevamo prima di integrarlo, meno difficile diventava. So che la maggior parte delle persone che insegnano l'integrazione continua parla di impegnarsi ogni pochi minuti - probabilmente ci impegniamo davvero ogni ora o giù di lì.

Abbiamo anche scoperto che solo la costruzione non era abbastanza. Avevamo bisogno di un buon livello di copertura del test per assicurarci di non aver violato 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 hai nemmeno bisogno di iscriverti a TDD per questo. Tutto ciò di cui hai bisogno sono alcuni test che dimostrano che le funzionalità degli sviluppatori funzionano correttamente. Questi potrebbero includere test unitari e test di integrazione, ma idealmente saranno un paio di test automatici end-to-end delle funzionalità critiche. Materiale del pacchetto di regressione standard.

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

Sono d'accordo con una delle altre risposte in cui l'autore ha dichiarato che Git PRs risolverebbe questo problema facendo in modo che ogni sviluppatore unisse il proprio lavoro.

Un altro punto che credo sia abbastanza importante da lasciare fino all'ultimo paragrafo. Suggerisco di eseguire test manuali sulle 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, implementata e testata il prima possibile.

Non

A seconda della tua lingua e dei file che stai modificando, potrebbe non avere senso che ogni sviluppatore li modifichi sul proprio ramo. Ad esempio, in C # ho trovato che è meglio per una sola persona modificare i file di progettazione dell'interfaccia utente alla volta. Si tratta di file generati automaticamente, pertanto il codice viene talvolta spostato senza alcun motivo apparente, e questo provoca il caos nella maggior parte degli strumenti di fusione.

Ciò significa che alcune storie potrebbero bloccare altre storie fino a quando il lavoro di interfaccia utente non è terminato. E / O, viene creata una nuova storia per il layout dell'interfaccia utente, con le altre storie che implementano funzionalità. Oppure, forse uno sviluppatore fa funzionare tutta l'interfaccia utente mentre altri implementano la funzionalità di quell'interfaccia utente.

In una nota correlata, se sai che più storie sfioreranno gli stessi file, potresti semplicemente voler evitare di lavorarci tutti allo stesso tempo. Non trascinarli tutti nello stesso sprint o non iniziare a lavorarci tutti fino a quando uno o più non sono terminati.

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

Ciò ti consente di unire le modifiche in precedenza a master o al tuo ramo di sviluppo congiunto senza rompere nulla. Altri sviluppatori possono quindi unire nuovamente queste modifiche nei loro rami di funzionalità (o rebase di conseguenza i loro rami).

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

I flag di funzionalità hanno vantaggi aggiuntivi (per esempio, rendono facile fare test A / B). Vedi questo articolo di Martin Fowler per ulteriori informazioni.

Seguiamo un approccio di ramo di sviluppo separato per ogni funzione e quindi stiamo unendo i rami a un ramo QA per il test nell'ambiente di test di integrazione.

Una volta completati i test di regressione e integrazione, spostiamo facilmente le funzionalità che sono pronte per l'uso nel ramo di rilascio.

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

Per dirla semplicemente, il commit e la fusione spesso riducono la finestra di opportunità per i conflitti di fusione e ridurranno notevolmente i conflitti. L'altra parte sta infatti pianificando il ruolo guida, che può ulteriormente garantire che il lavoro scorra liscio.

Le altre risposte forniscono alcune informazioni dettagliate sulle migliori pratiche per i commit e semplicemente seguendo quelle che probabilmente ridurrai la stragrande maggioranza dei tuoi problemi di unione. Più fusioni è quasi certamente una necessità, ma per una squadra più piccola, l'approccio per branca per persona probabilmente funziona abbastanza bene. Naturalmente, non fa molto (molto) per entrare in pratiche più estensibili!

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