È necessario un processo di Quality Assurance (QA) adeguato.

In un team di sviluppo software professionale, non si spinge dallo sviluppo alla produzione. Hai almeno tre ambienti separati: sviluppo, gestione temporanea e produzione.

Quando pensi di avere qualcosa che funziona nel tuo ambiente di sviluppo, spetti prima alla fase di staging, dove ogni commit viene testato dal team di controllo qualità e solo se il test ha esito positivo, viene spinto alla produzione. Idealmente, lo sviluppo, il test e la spinta alla produzione sono fatti da persone separate. Ciò può essere garantito configurando il sistema di automazione della build in modo tale che gli sviluppatori possano solo distribuire dallo sviluppo alla staging e che il team addetto al QA possa distribuire solo dalla gestione temporanea alla produzione.

Quando non riesci a convincere il management ad assumere qualcuno per fare il tuo QA, allora forse uno di voi può giocare quel ruolo per l'altro. Non ho mai lavorato con diploy.io, ma alcuni sistemi di automazione di build possono essere configurati in modo che un utente possa distribuire sia dallo sviluppo alla staging e dalla staging alla produzione, ma non eseguono entrambi per la stessa build, quindi una seconda persona è sempre richiesto (ma assicurati di avere alcune persone di backup per le volte in cui uno di voi è assente).

Un'altra opzione è fare in modo che il personale di supporto esegua il controllo qualità. Questo potrebbe sembrare un lavoro aggiuntivo per loro, ma si assicura anche che siano a conoscenza di eventuali modifiche all'applicazione che possano proteggerle un po 'di lavoro a lungo termine.

Probabilmente vorrai ottenere un server di sviluppo, e preferibilmente anche un ambiente di staging. Nessuno dovrebbe mai spingere dal locale alla produzione se non per il proprio sito web personale. Il tuo processo di implementazione dovrebbe supportare solo i prodotti di staging- > dev. Probabilmente vorresti che qualcuno fosse responsabile della firma delle nuove versioni - a seconda dell'organizzazione, questo può essere un lead di progetto, un QA dedicato o un dovere che ruota ogni settimana (con un promemoria tangibile ad esempio solo la persona con il peluche che la settimana arriva a Spingere). Tuttavia, discuti prima con la tua squadra per ottenere il buy-in (vedi sotto).

I want this behavior to be punished in some way or make it unpleasant as much as possible.

Potresti avere la tua suite di test (ne hai una, giusto?) includere un controllo che determina se sei su un server di produzione e, se lo fa, invia a tutti in ufficio un'email dicendo Looks like $username is testing on prod, watch out . Forse svergognare pubblicamente il tuo collega sarebbe spiacevole. Oppure potresti creare restrizioni tecniche come il divieto dell'IP da parte della tua squadra di guardare i prod (che puoi sollevare ma devi giustificare).

Non lo consiglio, tuttavia, sembrerebbe il problema, non la persona che sta provando su prod e potresti renderti molto impopolare con le persone della squadra a cui non interessa.

Sicuramente quello che vuoi veramente non è che questo comportamento sia punito, ma per farlo fermare ?

I forced them/us to use [...]

È bello che tu stia sostenendo i miglioramenti del flusso di lavoro, ma sembra che tu non pensi molto ai tuoi colleghi e / o che non hai il loro pieno supporto. Ciò dovrebbe comportare che i colleghi interagiscano semestralmente con il flusso di lavoro, facendo il minimo necessario per ottenere il codice sulla produzione e non seguendo realmente lo spirito del flusso di lavoro, il che significa più tempo dedicato alla pulizia. E quando passi sempre più tempo a chiarire i risultati di un'interazione inadeguata con il flusso di lavoro (perché a nessun altro importa, giusto?) Tutti gli altri metteranno in discussione il flusso di lavoro stesso.

Quindi inizia con una conversazione.

Scopri perché sta accadendo (la macchina del tuo collega non è buona per i test? Il tuo collega è incerto con le feature branch o è bloccato in una mentalità svn in cui commit e push sono uguali?), spiega perché è un problema per te che il codice non testato va su dev / staging / prod, e vedi se puoi fare qualcosa per cambiare perché succede (il tuo collega farà più probabilmente quello che vuoi se lo hai appena reso più bello da testare localmente che se ti sei appena rimproverato loro).

Se non riesci a risolverlo e si tratta davvero di una divergenza di opinioni, pianifica una discussione a livello di gruppo nella tua prossima riunione retrospettiva, guarda cosa fanno e pensano i tuoi colleghi. Fai il tuo caso, ma ascolta il consenso. Forse il tuo team dice che è giusto non testare le correzioni testuali a livello locale, e hai solo una regola che nessuna funzione di grandi dimensioni va a testare non testata. Annota nella riunione e leggi ciò che decidi collettivamente su ciò che è permesso su ciascuno degli ambienti. Imposta una data in un paio di mesi per esaminarla, magari in una retrospettiva.

Al lavoro, evitiamo questo problema utilizzando Gerrit . Gerrit è un sistema di revisione del codice che funge da porta per il ramo Git principale / di produzione che viene convenzionalmente chiamato "master". Hai recensioni sul codice, giusto? Sembra che tu li faccia personalmente eccezionalmente. Con Gerrit, spingi verso una sorta di ramo di staging che, dopo che tu e il tuo collega avete eseguito il processo di revisione del codice in modo soddisfacente, Gerrit si fonde quindi con il vostro ramo principale. Puoi persino collegare Gerrit a un server CI per eseguire test unitari prima che qualcuno riceva un'email per rivedere una modifica. Se non si dispone di un server, è possibile impostare uno strumento CI attivo, Codeship ha un buon piano gratuito da utilizzare come prova del concetto.

Infine, naturalmente, è necessario automatizzare le distribuzioni di produzione solo dai prodotti di costruzione sanzionati che sono sopravvissuti alla revisione del codice e ai test unitari. Ci sono alcune fantastiche tecnologie in arrivo per questo, che non citerò per paura che sarebbe un'esca di fiamma.

Vai al tuo capo con una soluzione. Questo si applica anche a te, ed è un modo per migliorare la qualità del codice di tutti, non solo punire il tuo collega.

Lo vedo come un problema in gran parte umano - il processo è lì e gli strumenti ci sono, ma il processo non viene seguito.

Sono d'accordo con ciò che gli altri hanno detto qui, sulla possibilità che sia del tutto possibile che lo sviluppatore in questione sia bloccato in un SVN mindset, e potrebbe ben pensare che è dopo il processo.

Trovo che il modo migliore per affrontare questo tipo di problema, specialmente dove potrebbe non esserci un chiaro superiore, non ruota attorno alla punizione o alla rimozione dell'accesso - questo porta solo al risentimento e sembra che tu sia il strong proponente di seguire il processo (ce n'è sempre uno, e io sono stato 'quel ragazzo' prima), tu sei quello che è probabile che copi più caldo. Riguarda innanzitutto il coinvolgimento delle persone nel processo.

È qui che le riunioni strutturate, come gli incontri "lezioni apprese" dopo un incidente importante in produzione, possono essere molto utili. Prova a far sì che tutti siano d'accordo, incluso lo sviluppatore in questione, che la revisione del codice, i test unitari, i test completi, ecc. Devono essere eseguiti ogni volta (e anche qui puoi iniziare a presentare l'idea di un ambiente di staging). Non dovrebbe essere difficile, ed è molto sensato. Poi chiedi al team di formulare alcune regole solide, su come dovrebbe essere fatto. Più lo sviluppatore che sta causando il problema contribuisce, più sentiranno aderire alle regole e inizieranno a capire perché il loro comportamento è stato un problema.

L'ultimo punto, non è quello di cadere nel "bene, è meglio di un tempo!" trappola. C'è sempre spazio per il miglioramento. È normale che le persone nel settore IT, nella mia esperienza, inizino a stabilirsi per quello che hanno, dopo alcuni miglioramenti. L'assestamento continua poi, fino a quando non sei di nuovo in un punto di crisi.

Questo non è raro , in particolare in piccoli gruppi . Non fare un grosso problema, ma fai una regola informale:

Rompi la build, aggiungi le ciambelle.

O 1) Riceverai ciambelle due volte alla settimana o 2) aderiranno allo standard.

Portalo in riunione. Non in modo accusatorio, non menzionare nessuno per nome, ma qualcosa di simile a, "Da quando abbiamo introdotto il controllo della versione e gli standard di implementazione, le cose sono diventate molto più semplici e il server è attivo più del tempo di una volta. è bello! Comunque è ancora tentato di prendere una scorciatoia e inviarla senza test adeguati.E 'un gioco d'azzardo, però, e il nostro server è sulla linea.Propongo che d'ora in poi se qualcuno di noi invia il codice che rompe il server, la persona il responsabile porta le ciambelle per la squadra il giorno successivo. "

Sostituire qualcos'altro per ciambelle se lo si desidera, e non renderlo costoso - il pranzo per l'intera squadra sarebbe troppo, ma una scatola da $ 5 di ciambelle o vassoio di frutta / verdura, patatine e salsa, ecc. ecc. probabilmente è abbastanza fastidioso da farli realmente pesare il rischio contro la comodità di saltare i test senza renderli un peso che li allontanerebbe dal team o dalla compagnia.

Now, how can I force them...

Invece di forzare i tuoi colleghi, prova a fargli vedere le cose dal tuo punto di vista. Ciò renderà le cose molto più facili per tutti. Il che mi porta in ...

I want this behavior to be punished in some way or make it unpleasant as much as possible.

Perché è un problema per te con problemi sul server live, ma non per questo ragazzo? Sai qualcosa che non fa? Cosa puoi fare per fargli vedere le cose come fai tu?

Se ci riesci, tirerai fuori il meglio di lui e troverà soluzioni al problema che non hai mai pensato.

In generale, cerca di collaborare con le persone per risolvere i problemi piuttosto che forzarli in processi che non capiscono.

Qual è la cosa peggiore che potrebbe accadere? Disponi di backup sufficienti per correggere un bug che modifica i record casuali nel database ripristinando una vecchia versione?

Supponiamo che tu abbia un bug in cui usi un ID del record e, per errore, l'importo di una bolletta in centesimi è memorizzato in una variabile utilizzata per l'id del record. Quindi, se pago $ 12,34, il record con l'ID 1234 verrà modificato. Puoi recuperare da quello, se il software funziona per alcune ore fino a quando il bug non viene rilevato? (Se vengono aggiornati sia il record corretto che il record 1234, lo si rileverà solo quando si utilizza il record 1234, quindi questo potrebbe non essere rilevato per un po 'di tempo).

Ora chiedi al tuo sviluppatore altamente motivato cosa ne pensa. Ovviamente non può affermare di non sbagliare mai, perché lo ha fatto in passato.

Comprendi chiaramente vari processi e soluzioni tecniche possibili. Il problema è come gestire il collega.

Questo è essenzialmente un esercizio di gestione delle modifiche.

In primo luogo, avrei una parola tranquilla con il fondatore per accertarmi che lui / lei sia a bordo con il tuo punto di vista. Se c'è un'interruzione della produzione, mi aspetterei che il fondatore sia molto preoccupato per questo e desideri cambiare.

In secondo luogo, lavori in un piccolo team e probabilmente vale la pena provare a coinvolgere tutto il team nel miglioramento dei processi.

L'impostazione regolare (ad esempio settimanalmente) elabora le retrospettive. Avere tutta la squadra:

• Identifica i problemi
• Proposte di volontariato per migliorare le pratiche di lavoro
• Impegnarsi ad attuare tali pratiche

Dovrebbe seguire naturalmente che l'intero team quindi aiuta anche a garantire la conformità con le pratiche migliorate.

Penso che tu abbia identificato un paio di problemi:

1. Sembra che qualsiasi codice che viene controllato possa essere banalmente messo in produzione da chiunque abbia i diritti per il check-in del codice.

Francamente penso che l'installazione sia semplicemente folle. Come minimo, le persone che possono attivare manualmente una spinta alla produzione dovrebbero essere limitate al gruppo di persone che possono essere considerate completamente per esaminare e testare tutte le modifiche in uscita (indipendentemente da chi ha apportato le modifiche) prima di attivare la spinta. Dando a chiunque con il permesso di controllare il codice, il potere di innescare arbitrariamente una spinta alla produzione è solo una richiesta di guai. Non solo da parte di sviluppatori incuranti e / o incompetenti, ma anche da quelli scontenti o da terze parti malintenzionate che compromettono uno dei tuoi account.

E se stai per utilizzare una procedura a pulsante per distribuire ogni modifica che viene archiviata, devi disporre di una suite completa di test automatici e premere il pulsante per eseguirli (e interrompere la distribuzione se qualche test fallisce!). Il tuo processo non dovrebbe consentire il codice che non è stato nemmeno testato superficialmente per raggiungere il punto in cui viene distribuito al sistema di produzione in primo luogo.

Il tuo collega ha fatto un grosso errore in termini di controllo del codice senza prima verificarlo. La tua organizzazione ha commesso un errore molto più grande adottando un processo di distribuzione che consente al codice non testato di raggiungere la produzione in qualsiasi circostanza.

Quindi il primo ordine del giorno è quello di correggere il processo di distribuzione. Limitare chi può attivare una spinta alla produzione o incorporare una quantità ragionevole di test nel processo di distribuzione automatizzato o entrambi.

2. Sembra che tu non abbia impostato alcun standard / principio di sviluppo chiaramente definito.

In particolare, sembra che manchi una chiara " definizione di fatto " e / o l'utilizzo di uno che non include "il codice è stato testato" come fattore di controllo sul controllo del codice in / distribuzione del codice in produzione. Se avessi questo, invece di sottolineare che "il buon codice non viene prodotto in questo modo" potresti dire "questo codice non soddisfa gli standard minimi che tutti abbiamo concordato, e deve essere migliore nel futuro".

Dovresti cercare di stabilire una cultura che comunichi chiaramente ciò che ci si aspetta dagli sviluppatori e gli standard e il livello di qualità che devono sostenere. La definizione di una definizione di fatto che includa almeno un test manuale (o preferibilmente, una serie di test automatizzati che possono essere eseguiti come parte del processo di build / deploy) aiuterà a farlo. Come può avere conseguenze per rompere la build. O più gravi conseguenze per rompere il sistema di produzione. Nota che queste due cose dovrebbero essere davvero indipendenti, e dovrebbe essere completamente impossibile rompere sia la build che il sistema di produzione contemporaneamente (perché le build rotte non dovrebbero mai essere distribuite).

Devi integrare un processo di integrazione continua + peer review in azienda. Bitbucket lo rende facile.

E +1 al server di sviluppo suggerito da altri utenti.

Non essere scortese con lui, farà solo male al tuo rapporto di lavoro.