7

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 èCon l'integrazione continua, perché i test vengono eseguiti dopo il commit anziché prima?

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.

+0

Questa è la domanda che la gente chiedeva MOLTO - e ora almeno Jenkins e TeamCity supportano "commit pre-testati". :-) –

risposta

3

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.

+0

Ma considera il tuo primo esempio: in un ambiente CI, la prima modifica verrà archiviata e la generazione passerà. Quindi la seconda modifica (inviata allo "stesso" orario) verrà archiviata e la compilazione fallirà. Con il test di pre-commit, le modifiche verranno accodate e la seconda modifica verrà rifiutata perché interrompe la compilazione prima di essere impegnata. Ciò consente al secondo sviluppatore di aggiornare il suo codice per lavorare con le modifiche appena trasferite e reinviare, senza mai interrompere la creazione. –

+0

Chi ha detto che è lui a rompere la costruzione? come avrebbe dovuto sapere che il primo sviluppatore ha cambiato l'interfaccia? forse è stato davvero il primo sviluppatore a rompere la build e lui dovrebbe aggiustarlo anche se i suoi check in sono passati? –

+0

E a proposito, ora pensa a 10 sviluppatori che lavorano in 3 team, ognuno dei quali afferma che sul suo computer il codice funziona correttamente. e nella macchina di compilazione la costruzione sta fallendo. Perché l'ultima povera anima che ha controllato responsabile di tutte le modifiche apportate dagli altri 9 sviluppatori? –

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.

1

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.

+0

Leggendo la mia domanda anni dopo, sento che è mal formulata , ma l'essenza della questione non è "perché non sono test eseguiti localmente prima di spingere al telecomando", ma piuttosto "perché non fa il test del server CI i cambiamenti hanno spinto al telecomando prima di essere 'fuse'". Paragonerei la tua struttura al metodo ["Not Rocket Science"] (http://graydon2.dreamwidth.org/1597.html), in cui l'unione viene eseguita manualmente anziché automaticamente. La mia domanda si concentra più su un'architettura in cui le spinte sono fatte direttamente su un repository centrale, anche se penso che sia ancora rilevante per gli altri. –