Installazione di sviluppo per TDD. È corretto?

Installare un CI (Jenkins nel tuo caso) su ogni singola workstation sarebbe eccessivo. Questa cosa è piuttosto pesante! La pratica comune è quella di averlo solo su un server e farlo verificare le modifiche (commit) nel repository ogni X minuti (quindi crea automaticamente) - oppure puoi creare un hook post-unione nel tuo VCS per attivare una build.

Che cosa intendi testando gli strumenti? Ogni sviluppatore dovrebbe essere in grado di eseguire test di unità / integrazione dal proprio ambiente, se questo è ciò che si sta chiedendo. In effetti, è una buona pratica eseguire i test prima di eseguire il commit (so che l'elemento della configurazione è lì per controllarlo ovunque, ma comunque preferisco non danneggiare le build).

Il setup di tutte le aziende che ho lavorato era abbastanza simile:

1. ognuno ha il proprio dev env locale in cui può eseguire test di unità / integrazione se vuole
2. c'è ovviamente un repository VCS comune in cui tutti ci impegniamo
3. c'è un elemento della configurazione in un server che esegue il polling dei nuovi commit dal repo VCS e, se ne trova uno, avvia un lavoro di CI che costruisce l'intero progetto controllando eventuali errori (build o test).
4. abbiamo avuto una compilazione notturna per ogni progetto che creava l'applicazione dalle ultime fonti dal repository e la distribuiva sul server nel mezzo della notte quando nessuno la utilizzava.

Puoi andare ancora oltre e provare ad adottare la distribuzione continua. Non abbiamo questo al mio attuale lavoro, dal momento che le procedure di distribuzione dell'applicazione sono molto simili a società.

Belle cose da avere:

• mail in arrivo dopo ogni build (dicendo che è riuscita o fallito, invia sempre una mail, se non vuoi mandarne uno dopo un costruire con successo è un errore dato che non sai se la build è stato attivato o meno)
• una schermata visibile a tutti / molti sviluppatori si posiziona con lo stato corrente di tutte le tue build

Non dovresti aver bisogno dell'intero stack per ogni sviluppatore. Avere localmente un server Jenkins sarebbe eccessivo e non è necessario.

Meglio invece avere un sistema come server di build, che esegue uno script di compilazione di uso comune e occuparsi di tutte le operazioni di distribuzione disordinate che non si desidera vengano eseguite ad-hoc su ciascuna workstation.

Ogni programmatore ha il proprio ambiente di sviluppo, la suite completa di strumenti di test e API necessari e può eseguire lo script di compilazione in locale. Ciò consente a tutte le build di funzionare allo stesso modo e di consentire attraverso il processo di integrazione continua per determinare se le loro modifiche potrebbero interrompere la compilazione. Abbiamo un impegno in cui lavoro per assicurarmi che quando il nostro codice viene spostato nel sistema di controllo della versione, che non debba rompere la build, così la costruzione locale ci consente di cogliere eventuali problemi sciocchi che potrebbero lasciare la build in un apparentemente permanente rotto stato.

Una volta verificato il codice, il sistema di generazione conferma che il codice sorgente è cambiato e avvia automaticamente un processo di compilazione. Se la build funziona sul mio PC, ma si interrompe sul sistema di build, di solito è perché o ho dimenticato di controllare qualcosa, o perché un altro sviluppatore ha cambiato qualcosa nel frattempo che potrebbe aver influenzato il modo in cui il mio codice viene eseguito ... anche se questo di solito accade perché avrei dimenticato di aggiornare la mia base di codice prima della mia compilazione, che (sì lo so) dovrebbe probabilmente accadere automaticamente all'inizio dell'esecuzione dello script di build locale.

Se stai facendo veramente TDD, gli sviluppatori stanno scrivendo ed eseguendo test localmente, quindi hai sicuramente bisogno degli strumenti di test su ogni sviluppatore.

La nostra configurazione:

Ogni sviluppatore ha un proprio server di sviluppo (vm)

• così tutti gli sviluppatori possono svilupparsi sulla stessa versione dello stesso sistema operativo, con lo stesso set di pacchetti di sistema installati
• quindi non esiste una piattaforma dif condivisa per assicurarsi che gli aggiornamenti di sistema o gli aggiornamenti del toolchain non abbiano impatto su tutti finché non sono stati controllati.
• per supportare vmi di sviluppo omogeneo, ma strumenti di sviluppo eterogenei (qualunque sia lo strumento di sviluppo che rende ogni sviluppatore più produttivo)
• che si trova sulla stessa rete protetta (accessibile solo tramite autenticazione VPN / 2 fattori) come i grandi sistemi (condivisi) che integriamo con
• essere sulla stessa versione del sistema operativo e configurazione della piattaforma in cui verrà distribuito il software in produzione

Ogni sviluppatore fa TDD, ma scrive test di accettazione automatici, non test di unità

• assicura il test dei punti di integrazione
• scambia alcune garanzie sulla correttezza dei componenti per la correttezza complessiva del sistema
• richiede meno tempo per eseguire refacters di grandi dimensioni perché non paghiamo gli aggiornamenti di test sui refactor

Ogni sviluppatore ha una toolchain e il codebase. La suite di test fa parte del codebase.

• per ridurre i vettori di bug assicurando che tutti stiano lavorando con le stesse versioni

Il server CI è creato allo stesso modo di un server di sviluppo, con lo stesso ambiente di sviluppo. Funziona con ogni commit, esegue test, codifica il codice e produce pacchetti installabili

• per assicurare che la suite di test venga eseguita su ogni commit
• per assicurare che ogni build di successo sia taggata e pacchettizzata dal momento che è considerata un RC
• per assicurare che tutti gli RC siano costruiti esattamente allo stesso modo ogni volta
• per assicurare che i pacchetti vengano creati allo stesso modo ogni volta

I pacchetti sono installati in QA per test più estesi

• i nostri test riducono significativamente, ma non eliminano completamente la necessità di test manuali

Gli stessi pacchetti che passano QA sono installati in Production

• per ridurre i vettori di bug utilizzando gli stessi identici bit che erano già stati ampiamente testati