Como posso convencer os programadores cowboys a usar o controle de origem?

Não é um problema de treinamento, é uma questão de fatores humanos. Eles não querem e estão criando bloqueios de estradas. Lidar com a dinâmica de grupo quebrada, qual é a causa da rota de sua objeção - geralmente medo, é apenas medo de mudança, ou é mais sinistro.

Nenhum desenvolvedor profissional hoje, ou nos últimos 20 anos, resistiu ao controle de origem. Uma vez, cerca de 30 ou 40 anos atrás, quando os computadores estavam lentos, o controle da fonte era ainda mais lento e os programas consistiam em um arquivo de 500 linhas, era uma dor e havia razões válidas para não usá-lo. Essas objeções só podem vir do pior tipo de caubói que eu posso imaginar.

O sistema é forçado neles dificultando suas vidas de alguma forma? Descubra o que é e altere o sistema para invalidar a objeção. Repita até terminar.

Eu sugiro olhar para o GIT ou o Mercurial. Você pode criar um repositório em cada árvore de código-fonte, eles nem perceberão e continuarão a hackear como fazem agora. Você pode acompanhar as alterações que eles hackearam na base de código, fazer commits, mesclá-los em outras árvores de código, etc. Quando eles vêem uma mescla de semanas de esforço em outro produto em segundos, eles podem mudar suas ideias. Quando você reverte um dos seus enroscados com um comando, e salva o seu traseiro, eles podem até agradecer (não conte com isso). Na pior das hipóteses, você fica bem na frente do chefe e, para um bônus, faz com que pareçam com os vaqueiros que são.

Merging would take not only a great knowledge of the project

Nesse caso, temo que você esteja no alto do proverbial riacho sem remo. Se a mesclagem não for uma opção, ela também não está sendo implementada. Por isso, você está dizendo que não é mais possível adicionar recursos que você já possui em uma ramificação (termo usado livremente) a outra.

Se eu fosse você, eu reconsideraria minhas perspectivas de carreira ...

Sometimes, real world issues make it impractical to use.

Falso.

If the team is not used to using source control, training problems can arise

Isso não tem nada a ver com controle de código-fonte e tudo a ver com treinamento. O treinamento é fácil, barato, eficiente e feito em questão de horas. Não usar o controle do código-fonte é caro, arriscado, ineficiente e os problemas persistem para sempre .

If a team member directly modifies code on the server, various issues can arise.

Essa é a questão do treinamento. Novamente. Nada a ver com controle de código-fonte e tudo a ver com treinamento.

Developers continue to have a distrust of source control and therefore compound the issue by not using source control

Eles precisam ser treinados em como usar o controle do código-fonte. Reduz o custo, reduz o risco, simplifica as coisas e é mais eficiente. É um investimento único que paga dividendos a cada momento.

What can possibly be done in this type of situation?

Comece a treinar todos sobre como usar o controle do código-fonte.

Atualizar

Developers argue that directly modifying source control saves time.

Como eles estão errados, é importante coletar dados para demonstrar com precisão o quanto isso é errado.

Infelizmente, no entanto, a gerência parece recompensar uma resposta imediata que é cara a longo prazo.

A única maneira de superar esse sistema de recompensas é

A) Identifique que o custo a longo prazo é maior do que o valor aparente de curto prazo.

identificar as recompensas reais que estão no lugar que fazem corrupção de curto prazo (ou seja, mudanças diretas) parecem mais valiosas do que controle de código-fonte correto a longo prazo. Quem recebe um tapinha na cabeça por fazer a coisa errada? Que tipo de tapinha na cabeça eles conseguem? Quem dá isso? Para consertar as coisas, você deve nomear as coisas que estão erradas e o (s) gerente (s) específico (s) que estão realmente incentivando as pessoas.

C) Recomende um sistema de recompensas revisado que valorize o valor a longo prazo em vez de uma resposta rápida de curto prazo. Diferentes tapinhas na cabeça por diferentes razões.

D) Treine as pessoas nas recompensas que você encontrou por valor a longo prazo; valor que é claramente maior do que a resposta rápida de curto prazo.

Os desenvolvedores que se recusarem a usar o controle de origem / versão devem ser acionados, simples assim. Como você já apontou, os riscos inerentes e os custos de NÃO usá-lo superam qualquer sobrecarga que ele gera em muitas, muitas ordens de grandeza. Qualquer um que tente argumentar contra isso simplesmente não deve estar envolvido no desenvolvimento de software e eu me recusaria a trabalhar com essas pessoas.

Resolvemos o problema primeiro, configurando um servidor de integração contínua para construir nosso controle de origem no dev. Segundo, bloqueie o acesso à pasta somente para leitura, para evitar que as pessoas contornem o controle de origem e modifiquem arquivos diretamente.

É um PITA nos dias em que você não pode reproduzir o bug localmente, mas, além disso, é melhor poder trabalhar, fazer check-in e seguir em frente, sabendo que ele será enviado automaticamente pelo servidor de IC.

Eu ouço sua dor. Eu entrei em um par de locais de trabalho para descobrir que 'controle de origem' era uma pasta compartilhada em uma unidade de rede. A questão geralmente não é porque eles acreditam que a abordagem é superior a qualquer outra coisa, ela simplesmente funciona e eles nunca foram apresentados a um fluxo de trabalho que integre com sucesso o controle de origem.

Com a estrutura da equipe de terra plana que você explicou, obter a mudança empurrada de cima para baixo pode não ser a melhor maneira de abordar a situação. Um método que vale a pena tentar é comprar diretamente de um ou dois dos outros desenvolvedores para permitir que o conceito ganhe força. Uma vez que você tenha um outro desenvolvedor a bordo, será muito mais fácil distribuí-lo para o restante da equipe. Lentamente, apresente-os ao conceito, por exemplo, comece a trabalhar em um projeto paralelo, faça o backup e Git , ou até mesmo ramifique algo hospedado em < um href="http://github.com/"> GitHub .

Comece de forma simples, introduza os conceitos devagar e separadamente de seu fluxo de trabalho diário. Os seres humanos são ótimos para aprender coisas e se adaptar à mudança, especialmente quando essa mudança fornece benefícios diretos para eles (pense na evolução). No entanto, quando apresentado com um monte de pequenas mudanças de uma só vez, torna-se alienante. Uma vez que eles tenham uma noção de como o controle de origem funciona e as vantagens que ele oferece, tente integrá-lo em um de seus projetos internos (se você iniciar um novo projeto, este é um momento ruim para introduzi-lo). Deixe os outros projetos funcionar da maneira existente, se você quiser também, isso será especialmente eficaz para destacar as vantagens do controle de código decente.

Se isso falhar, corra.

Você obviamente tem as habilidades técnicas para identificar e corrigir sua situação, seus problemas são humanos e relacionados ao processo.

As pessoas tendem a responder melhor ao exemplo do que à visão, por isso sugiro "corrigir" você mesmo:

Faça uma cópia da fonte mais recente, re-estruture-a para ser amigável ao controle de versão, crie um novo projeto com uma estrutura útil e voltada para o futuro (trabalhe como você lidará com filiais, onde você coloca dependências de terceiros etc). Você provavelmente terá que fazer isso em seu próprio tempo.

Em seguida, arraste seus colegas de trabalho e gerenciamento para uma sala e mostre a aparência do desenvolvimento de software no século XXI. Ilustre as falhas com seu sistema atual e mostre como elas são eliminadas com sua nova estrutura.

Você também terá que se posicionar como o Guardião da Fonte - já que você parece ser o único que se importa, cabe a você forçar as pessoas (com qualquer meio técnico ou psicológico à sua disposição) para manter o plano. Certifique-se de que a coisa somente enviada para um cliente tenha vindo de uma máquina de compilação sem controle de origem. Ritualmente humilhar as pessoas que quebram as regras e causam estragos. Suborná-los com donuts ... o que funciona.

Se tudo isso parece muito esforço, então (como já foi dito em quase todas as outras respostas) - arranje outro emprego. Eles não valem o seu tempo.

Este é um bom exemplo de um projeto em que práticas ruins foram usadas de forma tão abrangente que se torna praticamente impossível consertá-lo. Consertar isso exigiria um congelamento, então tudo pode ser limpo sem interrupção. Infelizmente, esses projetos geralmente são (por razões óbvias) muito problemáticos para serem congelados por vários meses, bugs críticos devem ser corrigidos a cada dois dias.

Você pode ficar tentado a gastar o projeto para criar uma versão limpa, enquanto a versão suja é tratada com essas correções diárias de erros; mas o resultado mais provável é que depois de vários meses, quando a versão "limpa" está terminada, ninguém pode dizer quais correções de bugs e alterações foram incorporadas desde a bifurcação (porque a mesma mentalidade que deixa as pessoas adotar tais práticas torna improvável que eles mantêm registros sobre as mudanças que fazem). A versão limpa está desatualizada, a versão suja ainda funciona, então o que acontece? A versão limpa é descartada, o naysays provou certo.

Passo 1 - fogo gerente incompetente!

Se você não conseguir executar a etapa 1, tente fazer com que o gerente limite a implantação de prod a somente scripts tirados do controle de origem. Se os desenvolvedores (que não devem ter direitos de produção sobre prod, consulte a etapa 1, se quiserem) quiserem que seus materiais sejam implantados, eles precisam vir do controle de origem. Isso resolveu nossa questão de não usar o controle de origem muito bem de volta quando começamos a usá-lo para material de banco de dados, bem como código C #.

Como alguém pode não querer versões diferentes de seus arquivos e a capacidade de ver as diferenças? Esqueça ramificação e qualquer uma das coisas complexas. Eles nem conseguem o básico. Modificar diretamente um arquivo de produção sem fazer a alteração mais rudimentar em um ambiente de teste é insano. Eu trabalhei com algumas pessoas e felizmente nunca trabalhamos nos mesmos projetos.

Seus colegas de trabalho são burros demais para serem preguiçosos. Isso é uma perda de tempo. Tudo o que você pode esperar é treinar seu gerente. A gerência deve gostar do controle de origem porque gosta de todas as formas de controle. Faz com que eles se sintam importantes. Aparafuse os outros; consertar o líder é sua única esperança, já que você não pode substituí-lo. Comece a trabalhar em rede com outros desenvolvedores competentes e tente fazer com que eles se juntem à sua equipe quando você tiver uma abertura ou peça para contratá-lo em sua loja.

Diferente do óbvio Encontre um novo emprego, acho que a resposta é mais do que tudo acima.

Primeiro, dirija-se à administração para ajudá-los a migrar e impor o uso do controle de origem. Então, chegue ao que precisa ser feito para manter as coisas funcionando, mesmo que isso signifique trabalhar diretamente no servidor. Inicie o processo de obter tudo no controle de origem.

Outra opção é garantir que o mais recente esteja no servidor (o que você precisa fazer independentemente) e iniciar um novo repositório a partir do mais recente. Você vai perder a história, mas neste momento isso é pequenas batatas.

Parece, a partir de sua descrição, que há um ou mais problemas com a situação - ou a equipe de desenvolvimento está fora de controle ou uma solução de controle de origem incorreta foi implementada. De qualquer maneira, cabe à equipe de desenvolvimento usar alguma solução de controle de origem - modificar diretamente o código-fonte no serviço de produção é apenas implorar que os problemas aconteçam.

Da minha experiência, a primeira etapa que deve ocorrer imediatamente é sincronizar o controle de origem com o servidor de produção. Essa etapa pode ser tão simples quanto tomar uma cópia do código de produção e fazer o check-in - o código de produção é presumivelmente a base que sua equipe está desenvolvendo. Essa etapa pode precisar ser aumentada por uma mesclagem com código flutuando no sistema de controle de origem existente. O código deve fluir de dev para integração / QA (ou ambos) e, em seguida, para estágio ou estágio / produção.

Em seguida, o gerenciamento precisa exigir o uso do controle de origem. Muito simplesmente, se a compilação não veio do sistema de controle de origem, o código não deve ser implantado na produção. O acesso de produção precisa ser limitado apenas à equipe de suporte, com acesso limitado ao dev para solucionar problemas de produção. Em geral, os desenvolvedores nunca devem executar implementações de código a quente na produção - problemas de produção podem definitivamente acontecer, especialmente se os desenvolvedores estiverem sob pressão.

O gerenciamento definitivamente precisa lidar melhor com os problemas aqui - será quase impossível sustentar o desenvolvimento se o código for aplicado diretamente ao prod (e não entrar no controle de origem).

O verdadeiro problema não é que os codificadores cowboys não usem o controle de versão. O problema real é que eles já escolheram alguma maneira de fazer as coisas e você está tentando mudar o processo deles. O processo escolhido não inclui o controle de versão. Todas as mudanças no processo são difíceis, a menos que os próprios programadores percebam um problema. Se existe a sensação de que o sistema existente é bom o suficiente, tentar impor algum sistema diferente é simplesmente fútil. Nós somos o borg, você será assimilado. Claro que eles estão tentando lutar para se tornar borg.

Bloqueie qualquer servidor que não seja o seu desenvolvimento. Use um gerenciador de configuração. Faça construções regulares identificáveis (contra tags). Marque cada conjunto de alterações (ou seja, 1 conjunto de alterações por bug). Nós também colocamos uma tag em cada build. Tenha um sistema do tipo QA entre dev e produção (no mínimo). Faz construções para o sistema de controle de qualidade usando a tag de construção correta. Dê-lhes pena por "quebrar a compilação".

Nunca cheguei a uma situação em que não pudesse recriar / corrigir um problema (que só é exibido na produção). Sim, passei horas tentando recriar o problema em um sistema de desenvolvimento (além disso, quando você descobrir, você poderá adicioná-lo ao seu teste de regressão).

Nós fizemos um projeto com um grupo de empreiteiros de vaqueiros que fizeram todas essas coisas ruins. Eu passo 4 semanas limpando depois e depois coloco as práticas acima no lugar. O projeto não teve problemas com nenhuma dessas coisas desde então.

Para sua própria sanidade, sugiro configurar o Git ou outro DVCS em sua própria máquina para que você possa acompanhar as alterações. Importe as alterações de seus colegas de trabalho em seu repositório com frequência. Resolva conflitos da melhor maneira possível. Isso irá protegê-lo parcialmente da insanidade de seus colegas de trabalho.

Você mencionou que a gerência disse que os desenvolvedores devem usar o controle de origem. Se você quer ser mau, você pode impor isso verificando as alterações no TFS e periodicamente publicando o repositório, assim, sobrescrevendo quaisquer alterações que não estejam no TFS. (Se você também está mantendo seu próprio DVCS, você deve manter os dois sincronizados.) Sua justificativa para isso é que você está seguindo os pedidos da gerência. Se seus colegas de trabalho se cansarem de ter suas alterações substituídas, convide-os a usar o TFS. E continue sofrendo alterações que não foram verificadas. Continue até que seus colegas de trabalho cedam ou você seja demitido.

Citação:

The team is not used to using TFS

O TFS é o Microsoft Team Foundation Server.

Meu primeiro instinto diz: "esta é a última versão do Microsoft Visual SourceSafe"

Eu estaria do lado de vocês colegas de trabalho e seria realmente contra isso.