Integrazione / Distribuzione continua: prova su commit, richiesta pull o cosa?

3

Ho letto di CI / CD, mi è piaciuto molto, ma sto avendo problemi con i dettagli perché tutto quello che ho letto era di alto livello.

Alcuni autori sembravano suggerire che non potevano esserci commit non validi sul repository (o master branch?), quindi un programmatore che sta consegnando un codice errato verrebbe fermato e non sarebbe in grado di creare un grande pasticcio . Sarebbe costretto a riparare il suo codice in modo che i test passassero.

Altri hanno detto che il trigger sarebbero le richieste pull, non i commit. Non ho usato molto le richieste pull per essere onesto, e inoltre non sono qualcosa di estraneo al git? Non fanno parte di git AFAIK, ma fanno parte di servizi come github, bitbucket, ecc., Quindi non ero sicuro di dover legare il mio flusso di lavoro a qualcosa del genere.

Qualche idea su questo mi aiuterà molto. Per favore, menziona anche quali strumenti stai usando, ad esempio: Jenkins, Buildbot, ecc. Nessuno degli strumenti che ho provato era IMO molto amichevole. I documenti e gli esempi erano carenti o legati a determinate tecnologie come java o servizi come github. Ho anche considerato di costruire il mio, non dovrebbe essere troppo difficile ottenere la funzionalità di base. Giusto?

    
posta ChocoDeveloper 06.05.2014 - 23:30
fonte

2 risposte

6

La risposta breve è: fai ciò che funziona per la tua squadra.

In uno scenario di distribuzione continuo perfetto si potrebbe avere questo come un flusso di lavoro:

  • ogni commit (in un sistema centralizzato) o push / pull verso un particolare ramo (in un sistema decentralizzato) farebbe scattare il codice da costruire.
  • Se la build ha esito positivo, dovrebbe attivare i test unitari.
  • Se ciò riesce, dovrebbe attivare un test di integrazione.
  • Se i test di integrazione passano, dovrebbe attivare una distribuzione su un sistema di gestione temporanea
  • Se la distribuzione funziona, ciò dovrebbe innescare test di accettazione automatici
  • Se i test di accettazione passano, ciò dovrebbe innescare una distribuzione in produzione
  • Se funziona, dovrebbe attivare alcuni test automatici del fumo.

Ora, nel mondo reale, raramente funziona in questo modo. Ogni squadra ha il proprio flusso di lavoro. Potresti avere un paio di fasi per il controllo qualità e la gestione temporanea, oppure puoi distribuire direttamente da una macchina di compilazione alla produzione. Potresti richiedere una fase di test manuale o potresti richiedere test delle prestazioni, ecc.

Non c'è una risposta perfetta, tranne ciò che ha più senso per te e la tua squadra. Esegui il trigger su ogni commit, se lo desideri, o attiva solo una volta su un ramo specifico. Qual è la cosa migliore per te dipende da cosa è importante per te e che tipo di copertura di prova hai. Dipende anche da quanto tempo impiegano i test per l'esecuzione. Non devi aspettare mezz'ora prima di eseguire una riga di codice.

Tutto ciò che viene detto, come regola generale non devi spostare il tuo codice su dove influisce sugli altri finché non è stato testato.

    
risposta data 06.05.2014 - 23:37
fonte
1

Utilizziamo ruby, rails, rspec e jenkins con il seguente flusso di lavoro:

    Lo sviluppatore
  • si sviluppa in una succursale, scrive unit test ed esegue anche la suite completa di test.
  • lo sviluppatore spinge il ramo
  • qa estrae il ramo, unisce il ramo in master, risolve eventuali conflitti di merge ed esegue test
  • se i test passano, qa spinge il master aggiornato
  • git push dei master trigger ci (jenkins) per eseguire la suite completa.
risposta data 07.05.2014 - 00:08
fonte

Leggi altre domande sui tag