Con l'integrazione continua, perché i test vengono eseguiti dopo il commit anziché prima?

Question

Mentre ho solo un repository github che sto spingendo a (da solo), spesso dimentico di eseguire test, o dimentico di impegnare tutti i file rilevanti, o di fare affidamento sugli oggetti che risiedono sul mio computer locale. Ciò si traduce in interruzioni di build, ma vengono rilevati solo da Travis-CI dopo il il commit errato. So che TeamCity ha una funzione di test pre-commit (che si basa sull'IDE in uso), ma la mia domanda riguarda l'uso corrente dell'integrazione continua rispetto a qualsiasi implementazione. La mia domanda è

Perché non sono cambiamenti testati su una macchina generazione pulita - come quelle che Travis-CI utilizza per la post-commit tesing - prima tali modifiche sono impegnati?

Tale processo vorrebbe dire che non ci sarebbe mai costruire le pause, il che significa che un ambiente fresco potrebbe tirare qualsiasi commit dal repository ed essere sicuri del suo successo; in quanto tale, non capisco perché l'IC non sia implementato usando test post-commit.

Answer 1

Il presupposto che se si scrive codice e si compila e i test vengono passati localmente, non è possibile che le build vengano interrotte. È solo così, se sei l'unico sviluppatore che lavora su quel codice. Ma diciamo che cambio l'interfaccia che stai usando, il mio codice compilerà e supererà i test finché non avrò il tuo codice aggiornato che usa la mia interfaccia. Il tuo codice compilerà e supererà i test finché non avrai il mio aggiornamento nell'interfaccia. E quando ci sia il check-nel nostro codice, esplode la macchina di costruzione ...

Quindi C'è un processo che dire essenzialmente: mettere le variazioni più presto possibile e testarli nel server CI (dovrebbe essere ovviamente compilato e testato localmente prima). Se tutti gli sviluppatori seguono queste regole, la build si interromperà, ma lo sapremo prima piuttosto che dopo.

Answer 2

Il server CI non è uguale al sistema di controllo versione. Anche il server CI controlla il codice dal repository. E quindi il codice è già stato impegnato quando viene testato sul server CI.

Test più estesi possono essere eseguiti periodicamente, piuttosto che al momento del check-in, su qualunque sia la versione corrente del codice al momento del test. Pensa ai test multi-piattaforma o ai test di carico.

In generale, naturalmente, si unità di prova il codice sul computer di sviluppo prima del check-in.

Answer 3

Premetto la mia risposta con i dettagli che io sono in esecuzione su GitHub e Jenkins.

Perché uno sviluppatore deve eseguire tutti i test localmente prima di eseguire il commit. Soprattutto nel paradigma Git che non è un requisito. Cosa succede se, ad esempio, ci vogliono 15-30 minuti per eseguire tutti i test. Vuoi davvero che i tuoi sviluppatori o te stesso stiano seduti in attesa che i test vengano eseguiti localmente prima del commit e spingere le modifiche?

Il nostro processo di solito va così:

1. apportare modifiche in sede locale.
2. Eseguire qualsiasi nuovo test che è stato creato.
3. Conferma modifiche al ramo locale.
4. Spingere le modifiche locali in remoto su GitHub e creare una richiesta di pull.
5. Le modifiche di acquisizione del processo di compilazione e l'esecuzione di test di unità.
6. Se i test falliscono, correggili nel ramo locale e inseriscili localmente.
7. Ottieni il codice delle modifiche esaminato nella richiesta pull.
8. Dopo l'approvazione e tutti i controlli sono passati, premere per eseguire il master.
9. Rieseguire tutti i test di unità.
10. Invia artefatto al repository.
11. Spingere le modifiche a un ambiente (ad es. DEV, QA) ed eseguire qualsiasi test di integrazione/funzionamento che si basi su un ambiente completo.
    • Se si dispone di una nuvola, allora si può spingere le modifiche a un nuovo nodo e solo dopo che tutti i test ambientali passare reindirizzare il VIP al nuovo nodo (s)
12. Ripetere 11 finché non si è spinto attraverso tutti gli ambienti pre-produzione.
13. Se si sta eseguendo l'implementazione continua, trasferire le modifiche fino a PROD se tutti i test, i controlli, ecc. Passano.

Il mio punto è che non è un buon uso di un tempo agli sviluppatori di eseguire test impedendo a livello locale il loro progresso quando si può off-load che lavorare su un server di Continuous Integration e ricevere notifiche di problemi che è necessario risolvere dopo. Inoltre, alcuni test semplicemente non possono essere eseguiti finché non li si commette e non si distribuisce l'artefatto in un ambiente. Se un ambiente è danneggiato perché non si dispone di un cloud e forse si dispone di un solo server, correggerlo localmente e apportare rapidamente le modifiche per stabilizzare l'ambiente.

È possibile eseguire i test localmente, se necessario, ma questo non dovrebbe essere la norma.

Per quanto riguarda il problema degli sviluppatori, i progetti open source hanno avuto a che fare con questo a lungo. Utilizzano le forcelle in GitHub per consentire ai contributori di suggerire nuove correzioni e funzionalità, ma questo non è poi così diverso da uno sviluppatore del team che crea una filiale locale, spingendolo in remoto e ottenendo il buy-in del team tramite la revisione del codice prima di premere . Se qualcuno spinge i cambiamenti che infrangono le tue modifiche, allora provi a correggerle tu stesso e poi chiedi il loro aiuto. Dovresti seguire il principio di "fusione precoce e frequente" e di unire periodicamente gli aggiornamenti dal master al tuo ramo.