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ì:
- apportare modifiche in sede locale.
- Eseguire qualsiasi nuovo test che è stato creato.
- Conferma modifiche al ramo locale.
- Spingere le modifiche locali in remoto su GitHub e creare una richiesta di pull.
- Le modifiche di acquisizione del processo di compilazione e l'esecuzione di test di unità.
- Se i test falliscono, correggili nel ramo locale e inseriscili localmente.
- Ottieni il codice delle modifiche esaminato nella richiesta pull.
- Dopo l'approvazione e tutti i controlli sono passati, premere per eseguire il master.
- Rieseguire tutti i test di unità.
- Invia artefatto al repository.
- 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)
- Ripetere 11 finché non si è spinto attraverso tutti gli ambienti pre-produzione.
- 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.
Questa è la domanda che la gente chiedeva MOLTO - e ora almeno Jenkins e TeamCity supportano "commit pre-testati". :-) –