Você precisa de um processo de garantia de qualidade (QA) adequado.

Em uma equipe profissional de desenvolvimento de software, você não passa do desenvolvimento à produção. Você tem pelo menos três ambientes separados: desenvolvimento, encenação e produção.

Quando você pensa que tem algo funcionando em seu ambiente de desenvolvimento, você avança para a primeira preparação, em que cada confirmação é testada pela equipe de controle de qualidade e, somente se o teste for bem-sucedido, ela será enviada para produção. Idealmente, o desenvolvimento, teste e envio para produção são feitos por pessoas separadas. Isso pode ser assegurado configurando seu sistema de automação de construção de forma que os desenvolvedores só possam implementar do desenvolvimento ao armazenamento temporário e que a equipe de controle de qualidade possa implantar somente de teste para produção.

Quando você não consegue persuadir a gerência a contratar alguém para fazer o seu controle de qualidade, então talvez um de vocês possa desempenhar esse papel para o outro. Eu nunca trabalhei com diploy.io, mas alguns sistemas de automação de construção podem ser configurados de forma que um usuário possa implementar tanto do desenvolvimento ao escalonamento e do escalonamento à produção, mas não ambos para a mesma construção, então uma segunda pessoa é sempre necessário (mas certifique-se de ter algumas pessoas de backup para momentos em que um de vocês está ausente).

Outra opção é ter sua equipe de suporte fazendo o controle de qualidade. Isso pode parecer um trabalho adicional para eles, mas também garante que eles estejam cientes de qualquer alteração no aplicativo, o que pode proteger alguns trabalhos a longo prazo.

Você provavelmente desejará obter um servidor dev e, preferencialmente, um ambiente de preparo também. Ninguém deveria estar passando do local para a produção, exceto pelo seu próprio site pessoal. O seu processo de implementação deve apenas suportar dev-> staging- > prod. Você provavelmente quer alguém responsável por assinar novos lançamentos - dependendo da organização, isso pode ser um líder de projeto, um QA dedicado ou um dever que gira a cada semana (com um lembrete tangível, por exemplo, apenas a pessoa com o brinquedo fofo empurrar). No entanto, discuta com sua equipe primeiro para conseguir o buy-in (veja abaixo).

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

Você poderia ter sua suíte de testes (você tem uma dessas, certo?) incluir uma verificação que determina se você está em um servidor de produção e, se isso acontecer, envia a todos no escritório um email dizendo Looks like $username is testing on prod, watch out . Talvez publicamente envergonhar seu colega seja desagradável. Ou você pode criar restrições técnicas, como IP, proibindo que sua equipe veja o prod (que você pode levantar, mas precisa justificar).

Eu não recomendo, porém, você se pareceria com o problema, não com a pessoa que está testando o prod e você poderia se tornar muito impopular com as pessoas da equipe que não se importam.

Certamente, o que você realmente quer não é que esse comportamento seja punido, mas para que ele pare ?

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

É ótimo que você esteja defendendo melhorias no fluxo de trabalho, mas parece que você não pensa muito em seus colegas e / ou não tem o apoio total deles. Isso provavelmente fará com que os colegas interajam de forma meio acalorada com o fluxo de trabalho, fazendo o mínimo necessário para colocar o código em produção e não seguindo realmente o espírito do fluxo de trabalho, o que significará mais tempo gasto na limpeza. E quando você está gastando mais e mais tempo limpando os resultados da interação inadequada com o fluxo de trabalho (porque ninguém mais se importa, certo?), Todo mundo questionará o fluxo de trabalho em si.

Então comece com uma conversa.

Descubra por que isso está acontecendo (a máquina do seu colega não é tão boa para testes? Seu colega está incerto com ramificações de recursos ou está preso em uma mentalidade svn onde commit e push são os mesmos?), explique por que isso é um problema para você código não testado vai em dev / staging / prod, e veja se você pode fazer algo para mudar porque isso acontece (seu colega provavelmente fará o que você quer se você tiver feito um teste mais localmente do que se você tivesse acabado de repreendê-lo) eles).

Se você não consegue resolvê-lo e isso realmente se resume a uma diferença de opinião, agende uma discussão por toda a equipe em sua próxima reunião retrospectiva, veja o que seus colegas fazem e pensam. Faça o seu caso, mas ouça o consenso. Talvez sua equipe diga que não há problema em testar correções textuais localmente, e você só tem uma regra de que nenhum recurso grande vai para o desenvolvedor não testado. Anote na reunião e leia o que você decide coletivamente sobre o que é permitido em cada um dos ambientes. Defina uma data em alguns meses para analisá-la, talvez em uma retrospectiva.

No trabalho, evitamos isso usando Gerrit . O Gerrit é um sistema de revisão de código que atua como uma porta para o seu branch Git principal / de produção que é convencionalmente chamado de "master". Você tem revisões de código, certo? Parece que você os faz excepcionalmente. Com o Gerrit, você passa para uma espécie de ramificação temporária que, depois que você e seu colega de trabalho executaram o processo de revisão de código satisfatoriamente, o Gerrit se funde com o seu branch master. Você pode até ligar o Gerrit a um servidor de IC para executar testes de unidade antes que alguém receba um email para revisar uma alteração. Se você não tem um servidor, você pode configurar uma ferramenta de CI, Codeship tem um bom plano gratuito para usar como uma prova de conceito. / p>

Por último, é claro, é automatizar as implantações de produção apenas de produtos de construção sancionados que sobreviveram à revisão de código e ao teste de unidade. Existem algumas tecnologias interessantes para isso, que eu não vou mencionar por medo de ser uma isca chama.

Vá ao seu chefe com uma solução. Este se aplica até mesmo a você e é uma maneira de melhorar a qualidade de código de todos, não apenas punir seu colega de trabalho.

Eu vejo isso como um problema em grande parte humano - o processo está lá e as ferramentas estão lá, mas o processo não está sendo seguido.

Eu concordo com o que os outros disseram aqui, sobre a possibilidade de que seja bem possível que o desenvolvedor em questão esteja apenas preso em um SVN mentalidade, e pode muito bem pensar que ele está seguindo o processo.

Acho que a melhor maneira de abordar esse tipo de problema, especialmente quando pode não haver um superior claro, não gira em torno da punição ou da remoção do acesso - isso apenas leva ao ressentimento e como parece que você é o mais barulhento proponente de seguir o processo (há sempre um, e eu já estive 'aquele cara' antes), você é o único que provavelmente vai lidar com a maior parte do calor. Ele gira em torno de levar as pessoas a um acordo sobre o processo primeiro.

É aqui que reuniões estruturadas, como reuniões de tipo "lições aprendidas" após um grande incidente na produção, podem ser muito úteis. Tente fazer com que todos concordem, incluindo o desenvolvedor em questão, que revisão de código, teste de unidade, testes abrangentes, etc. precisam ser realizados, sempre (e você pode começar a introduzir a ideia de um ambiente de preparação aqui também). Não deve ser difícil e é muito sensato. Em seguida, peça à equipe que elabore algumas regras sólidas, sobre como isso deve ser feito. Quanto mais o desenvolvedor que está causando o problema contribuir, mais ele se sentirá como aderente às regras e começará a entender por que seu comportamento tem sido um problema.

O ponto final, é nunca cair no "bem, é melhor do que costumava ser!" armadilha. Há sempre espaço para melhorias. É comum as pessoas na indústria de TI, na minha experiência, começarem a se contentar com o que obtiveram, depois de algumas melhorias. A resolução continua, até que você está de repente em um ponto de crise novamente.

Isso não é incomum , principalmente em pequenas equipes . Não faça muita coisa, mas faça uma regra informal:

Quebre a construção, traga donuts.

Ou 1) Você receberá donuts duas vezes por semana ou 2) eles seguirão o padrão.

Faça uma reunião. Não acusando, não mencione ninguém pelo nome, mas algo semelhante a, "Desde que introduzimos os padrões de controle e implantação de versão, as coisas ficaram muito mais fáceis e o servidor ficou mais tempo do que costumava ser. é ótimo! No entanto, ainda é tentador pegar um atalho e enviá-lo sem o teste adequado. É uma aposta, e nosso servidor está na linha. Sugiro que a partir de agora, se algum de nós enviar um código que quebre o servidor, a pessoa responsável traz donuts para a equipe no dia seguinte. "

Substitua qualquer outra coisa por rosquinhas, se desejar, e não a torne cara - o almoço para toda a equipe seria demais, mas uma caixa de US $ 5 de donuts ou bandeja de frutas e vegetais, batatas fritas e molho etc. Provavelmente seja chato o suficiente para fazê-los realmente pesar o risco contra a conveniência de pular o teste sem torná-lo um fardo que os afastaria da equipe ou empresa.

Now, how can I force them...

Em vez de forçar seus colegas, tente fazê-los ver as coisas da sua perspectiva. Isso tornará as coisas muito mais fáceis para todos. O que me leva a ...

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

Por que é uma dor para você com problemas no servidor ao vivo, mas não para esse cara? Você sabe algo que ele não sabe? O que você pode fazer para que ele veja as coisas do jeito que você faz?

Se você tiver sucesso com isso, você mostrará o melhor dele e ele encontrará soluções para o problema em que você nunca pensou.

Em geral, tente trabalhar junto com as pessoas para resolver problemas, em vez de forçá-los a processos que não entendem.

Qual é o pior que poderia acontecer? Você tem backups que são bons o suficiente para que um bug modificando registros aleatórios em seu banco de dados possa ser corrigido restaurando uma versão antiga?

Digamos que você tenha um bug em que usa um ID de registro e, por engano, o valor de uma nota em centavos é armazenado em uma variável usada para o ID do registro. Então, se eu pagar US $ 12,34, o registro com o id 1234 será modificado. Você pode se recuperar disso, se o software for executado por algumas horas até que o bug seja detectado? (Se tanto o registro correto quanto o registro 1234 forem atualizados, você só detectará isso quando o registro 1234 for usado, de modo que isso possa passar despercebido por um bom tempo).

Agora pergunte ao seu desenvolvedor altamente motivado o que ele acha disso. Obviamente, ele não pode afirmar que nunca comete erros, porque fez isso no passado.

Você compreende claramente vários processos e soluções técnicas possíveis. A questão é como gerenciar o colega de trabalho.

Este é essencialmente um exercício de gerenciamento de mudanças.

Em segundo lugar, você trabalha em uma equipe pequena e vale a pena tentar envolver toda a equipe na melhoria do processo.

Configure retrospectivas de processo regulares (por exemplo, semanais). Tem toda a equipe:

• Identifique problemas
• Idéias voluntárias para melhorar as práticas de trabalho
• Envolva-se na implementação dessas práticas

Deve seguir naturalmente que toda a equipe também ajuda a garantir a conformidade com as práticas aprimoradas.

Acho que você identificou alguns problemas:

1. Parece que qualquer código que é verificado pode ser banido para a produção por qualquer pessoa que tenha o direito de verificar o código.

Francamente, acho que a configuração é insana. No mínimo, as pessoas que podem disparar manualmente um push para a produção devem ser restritas ao conjunto de pessoas que podem ser totalmente confiáveis para revisar e testar completamente todas as alterações de saída (independentemente de quem criou as alterações) antes de acionar o push. Dar a alguém com permissão para fazer check-in do código a capacidade de desencadear arbitrariamente um push para a produção é apenas um problema. Não apenas de desenvolvedores descuidados e / ou incompetentes, mas também de desenvolvedores insatisfeitos ou mal-intencionados que comprometem uma de suas contas.

E se você for usar um processo de botão de ação para implantar todas as alterações que forem registradas, será necessário ter um conjunto abrangente de testes automatizados, e pressionar o botão precisa executá-los (e abortar a implantação se algum teste falhar!). Seu processo não deve permitir que um código que sequer tenha sido testado superficialmente chegue ao ponto de estar sendo implantado no sistema de produção.

Seu colega de trabalho cometeu um grande erro ao verificar o código sem testá-lo primeiro. Sua organização está com um erro muito maior ao adotar um processo de implantação que permite que o código não testado chegue à produção sob qualquer circunstância.

Portanto, a primeira ordem de negócios é corrigir o processo de implantação. Limite quem pode desencadear um push para a produção ou incorpore uma quantidade razoável de testes em seu processo de implantação automatizado ou ambos.

2. Parece que você pode não ter definido nenhum padrão / princípio de desenvolvimento claramente definido.

Em particular, parece que você está perdendo uma clara " definição de feito " e / ou usando um que não inclua "o código foi testado" como um fator de bloqueio na verificação de código em / implantar código para produção. Se você tivesse isso, em vez de apenas apontar que "um bom código não é produzido dessa maneira", você poderia dizer "esse código não está atendendo aos padrões mínimos que todos nós concordamos, e ele precisa ser melhor no futuro".

Você deve tentar estabelecer uma cultura que comunique claramente o que é esperado dos desenvolvedores e os padrões e níveis de qualidade que eles devem manter. A definição de uma definição que inclua, pelo menos, testes manuais (ou, de preferência, caixas de testes automatizadas que podem ser executadas como parte do processo de compilação / implementação) ajudará com isso. Como pode ter consequências para quebrar a compilação. Ou consequências mais graves para quebrar o sistema de produção. Observe que essas duas coisas devem ser realmente independentes, e deve ser completamente impossível interromper a construção e o sistema de produção ao mesmo tempo (porque compilações quebradas não devem ser implementadas).

Você deve integrar um processo de revisão contínua + revisão por pares na empresa. O Bitbucket facilita isso.

E +1 para o servidor de desenvolvimento sugerido por outros usuários.

Não seja rude com ele, isso só afetará sua relação de trabalho.