Quando eseguire le revisioni del codice quando si esegue l'integrazione continua?

Stiamo cercando di passare a un ambiente di integrazione continua ma non siamo sicuri su quando eseguire le revisioni del codice. Da quanto ho letto sull'integrazione continua, dovremmo tentare di archiviare il codice più volte al giorno. Presumo che ciò significhi anche per funzionalità che non sono ancora complete.

Quindi la domanda è: quando eseguiamo le revisioni del codice?

Non possiamo farlo prima di archiviare il codice, perché ciò rallenterebbe il processo in cui non saremo in grado di effettuare check-in giornalieri, figuriamoci più check-in al giorno.

Inoltre, se il codice che stiamo controllando si limita a compilare ma non è completo di funzionalità, fare una revisione del codice è inutile, poiché la maggior parte delle revisioni di codice viene eseguita meglio quando la funzionalità viene finalizzata. Questo significa che dovremmo fare delle revisioni del codice quando una funzione è completata, ma quel codice non visualizzato entrerà nel repository?

IMO, è necessario rivedere il codice prima che venga pubblicato sulla mainline in modo che mainline abbia sempre e solo il codice di massima qualità.

OTOH, un buon punto potrebbe essere che "perché preoccuparsi di rivedere se l'automazione del test CI non è stata eseguita su di esso?", Quindi forse il migliore sarebbe dare a ciascuno di essi un ramo privato che il server CI costruirà e testerà per loro . In questo modo si impegnano prima e spingono lì, quindi una volta superato lo riesaminano, quindi si uniscono alla linea principale (dove eseguirà un'altra esecuzione attraverso il server CI).

Dovresti assolutamente rivedere il codice non completo di funzionalità per assicurarti che sia presente l'impalcatura per le funzionalità future, o almeno che non sia stato inserito nulla che impedisca l'implementazione di tali funzionalità future.

Inoltre, tieni presente che le revisioni del codice non devono essere lente o sincrone: uno strumento come gerrit o reviewboard o simili può renderle asincrone e abbastanza indolori.

(Informativa completa: lavoravo per SmartBear, creatori di Code Collaborator, uno strumento di revisione del codice)

Impostare la programmazione di coppia?

Tutto il codice viene esaminato mentre viene digitato senza estendere il processo o introdurre un altro passaggio.

Ecco l'estratto dell'autore della consegna continua:

Jez Humble scrive come:

Attualmente sto scrivendo un post sul blog su questo argomento. La risposta breve è questa:

• Il modo migliore per rivedere il codice è attraverso la programmazione di coppie
• È una cattiva idea chiudere l'unione alla linea principale - creando, ad esempio, un ramo separato - su un processo di revisione formale. Ciò inibisce l'integrazione continua (il modo migliore per ridurre il rischio di cambiamenti errati, che è ciò che realmente stai mirando a raggiungere).
• Penso che Gerrit sia uno strumento piacevole, ma dovrebbe essere usato dopo il check-in (è così che è stato progettato, in effetti). Parte del lavoro degli sviluppatori senior è di rivedere tutti i check-in. Potrebbero, ad esempio, iscriversi a un feed.

Riassumendo: la revisione del codice è buona. Così bene, dovremmo farlo continuamente, attraverso la programmazione di coppie e la revisione degli impegni. Se uno sviluppatore senior trova un cattivo impegno, dovrebbe accoppiarsi con la persona che lo ha commesso per aiutarli a risolvere il problema.

L'unione di gating alla mainline su una revisione formale non è buona e la creazione di filiali per farlo è molto più grave, per lo stesso motivo per cui le filiali di funzionalità non sono valide.

Grazie,

Jez.

il link originale è: https://groups.google.com/forum/#!msg/continuousdelivery/LIJ1nva9Oas/y3sAaMtibGAJ

Non so se sia il modo migliore per farlo ... ma ti spiego come lo facciamo. Uno o più sviluppatori lavorano su un determinato ramo e commettono il loro codice il più spesso possibile per evitare di perdere tempo in unione che altrimenti non sarebbe accaduto. Solo quando il codice è pronto viene inserito nella testa. Questo è per le cose impegnate e dirette.

Per quanto riguarda la revisione del codice, utilizziamo Sonar come nostro strumento di integrazione continua (e Maven / Jenkins per interagire con il sonar) per fornirci nuovi risultati dei test, copertura del codice e revisione automatica del codice ogni mattina (le build vengono eseguite di notte) in modo che gli sviluppatori possono trascorrere un massimo di un'ora ogni mattina per risolvere i loro problemi / odori di codice. Ogni sviluppatore si assume la responsabilità (anche essere orgoglioso!) Per la funzione che sta scrivendo. Questa è la revisione automatica del codice, che è grandiosa per trovare potenziali problemi tecnico / architettonici, ma ciò che è più importante è verificare se queste nuove funzionalità implementate stanno facendo ciò che l'azienda vuole che facciano correttamente.

E per questo, ci sono due cose: test di integrazione e revisione del codice peer. I test di integrazione aiutano a essere ragionevolmente sicuri che il nuovo codice non rompe il codice esistente. Per quanto riguarda la revisione del codice peer, lo facciamo venerdì pomeriggio, il che è un po 'più rilassato per farlo :-) Ogni sviluppatore è assegnato a una filiale su cui non lavora, impiega del tempo per leggere i requisiti del nuova funzionalità prima, quindi controlla cosa è stato fatto. Il suo compito più importante è assicurarsi che il nuovo codice funzioni come previsto, dati i requisiti, non infranga le nostre "regole" (utilizzare questo oggetto per quello, e non quello), sia facile da leggere e che consenta facile estensione.

Quindi abbiamo due revisioni del codice, una automatica e una "umana" e cerchiamo di evitare di inserire codice non revisionato nel ramo HEAD. Ora ... Succede a volte per vari motivi, siamo tutt'altro che perfetti, ma cerchiamo di mantenere un giusto equilibrio tra qualità e costi (tempo!)

@pjz fornisce anche una buona risposta e menziona gli strumenti di revisione del codice. Non ne ho mai usato uno, quindi non posso dire nulla al riguardo ... anche se in passato sono stato tentato di lavorare con Crucible poiché stiamo già utilizzando JIRA .

Penso che il concetto principale che aiuterà sarà quello di un'area di "stadiazione".

Sì, non vuoi controllare il codice che è rotto. Ma dovresti anche controllare frequentemente il codice. Ciò implica perfezione? ;) No. Basta usare più aree e un DVCS come git.
In questo modo si apportano modifiche (localmente) e le si impegna frequentemente mentre si testano e si sviluppano fino al completamento dei test. Quindi si passa a un'area di gestione temporanea per la revisione del codice.

Dovresti quindi passare dalla gestione temporanea ad altre attività di controllo qualità come test del browser e test utente. Finalmente puoi andare in un'area di test del volume, quindi finalmente la produzione.

Ci sono anche flussi di lavoro all'interno di questo, come tutti coloro che lavorano nel ramo principale o usano i singoli rami per tutti gli sforzi.

L'integrazione continua stessa può avvenire anche a più livelli. Può essere locale per una macchina degli sviluppatori 'fino al superamento dei test' e può anche trovarsi in aree di gestione temporanea e qa per quando il codice va a loro.

Disaccoppiare la revisione del codice e l'integrazione continua!

Perché li hai combinati?

Usiamo git flow per i nostri repository e facciamo le nostre revisioni del codice quando si tratta di unirmi nel ramo di sviluppo.

Tutto in sviluppo è completo, distribuibile e revisionato dal codice.

Abbiamo anche istituito un CI per le nostre filiali di sviluppo e master.

Penso davvero, davvero, che avresti bisogno di un DVCS (ad es. Mercurial, git) per farlo naturalmente. Con un CVCS avresti bisogno di un ramo e speri in qualunque dio tu abbia, non c'è un inferno di fusione.

Se si utilizza un DVCS, è possibile suddividere in livelli il processo di integrazione in modo che il codice lo faccia già rivedere prima che arrivi al server CI. Se non disponi di un DVCS, il codice arriverà sul tuo server CI prima di essere esaminato, a meno che i revisori del codice non riescano a rivedere il codice sul computer di ciascun sviluppatore prima che inviino le modifiche.

Un primo modo per farlo, specialmente se non si dispone di un software di gestione dei repository che può aiutare a pubblicare repository personali (ad esempio bitbucket, github, rhodecode), è avere ruoli di integrazione gerarchica. Nei seguenti diagrammi, è possibile fare in modo che i tenenti esaminino il lavoro degli sviluppatori e il dittatore come integratore principale riesamini il modo in cui i tenenti hanno unito il lavoro.

Un altro modo per farlo se si dispone di un software di gestione del repository è utilizzare un flusso di lavoro come il seguente:

Il software di gestione del repository in genere aiuta a emettere notifiche quando c'è attività nei repository (ad es. E-mail, rss) oltre a consentire richieste pull . La revisione del codice può avvenire organicamente durante le richieste pull, poiché le richieste pull in genere inducono le persone a conversare per integrare il codice. Prendi questa richiesta pull pubblica come esempio. Il gestore dell'integrazione non può effettivamente consentire al codice di arrivare al repository benedetto (noto anche come "repository centrale") se il codice deve essere corretto.

Ancora più importante, con un DVCS è ancora possibile supportare un flusso di lavoro centralizzato, non è necessario disporre di un altro flusso di lavoro fantastico se non si desidera ... ma con un DVCS è possibile separare un repository di sviluppo centrale dall'IC server e dare a qualcuno l'autorità di inviare le modifiche dal repository di sviluppo al repository CI una volta effettuata una sessione di revisione del codice .

PS: il merito delle immagini va su git-scm.com

Perché non avere più di un repository? Uno per il lavoro "quotidiano", guida un server di integrazione continua, esegue tutti i test unitari e i test di integrazione per ottenere un piacevole circuito di feedback stretto, e un altro per un lavoro "stabile", in cui gli commit sono meno frequenti, ma devono essere sottoposti a revisione.

A seconda del percorso seguito dalle modifiche mentre si muovono nel sistema, questo può finire per essere una soluzione un po 'complessa e potrebbe funzionare meglio quando si utilizzano strumenti come Git o Mercurial Queues (avvertenza: non ho usato né con rabbia) ma molte organizzazioni fanno qualcosa di simile.

Questo significa che dovremmo fare delle revisioni del codice quando una funzione è completata, ma quel codice non visualizzato entrerà nel repository?

Ben sopra è il modo in cui l'ho visto fatto in almeno tre progetti che utilizzavano intensamente l'integrazione continua e per mio ricordo ha funzionato come un fascino. Questa pratica è nota come revisione del codice post-commit : cerca nel Web questo termine se sei interessato ai dettagli.

• ^{D'altra parte, l'unico caso in cui sono stato nel progetto cercando di "sposare" le revisioni del codice pre-commit con CI si è rivelato piuttosto doloroso. Bene, quando le cose sono andate senza intoppi al 100%, è andato tutto bene, ma anche interruzioni rare (come quando i revisori principale e di backup non erano disponibili per un paio d'ore) hanno causato uno stress notevole. Ho anche notato che il morale della squadra ha sofferto un po '- c'erano un po' troppi conflitti.}

Innanzitutto, dovremmo chiarire il concetto di "integrazione continua". Nei metodi di sviluppo tradizionali, l'integrazione continua significa che possiamo integrare e costruire il nostro repository di codice sorgente ogni giorno, il che eviterà le insidie ​​dell '"inferno dell'integrazione". Le revisioni del codice sono sempre tra il periodo di codifica e il test unitario. Dobbiamo garantire che la fusione del codice con il ramo possa essere compilata senza errori. Raramente si verifica la situazione in cui parti della funzionalità si uniscono al ramo perché è difficile gestire la coerenza dell'interfaccia e compilare gli errori.

L'integrazione continua è popolare nel processo di programmazione estrema. Lo sviluppo guidato dai test aggiunge la programmazione di Pair, che è parte integrante di un processo di revisione del codice, rendendo facile l'integrazione continua. La stessa Extreme Programming è un processo continuo di revisione e integrazione del codice. Le revisioni del codice esistono ovunque.

In alcune comunità open source, le revisioni del codice vengono eseguite appena prima che il codice si unisca al ramo. Sono sempre le persone più esperte in questo team a fare le revisioni del codice e decidere se il codice può unirsi al ramo principale. In questo modo, il periodo di integrazione continua è un po 'più lungo ma la qualità del codice è leggermente migliore.

Ritorna alla domanda. Non esiste una risposta standard per quando eseguire le revisioni del codice e dipende dal processo di sviluppo originale e dall'attuazione effettiva della tua integrazione continua.