Puoi darmi un esempio del tuo processo di sviluppo per l'integrazione continua

4

Stiamo pensando di fare integrazione continua con build notturne qui. Alcuni dei nostri punti critici sono quando fare revisioni del codice. C'è qualcuno là fuori che fa l'integrazione continua con build notturne e sta facendo revisioni del codice? Se puoi dare una breve descrizione del tuo processo, sarebbe fantastico. Ad esempio, ecco cosa stiamo facendo ora:

  1. Gli sviluppatori tentano di controllare il codice ogni giorno o il più spesso possibile. Il codice non deve essere "fatto", deve solo essere compilato. Eseguono il rebase del codice con le modifiche di tutti gli altri in questo momento. Questo spesso ci impedisce di unire gli incubi.

  2. Le build escono di notte, ma QA guarda solo le build ma non scrive ancora bug, semplicemente ci informano di ciò che stanno vedendo.

  3. Ogni pochi giorni, abbiamo una versione ufficiale. Il codice è stato revisionato. Scriviamo una descrizione di cosa è pronto per il test, cosa no.

  4. Il QA scrive ciò che trova nelle cose che diciamo è pronto per il test. Il processo ricomincia.

Quindi, cosa stiamo sbagliando? Una cosa che non mi piace, è che il codice è archiviato e che non è stato revisionato. Ho sentito prima che il codice deve essere controllato solo se è stato esaminato, tuttavia, non sono sicuro di come farlo e il codice di accesso dei programmatori è ancora giornaliero. Se puoi dare esempi di ciò che è il tuo processo, lo apprezzerei davvero?

    
posta Brian Tompsett - 汤莱恩 07.01.2012 - 00:19
fonte

1 risposta

1

Al lavoro ho impostato un processo con Git e Gerrit e alcuni script di CI personalizzati. Ecco come funziona:

  • Tutto il lavoro viene svolto sui rami e unito in master più tardi.
  • Mentre gli sviluppatori lavorano, controllano le modifiche a Gerrit, dove vengono esaminate da altri. Gerrit mantiene le modifiche non verificate in un'area di attesa separata dal ramo esaminato stesso.
  • Quando un ramo è completo, viene fuso in master e quindi il merge commit viene anche inviato a Gerrit per l'approvazione.
  • Lo script autobuild crea quanto segue: (a) ramo principale, (b) tutti i rami di lavoro revisionati e (c) qualsiasi codice non rilevato in Gerrit.

Gerrit gestisce bene il processo di revisione e consente alle persone di verificare le modifiche da sottoporre a revisione in qualsiasi momento, ma non possono modificarle surrettiziamente o accidentalmente dopo la revisione.

Il nostro ambiente è un software di produzione critico in cui tutte le modifiche devono essere firmate prima dell'inclusione (ecco perché anche il commit di merge passa attraverso Gerrit). Separare la revisione delle modifiche dalla revisione del commit di unione significa che questi due passaggi possono essere eseguiti in momenti diversi. Revisionare il codice non significa necessariamente che vada in diretta.

    
risposta data 07.01.2012 - 00:47
fonte

Leggi altre domande sui tag