Quando il mio collega pensa che non sia necessario un test sul suo PC, apporta modifiche, si impegna e quindi spinge. Quindi verifica sul server di produzione e si rende conto di aver commesso un errore. Succede una volta alla settimana. Ora vedo che ha eseguito 3 commit e che ha inviato la distribuzione al server di produzione in 5 minuti.

Gli ho detto alcune volte che non è così che si fa un buon lavoro. Non voglio essere di nuovo scortese con lui ed è nello stesso stato con me in compagnia e ha lavorato più di me qui.

Voglio che questo comportamento sia punito in qualche modo o lo renda spiacevole il più possibile.

Prima di iniziare, la società distribuiva utilizzando metodi antichi, come FTP, e non c'era controllo della versione.

Ho costretto loro / noi a usare Git, Bitbucket, Dploy.io e HipChat. La distribuzione non è automatica, qualcuno deve accedere a dply.io e premere il pulsante di distribuzione.

Ora, come posso forzarli a non eseguire test sul server di produzione? Qualcosa come il bot HipChat può avvertire che ci sono ripetute modifiche sulla stessa linea e inviare un avviso al programmatore.

È necessario un processo di controllo qualità (QA) adeguato.

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

Quando pensi di avere qualcosa che funzioni nel tuo ambiente di sviluppo, spingi prima alla messa in scena, dove ogni commit viene testato dal team QA e solo se quel test ha esito positivo, viene portato alla produzione. Idealmente, lo sviluppo, il collaudo e la promozione della produzione vengono effettuati da persone separate. Ciò può essere garantito configurando il sistema di automazione della compilazione in modo tale che gli sviluppatori possano implementare dallo sviluppo alla gestione temporanea e che il team addetto al controllo qualità possa implementare 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ò svolgere quel ruolo per l'altro. Non ho mai lavorato con diploy.io, ma alcuni sistemi di automazione della build possono essere configurati in modo tale che un utente possa distribuire sia dallo sviluppo alla gestione temporanea che dalla gestione temporanea alla produzione, ma non fare entrambi per lo stesso 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 è che il personale di supporto faccia il controllo qualità. Questo potrebbe sembrare un lavoro aggiuntivo per loro, ma assicura anche che siano a conoscenza di eventuali modifiche all'applicazione che possono proteggerli in qualche modo nel lungo periodo.

Probabilmente vorrai ottenere un server di sviluppo, e preferibilmente anche un ambiente di gestione temporanea. Nessuno dovrebbe mai spingere da locale a produzione tranne per il proprio sito Web personale. Il processo di distribuzione dovrebbe supportare solo dev-> staging-> prod. Probabilmente vuoi qualcuno responsabile della firma di nuove uscite - 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 giocattolo soffice quella settimana arriva a spingere). Tuttavia, discutilo prima con il tuo team per ottenere il buy-in (vedi sotto).

Voglio che questo comportamento sia punito in qualche modo o lo renda spiacevole il più possibile.

Potresti avere la tua suite di test (ne hai una, vero?) Che include un controllo che determina se sei su un server di produzione e, in tal caso, invia a tutti in ufficio un messaggio di posta elettronica Looks like $username is testing on prod, watch out. Forse vergognare pubblicamente il tuo collega sarebbe spiacevole. Oppure potresti creare restrizioni tecniche come l'IP-vietare al tuo team di guardare prod (che puoi sollevare ma devi giustificare).

Non lo consiglio, però, sembreresti il ​​problema, non la persona che sta testando il pungolo e potresti renderti molto impopolare con le persone del team a cui non importa.

Sicuramente quello che vuoi davvero non è che questo comportamento sia punito, ma che si fermi ?

Li ho costretti / noi ad usare [...]

È fantastico che tu stia sostenendo miglioramenti del flusso di lavoro, ma sembra che tu non pensi molto ai tuoi colleghi e / o che tu non abbia il loro pieno supporto. Ciò può comportare l'interazione accesa a metà dei colleghi con il flusso di lavoro, facendo il minimo necessario per ottenere il codice nella produzione e non seguendo realmente lo spirito del flusso di lavoro, il che significherebbe più tempo speso a chiarire. E quando passi sempre più tempo a chiarire i risultati di un'interazione inadeguata con il flusso di lavoro (perché a nessuno importa, giusto?) Tutti gli altri metteranno in discussione il flusso di lavoro stesso.

Quindi inizia con una conversazione.

Scopri perché sta succedendo (la macchina del tuo collega non è adatta ai test? Il tuo collega è incerto con i rami delle funzionalità o bloccato in una mentalità svn in cui commit e push sono gli stessi?), Spiega perché è un problema per te che il codice non testato vada su dev / staging / prod, e vedi se riesci a fare qualcosa per cambiare il motivo per cui accade (il tuo collega farà più probabilmente quello che vuoi se hai appena reso più bello il test a livello locale che se li hai appena rimproverati).

Se non riesci a risolverlo e si riduce davvero a una differenza di opinione, organizza una discussione a livello di team nella prossima riunione retrospettiva, vedi cosa fanno i tuoi colleghi e pensano. Fai il tuo caso, ma ascolta il consenso. Forse il tuo team dice che va bene non testare le correzioni testuali localmente, e hai solo una regola che nessuna grande funzionalità va su dev non testata. Annotare nella riunione e leggere ciò che si decide collettivamente su ciò che è consentito in ciascuno degli ambienti. Stabilisci una data tra un paio di mesi per esaminarla, magari in una retrospettiva.

Al lavoro, lo evitiamo usando Gerrit . Gerrit è un sistema di revisione del codice che funge da gate per il tuo ramo Git principale / di produzione che è convenzionalmente chiamato "master". Hai recensioni di codice, giusto? Sembra che tu li faccia personalmente eccezionalmente. Con Gerrit, spingi verso una sorta di ramo di gestione temporanea che, dopo che tu e il tuo collega avete eseguito in modo soddisfacente il processo di revisione del codice, Gerrit si unisce quindi al ramo principale. Puoi persino collegare Gerrit a un server CI per eseguire unit test prima che qualcuno riceva un'email per rivedere una modifica. Se non si dispone di un server su cui è possibile impostare uno strumento CI, Codeship ha un bel piano gratuito da utilizzare come prova di concetto.

L'ultimo, ovviamente, è quello di automatizzare le distribuzioni di produzione solo da prodotti di costruzione sanzionati che sono sopravvissuti alla revisione del codice e ai test delle unità. Ci sono alcune tecnologie interessanti in arrivo per questo, che non menzionerò per paura che sarebbe un'esca di fiamma.

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

Vedo questo 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 altri hanno detto qui, sulla possibilità che sia abbastanza possibile che lo sviluppatore in questione sia semplicemente bloccato in una mentalità SVN e potrebbe benissimo pensare che stia seguendo 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 a risentimento e siccome sembra che tu sia il forte sostenitore di seguire il processo (ce n'è sempre uno, e in precedenza sono stato "quel ragazzo"), sei tu quello che probabilmente tratterà più calore. Ruota intorno portando le persone a concordare prima il processo.

È qui che incontri strutturati, come incontri di tipo "lezioni apprese" dopo un grave incidente di produzione, possono essere molto utili. Prova a convincere tutti, compreso lo sviluppatore in questione, che la revisione del codice, i test unitari, i test completi, ecc. Devono sempre aver luogo, ogni volta (e puoi iniziare a introdurre l'idea di un ambiente di staging anche qui). Non dovrebbe essere difficile ed è molto sensato. Quindi chiedi al team di elaborare insieme alcune regole solide, su come dovrebbe essere fatto. Più lo sviluppatore che sta causando il problema contribuisce, più avranno voglia di aderire alle regole e inizieranno a capire perché il loro comportamento è stato un problema.

L'ultimo punto è non cadere mai nel "beh, è ​​meglio di prima!" trappola. C'è sempre spazio per il miglioramento. È comune per le persone del settore IT, nella mia esperienza, iniziare ad accontentarsi di ciò che hanno, dopo alcuni miglioramenti. L'insediamento quindi continua, fino a quando non sei di nuovo improvvisamente in un punto di crisi.

Questo non è raro , in particolare nelle piccole squadre. Non fare molto, ma fai una regola informale:

Rompi la costruzione, porta le ciambelle.

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

Presentalo in una riunione. Non per accusa, non menzionare nessuno per nome, ma qualcosa di simile a "Da quando abbiamo introdotto il controllo della versione e gli standard di distribuzione, le cose sono diventate molto più semplici e il server è più attivo di quanto non fosse in passato. Questo è fantastico! Tuttavia è ancora allettante tentare di prendere una scorciatoia e inviare senza test adeguati. Tuttavia, è una scommessa e il nostro server è in linea. Suggerisco che d'ora in poi se qualcuno di noi invia codice che rompe il server, la persona responsabile porta ciambelle per la squadra il giorno successivo ".

Sostituisci qualcos'altro con le ciambelle se lo desideri, e non renderlo costoso: il pranzo per l'intera squadra sarebbe troppo, ma una scatola da $ 5 di ciambelle o vassoio di frutta / verdura, o patatine e salsa, ecc., Probabilmente sarebbe fastidioso abbastanza per farli effettivamente soppesare il rischio rispetto alla comodità di saltare i test senza renderlo un onere che li allontanerebbe dal team o dall'azienda.

Ora, come posso forzarli ...

Invece di forzare i tuoi colleghi, prova a far vedere loro le cose dalla tua prospettiva. Questo renderà le cose molto più facili per tutti. Il che mi porta in ...

Voglio che questo comportamento sia punito in qualche modo o lo renda spiacevole il più possibile.

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

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

In generale, prova a collaborare con le persone per risolvere i problemi piuttosto che forzarli in processi che non comprendono.

Qual è il peggio che potrebbe succedere? Hai backup abbastanza buoni da poter correggere un bug che modifica record casuali nel tuo database ripristinando una versione precedente?

Supponiamo che tu abbia un bug in cui usi un ID record e, per errore, l'importo di una fattura in centesimi viene archiviato in una variabile utilizzata per l'ID record. Quindi, se pago $ 12,34, il record con ID 1234 verrà modificato. Puoi recuperare da questo, se il software viene eseguito per alcune ore fino a quando il bug non viene rilevato? (Se vengono aggiornati sia il record corretto che il record 1234, questo verrà rilevato solo quando viene utilizzato il record 1234, quindi potrebbe non essere rilevato per un bel po ').

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

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

Questo è essenzialmente un esercizio di gestione del cambiamento.

In primo luogo, avrei una parola tranquilla con il fondatore per assicurarmi che sia d'accordo con il tuo punto di vista. Se si verifica un'interruzione della produzione, mi aspetto che il fondatore sia molto preoccupato per questo e desideri un cambiamento.

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

Impostare retrospettive di processo regolari (ad esempio settimanali). Avere l'intera squadra:

• Identificare i problemi
• Idee di volontariato per migliorare le pratiche di lavoro
• Impegnarsi nell'attuazione di tali pratiche

Dovrebbe seguire naturalmente che l'intero team aiuta anche a garantire il rispetto delle pratiche migliorate.

Penso che tu abbia identificato un paio di problemi:

1. Sembra che qualsiasi codice che viene controllato possa essere banalmente spinto in produzione da chiunque abbia i diritti per eseguire 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 all'insieme di persone di cui ci si può fidare completamente per rivedere e testare accuratamente tutte le modifiche in uscita (indipendentemente da chi ha creato le modifiche) prima di attivare la spinta. Dare a chiunque con il permesso di archiviare il codice il potere di innescare arbitrariamente una spinta alla produzione è solo chiedere problemi. Non solo da sviluppatori disattenti e / o incompetenti, ma anche da quelli scontenti o da terze parti dannose che capita di compromettere uno dei tuoi account.

E se hai intenzione di utilizzare una procedura a pulsante per distribuire tutte le modifiche che vengono archiviate, devi disporre di una suite completa di test automatizzati e premere il pulsante per eseguirli (e interrompere la distribuzione se eventuali test falliscono!). Il tuo processo non dovrebbe consentire al codice che non è stato nemmeno testato superficialmente di raggiungere il punto in cui viene distribuito in primo luogo al sistema di produzione.

Il tuo collega ha commesso 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 riparare il processo di distribuzione. Limitare chi può innescare una spinta alla produzione o incorporare una quantità ragionevole di test nel processo di distribuzione automatizzata o entrambi.

2. Sembra che potresti non aver fissato standard / principi di sviluppo chiaramente definiti.

In particolare, sembra che ti manchi una " definizione di fatto " chiara e / o utilizzi una che non includa "il codice è stato testato" come fattore di gating nel controllare il codice / distribuire il 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 nella 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. L'impostazione di una definizione di done che includa almeno test manuali (o preferibilmente, testcase automatizzati che possono essere eseguiti come parte del processo di compilazione / distribuzione) sarà di aiuto. Come può avere conseguenze per rompere la build. O conseguenze più gravi per la rottura del sistema di produzione. Si noti che queste due cose dovrebbero essere realmente indipendenti e dovrebbe essere assolutamente impossibile interrompere contemporaneamente la build e il sistema di produzione (poiché le build interrotte non dovrebbero mai essere implementabili).

È necessario integrare un processo di integrazione continua + revisione tra pari all'interno dell'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.