Uso di gerrit (o strumento simile) in una squadra in cui più sviluppatori lavorano su una singola funzione

3

Abbiamo una squadra di circa ~ 8 sviluppatori che lavorano regolarmente sulla stessa funzione nel corso di uno sprint di 3 settimane. Non è abbastanza la programmazione delle coppie, ma nel nostro attuale flusso di lavoro gli sviluppatori inviano regolarmente un codice incompleto per il completamento di un collega. Questo ha funzionato bene prima di introdurre Gerrit, ma ora i nostri commit devono rappresentare blocchi di funzionalità di test, complete, logiche e così il modello si rompe.

La mia unica idea è di far spingere tutti fino a un ramo separato, non tracciato fino a quando la funzionalità è pronta per la revisione, quindi spacchettare tutto in commit che hanno senso e spingono verso l'alto. Esiste un altro flusso di lavoro con Gurit che potrebbe funzionare?

So che questo è un argomento ampiamente discusso su Google Gruppi e che di recente sono state discusse alcune recensioni sugli argomenti di Gerrit, ma volevo vedere se c'è qualcuno là fuori che utilizza Gerrit in questo modo e quale è il flusso di lavoro suggerito sarebbe.

    
posta Bacon 13.05.2013 - 23:41
fonte

1 risposta

2

Se vuoi condividere una modifica su Gerrit senza pubblicarla, allora il seguente flusso di lavoro potrebbe funzionare:

  • (no1) spinge la modifica in refs / per / *
  • (no2) ottieni la modifica controllandola (il comando può essere trovato nel pannello dei permessi in Gerrit)
  • (no2) modifica il codice, modificalo e spostalo indietro

Dopo aver premuto qualsiasi modifica a Gerrit, il ramo locale può essere resettato, poiché ogni modifica può essere verificata da Gerrit. Considera inoltre di mantenere aggiornato il ramo locale resettandolo:

  • git fetch
  • git reset --hard <remote_branch>

In questo modo, i commit verranno eliminati facilmente (non è possibile inserire commit di merge).

Se il team sta lavorando sulla stessa funzione, allora il commit dovrebbe essere ribadito più spesso prima del push. (Gerrit abbandona il push se il commit ha bisogno di rebase) usa git rebase -p <remote_branch>' per risolverlo.

Questo flusso di lavoro ha un solo problema: ogni push attiverà diversi lavori jenkins (speranza). Penso che ormai sia difficile dire a jenkins di non eseguire test per un particolare cambiamento. Il plugin trigger di Gerrit considera solo file e rami.

Se un trigger può esaminare prima il messaggio di commit o il nome dell'argomento, sarebbe facile forzare Jenkins a non eseguire aggiungendo tag al messaggio di commit come [WIP]. Se sei d'accordo, vota per la richiesta di funzionalità: link e controlla questo suggerimento sul modello di messaggio di commit: < a href="https://softwareengineering.stackexchange.com/a/203484/91685"> link

    
risposta data 16.09.2013 - 16:21
fonte

Leggi altre domande sui tag