Evita i conflitti tra filiali e le condizioni di gara con i rami attività

Naviga le tue risposte
2

Sfondo

  • Support e Sprint sono i rami di test per bug e attività
  • Ogni bug riceve un nuovo ramo dal master, che viene unito in Support, quando viene testato correttamente, viene fatta una richiesta di pull tra il ramo Support e il master.
  • Ogni task ottiene un nuovo ramo dal master, che viene unito in Sprint, quando viene testato correttamente, viene fatta una richiesta di pull tra il ramo Sprint e il master
  • Permette di correggere qualsiasi errore dato che viene attivato in un momento preciso quando viene testato correttamente, e consente a qualsiasi attività data di essere pubblicata come e quando è pronta.
  • Consente di testare qualsiasi parte di un'attività in isolamento
  • Consente la verifica di eventuali errori isolati

problema

Se Task 123 e Task 234 modificano entrambi il metodo DoSomethingToX, ciò crea un conflitto in Sprint che deve essere risolto. Questo interromperà uno o entrambi, o nessuno dei compiti. La correzione verrà eseguita come parte dell'unione (poiché risolve un conflitto), quindi verrà impegnata in Sprint, non nell'attività 123/234.

Non voglio unire Sprint di nuovo in un'attività, perché in quel modo uniremo tutte le altre attività in corso in quell'attività e potremmo potenzialmente rendere attive queste parti delle attività

Come gestirò meglio questi conflitti?

È questo il motivo per cui la ciliegina?

C'è un modo per andare con questo tipo di architettura ed evitare questi conflitti?

Esistono standard di codifica che potrebbero aiutare a evitare questi conflitti?

(Support e Sprint sono lì solo per dare un ramo per creare build di implementazione da testare, questo è già abbastanza radicato nell'intero processo ed è improbabile che venga modificato)

    
posta bizzehdee 21.07.2015 - 22:18
fonte

1 risposta

2

Non vedo alcun processo per unire i rami RC o Master ai rami operativi (Bug ###, Task ###, ecc.)

Questo va bene, purché ogni Bug / Attività apporti modifiche minori ai rami Support / Sprint e non siano influenzati dagli altri.

Vuoi che la deriva del ramo sia bassa. Non vuoi unire altre modifiche ai rami attività / bug, il che significa che questi rami stanno per deriva deriva dai loro obiettivi.

Se più funzioni su cui si sta lavorando simultaneamente stanno cambiando lo stesso metodo in modo significativo si hanno problemi che suggeriscono anche:

  1. Il metodo è troppo complicato / grande
  2. Le tue funzionalità dovrebbero essere sviluppate in sequenza

Puoi anche lavorare per ridimensionare le tue attività in modo che siano più facili da completare rapidamente. Questo è più importante se non riesci a unire le modifiche a monte. O hai qualche tipo di comunicazione tra i tuoi team per sapere quando devono tirare queste modifiche (stand up? O qualcosa del genere?).

I do not want to merge Sprint back into a task, because that will then merge all other In Progress tasks into that task, and could potentially put those task-parts live

Questo significa anche che stai ritardando qualsiasi problema derivante da altre attività. Ad esempio, considerare Task1 e Task2 modificano entrambi il codice simile. Task1 è impegnata / testata / inviata al ramo Sprint ma Task2 richiede altri cinque giorni. Poiché non esegui mai il codice Task2 aggiornato e ti ricolleghi ad esso, quando esegui Task1 corri il rischio di interrompere lo Sprint.

How would i better manage these conflicts?

Rebase il commit da Task2 sul ramo Sprint corrente, prima di passare a Sprint.

    
risposta data 21.07.2015 - 22:36
fonte

Leggi altre domande sui tag

Accesso all'API interna tramite DMZ interno La funzione utilizza la comprensione degli elenchi python, senza stato?