Come posso far lavorare meglio i programmatori sul codice condiviso con i test

Fai in modo che la tua squadra risolva il problema e dia loro l'autonomia per farlo. Riunisci la tua squadra e fai del tuo meglio per dichiarare chiaramente il problema, la situazione e gli obiettivi. Indicalo come requisiti, definendo cosa deve accadere senza specificare come. Gli sviluppatori sono risolutori di problemi quindi rendi questo un problema da risolvere. Ciò significa che dovrai ascoltare e potrebbe dover rinunciare alla tua soluzione ideale, ma il tuo team possiede la soluzione in quanto saranno più propensi a seguire la soluzione che hanno trovato.

I tuoi requisiti potrebbero essere qualcosa come

1) Le build automatiche vengono eseguite ogni notte alle 9:00, quindi tutti i test devono essere superati. Chiedi al team come far rispettare questo (forse se rompi la build devi portare ciambelle:)

2) Le build vengono distribuite ogni mercoledì, se i test non passano entro martedì, perdiamo il rilascio e il ritardo fino alla finestra successiva. Come possiamo far rispettare questo?

Ogni volta che faccio questo con la mia squadra, trovo che escogitano una soluzione migliore rispetto a quella che ho dettato e la rafforzano reciprocamente, il che mi consente di concentrarmi su cose più importanti rispetto all'applicazione delle regole.

Se il problema è che la tua squadra rompe costantemente la build, allora dovresti sederti e discutere del problema.

Come manager dovresti chiarire che se non hai un artefatto costruibile in qualsiasi momento nel server di costruzione, non stai consegnando nulla. Quali sarebbero gli effetti del non consegnare nulla? Quindi lascia che il team provi a risolvere il problema con quali processi, pratiche e strumenti sono necessari al tuo team per avere tutto pronto a fine giornata. Assicurati anche che il team non abbia altri problemi urgenti durante questo giorno, altrimenti quelli avranno la precedenza per impostazione predefinita.

Ci sono molti modi per farlo, ma alla fine il team deve farlo, quindi dai al team abbastanza tempo (come un giorno o due) per farlo da solo.

... e se fanno ancora schifo, hai bisogno di programmatori migliori che abbiano la disciplina per fare questo tipo di lavoro.

Hai provato a rendere i fallimenti più visibili? Un radiatore di costruzione pubblica? E-mail committer / team / società (beh, l'ultima forse non è una buona idea se non si ha una piccola azienda ..) quando si rompe una build, descrivendo i contenuti del commit e il committer?

Cerca di creare un ciclo di feedback il più breve possibile. Se lo sviluppatore sa che ha rotto la build 15 minuti dopo il commit contro domani, c'è una enorme differenza in termini di capacità di reazione.

Sembra che tu stia sbagliando, intendo il flusso di lavoro generale git. Ecco un paio di suggerimenti:

We keep repeating "you have to pull first" (this is git and github by the way). Then you code a little, then get your tests to pass, then commit, then pull and push again.

Perché tutti si stanno impegnando nello stesso ramo? Questo è così svn :). Lascia che si sviluppino nei propri rami, specifici per sviluppatore o funzione. Non preoccuparti di cosa si rompono lì, ma richiedi che tutto debba superare i test e diventare di prima qualità in generale una volta che si uniscono le loro modifiche al ramo di produzione.

In questo modo un programmatore può sviluppare codice isolato in pace (anche per un paio di giorni quando si lavora su una funzione) e preoccuparsi dell'integrazione e dei test più tardi, quando decide di apportare modifiche alla produzione.

Puoi fare un passo in più - non permettere agli sviluppatori di spingere direttamente alla produzione affatto e dare loro invece uno script che permetterà loro di spingere le modifiche solo se tutti i test passare . Semplice.

Right now we are tempted to rollback all of todays changes which wouldn't be popular. I'm not a big fan of that harsh an approach to management but perhaps a 'final' warning that we will do that next time is now required.

Di nuovo, a cosa servono i rami? In questo caso puoi:

• crea un ramo "bugfix" dal ramo "produzione"

• cancella il codice rotto dal ramo "produzione"

• corregge il codice rotto nel ramo "bugfix"

• unisci "bugfix" di nuovo in "produzione"

Cosa c'è di così grave?

In generale, cerca di migliorare il tuo flusso di lavoro di controllo della versione (forse assumere un consulente git per aiutarti?), che dovrebbe impedire ai programmatori di inserire codice spezzato in produzione.

Ovviamente, il cattivo flusso di lavoro non è una scusa per commettere codice rotto, ma prendilo dal punto di vista dello sviluppatore - è molto facile interrompere il codice quando più persone lavorano sulla stessa app contemporaneamente e tutti si stanno impegnando nello stesso ramo . Soprattutto se fanno un enorme commit e i test sono fragili, ma non so se questo è il tuo caso.