Crucible rispetto a Gerrit?

Question

Attualmente stiamo utilizzando Crassble di Atlassian in questo momento per le revisioni del codice (non stiamo realmente utilizzando la parte FishEye) e sta iniziando a diventare inutilizzabile, principalmente a causa di performance issues nell'indicizzazione di un repository di grandi dimensioni e più repository.

Il nostro codice è ospitato su Github e gli sviluppatori sono incoraggiati a effettuare il fork del repository e a fare tutto il loro lavoro nelle proprie forchette. Affinché funzioni con Crucible, è necessario indicizzare tutti i fork degli sviluppatori. Abbiamo iniziato a farlo, ma ci vuole molto tempo (ore per commit). Vedi il link sopra.

Come si confronta Gerrit? Indica i repository?

So che la gente commenterà come dice che Github ha richieste pull per le revisioni del codice (le usiamo) ma la richiesta pull è davvero fatta alla fine del flusso di lavoro una volta che è stata esaminata. Abbiamo un team di circa 20 persone in sviluppo e non esiste un sistema in Github per gestire le richieste/richieste di pull che devono essere completate da quale sviluppatore. Inoltre, l'integrazione con Crucible to JIRA è piacevole e ne approfittiamo.

Sono aperto anche ad altri strumenti di revisione del codice, non solo a Gerrit.

Answer 1

Ho iniziato a utilizzare Gerrit al lavoro (piccola squadra di 6, in-house, senza Github). Non ha bisogno di "indicizzare" nulla, ma Gerrit preferisce mantenere il repository "master". Quindi un nuovo sviluppatore clonerà direttamente da Gerrit.

Le modifiche apportate dagli sviluppatori vengono inviate a un refspec speciale su Gerrit, che crea un oggetto di revisione. Altri sviluppatori possono in particolare ritirare i commit per quella revisione se necessario, ma per impostazione predefinita i commit non sono disponibili su un ramo normale fino a quando la revisione non viene superata.

Esistono numerose opzioni di autorizzazioni che è possibile configurare con Gerrit, che richiede un po 'di tempo per abituarsi. È possibile configurare quali utenti possono fare quali azioni su base per ramo, se necessario.

Abbiamo un repository di grandi dimensioni (una base di codice di 20+ anni) ma con una storia di commit di circa 2 anni (migrato dal VCS precedente). Non ci sono problemi di prestazioni e, a causa del modo in cui Gerrit funziona, non mi aspetto nulla di come il repository cresce.

[non ho usato Crucible.]

Answer 2

In realtà non avere forchette separati per inviare richieste di trazione, si può avere tutti di impegnarsi in un unico repository e spingere funzionalità rami per GitHub, quindi fare clic su su Pull Request "Da 'feature-1-' a 'master'"

Answer 3

Come Greg ha detto, Gerrit presuppone che possiede i repository e non esiste un buon metodo (al momento) per usarlo in combinazione con github. Probabilmente potresti collegarlo in modo tale che una volta che il codice viene revisionato/verificato/unito in gerrit, viene spinto a github e gli sviluppatori possono ancora recuperare da lì.

Non credo che si verifichino problemi di prestazioni. Gerrit è utilizzato dalla maggior parte dei negozi Android e di altri luoghi all'interno di Google e di altre grandi aziende. Centinaia di sviluppatori spingono a migliaia di repository non è raro.

Se al momento si sta ospitando su github, sarà necessario fornire il proprio hardware, che deve essere piuttosto robusto. Gerrit userà volentieri tutta la memoria che puoi dare ... Credo che alcuni posti usino 64 GB o più di RAM, ma $ DAYJOB passa con circa 16 GB per un paio di centinaia di sviluppatori.

I rami di argomento funzionano abbastanza bene su Gerrit e stanno migliorando sempre.

Gerrit non risolverà veramente il problema relativo all'assegnazione degli sviluppatori alla revisione/verifica/unione in sé. Gli sviluppatori possono aggiungere altri sviluppatori come revisori di una modifica/commit, ma non esiste un concetto di flusso di lavoro/proprietario ufficiale. Il mio team usa Jira per questo - una volta terminato il compito, assegnare il problema di Jira a qualcuno da esaminare, quindi assegnarlo a qualcuno per verificare, ecc. Ci sono anche molte altre opzioni qui.

Sospetto che Gerrit soddisfi bene le vostre esigenze. Ti consiglio di provarlo!

Answer 4

Un'alternativa potrebbe essere ReviewBoard, che per lo più funziona piuttosto bene con git. In un precedente lavoro ho scritto uno script che utilizza ganci post-ricezione per creare automaticamente revisioni ogni volta che qualcosa viene trasferito nel repository centrale. ReviewBoard non è bello come Crucible o Gerrit, ma siamo passati ad esso da Crucible esattamente per le ragioni che stai descrivendo.

I lievi problemi con ReviewBoard e git coinvolgono principalmente alcune situazioni strane come provare a rivedere ogni commit dall'inizio del repository - ho scoperto che in genere in tali casi ho dovuto formattare me stesso e caricarlo piuttosto che lasciarlo Lo script di postreview.py di ReviewBoard lo gestisce.

Si noti che pochissimi strumenti di revisione del codice in realtà indicizzano il repository come fa Crucible. La maggior parte di essi si basa su patch, sia generati da alcuni strumenti come postreview.py, sia guardando il commit e generando la diff internamente.