Quantificando as vantagens de um sistema moderno de controle de versão [fechado]

Trabalhei como líder de equipe / desenvolvedor em um grande ambiente empresarial financeiro por quase três anos. Nosso processo de liberação da produção é um pesadelo, porque gira em torno do Clearcase. Temos um grupo de gerenciamento de mudanças que executa todas as liberações e que permitirá apenas o código na produção que foi retirado dele.

Uma das primeiras coisas que fiz ao ingressar foi montar minha equipe com o Git. Todos concordaram que o Clearcase era péssimo e não era prático para lidar com questões cotidianas de controle de fontes. Por isso, configuramos uma espécie de repositório "não oficial" na minha máquina local e eu escrevi um script para sincronizar nossos repositórios git e Clearcase por volta do momento do lançamento.

A notícia disso se espalhou para outras equipes e várias adotaram o mesmo processo. Usando o git de maneira "não oficial" para as atividades do dia-a-dia e "oficialmente" usando o Clearcase para lançamentos. Eu me tornei uma espécie de ir para o cara por quaisquer problemas com o Git.

Então, eu tenho uma reunião esta semana com o SVP em mudança de infraestrutura, que quer especificamente que eu explique a ela os méritos do Git. Aparentemente, chegou a notícia dos meus frequentes discursos no Clearcase. Se ela aceitar meus argumentos, terei uma chance real de ajudar meu empregador a se livrar dessa abominação.

Minha experiência com executivos me diz que eles: a) querem explicações extremamente concisas para tudo; b) só estão interessados ​​em fatos que envolvam números em dólares

Para um desenvolvedor, posso explicar os méritos do Git sobre o Clearcase (ou QUALQUER outro sistema de controle de versão sobre o Clearcase), mas estou deixando um espaço em branco sobre como fazer isso com um executivo técnico sem formação técnica (ela tem um MBA e graduação em geografia).

Sinto que qualquer argumento que apresento parecerá algo sem sentido técnico ou que estou evangelizando minhas preferências pessoais.

O que estou tentando encontrar são fatos concretos que demonstram que os desenvolvedores trabalham mais efetivamente com o Git, ou QUALQUER sistema de controle de origem moderno.

Eu acho que o fato de as outras equipes terem começado a usar o Git internamente é um sinal significativo, mas ainda não é forte o suficiente, porque ainda pode ser descartado como preferência pessoal.

O que eu realmente preciso é de algo poderoso o suficiente para interromper o processo "Este processo funcionou por 20 anos, por que devemos mudar?" argumento.

Eu já estive em situações muito semelhantes (nas indústrias aeroespacial e automotiva). Não espere progredir muito nesta reunião ou nas seguintes. Ambas as situações superaram meu desejo de continuar lutando por melhorias, mas aqui está a melhor tática que eu já vi até agora ...

Você diz "esse processo funcionou por 20 anos", mas realmente? Comece descrevendo o que você quer dizer com "nosso processo de lançamento de produção é um pesadelo". Crie uma lista de problemas com o processo / ferramenta atual que seja o mais independente possível do ClearCase.

Em seguida, crie uma lista de "soluções" de processo / ferramenta que sejam o mais agnósticas do Git possível (embora o Git ou qualquer DVCS moderno se encaixe exatamente na conta). Explicar por que o Git é melhor que o ClearCase não significa nada para não usuários.

Permita que a equipe de infraestrutura confirme se a abordagem atual tem os problemas que você identifica. Isso provavelmente os levará a procurar suporte da IBM para "corrigir" esses problemas. Permaneça conectado para garantir que a IBM não evite os problemas. Como o ClearCase não possui as propriedades básicas de nosso entendimento moderno do controle de versão, a maioria desses problemas não pode ser corrigida ou exigirá uma grande alteração na infraestrutura.

Esperamos que, nesse ponto, a equipe de infraestrutura veja isso como um problema de negócios, mas sem uma solução fácil. Neste ponto, você oferece a comparação de soluções adicionais com custos estimados. Como muitas de suas equipes já estão usando o Git, você poderá remover o treinamento como uma despesa.

Boa sorte!

Nosso processo de liberação da produção é um pesadelo, porque gira em torno do Clearcase. Temos um grupo de gerenciamento de mudanças que executa todas as liberações e que permitirá apenas o código na produção que foi retirado dele.

Não, seu processo é um "pesadelo" devido ao seu grupo de gerenciamento de alterações e aos procedimentos de liberação. Vá em frente e substitua o Clearcase por SVN ou git ou Fossil. Você terá exatamente os mesmos problemas . (Eu acho que eles estão fazendo certo TBH, controles de liberação fortes são essenciais).

É nisso que você precisa se concentrar, não nas credenciais nerds do git (que são irrelevantes para todos, exceto os desenvolvedores); você precisa se concentrar no caso de negócios para alterar o processo para torná-lo menos oneroso. Provavelmente, você pode fazer isso usando o Clearcase, mas oferece a oportunidade de ocultar a ideia de usar o git de qualquer maneira.

Se você não olhar para a "imagem maior" aqui, o melhor caso será usar o git com as mesmas restrições que o grupo de lançamento exige. Se você considerar os aspectos mais amplos do que é o controle de alterações, apreciará as restrições que precisará implementar para tornar o git útil no tipo de processo fortemente controlado que sua organização precisa.

Algumas idéias para você: Faça com que eles vejam os problemas de produtividade com o sistema atual do ponto de vista do desenvolvedor. Faça isso como parte 1 de 2. Parte 2, trabalhe com eles em uma liberação para poder ver os problemas de controle que os desenvolvedores precisam entender. Trate-o como um exercício de aprendizado para os dois lados verem a visão do outro lado e, em seguida, você poderá encontrar uma solução que ainda resolva os principais requisitos de ambos os lados. Observe que os lançamentos são mais importantes que o dev, portanto, você deve estar preparado para dar mais terreno do que espera.

Depois de ter o conhecimento do que é necessário para as liberações, você deve concordar em escrever um documento do processo detalhado (com o tipo de detalhe das etapas a seguir) que pode mostrar a eles, dando o que eles precisam. Como você pode massagear isso para que o lado do desenvolvedor seja melhor para você, é com você. Eu imagino que eles realmente não se importam com o quanto o dev dev, desde que a fonte seja gerenciada adequadamente e os lançamentos sejam organizados corretamente - isso significa que você terá que mostrar como as alterações de código podem ser vinculadas aos tickets de alteração, como usar o código criado uma versão para corrigir, compilar e relançá-la.

Exemplos específicos impressionarão mais do que vantagens abstratas. Acho que você terá mais sucesso se puder documentar exemplos específicos em que (a) o Clearcase causou problemas que levaram tempo para resolver e (b) o Git resolve esses problemas. Lembre-se de que você não precisa entrar em detalhes técnicos sobre por que isso é assim (a menos que solicitado) simplesmente mostre que é; a gerência não precisa conhecer os detalhes técnicos, é para isso que você paga.

Se você pode anexar prazos e datas específicas a esses exemplos, melhor. Você também pode concluir isso, mostrando que a tarefa X que você faz muito leva Y minutos no Clearcase e Z minutos no Git.

Lembre-se de que tempo é dinheiro; portanto, se você pode mostrar que trabalhar com o Git é mais rápido, pode mostrar que também fará sentido financeiro.

Aqui está uma tentativa de como eu tentaria isso.

Isso pode parecer estúpido para um desenvolvedor, mas para o gerenciamento, as mudanças tecnológicas são vistas como arriscadas.

"Se a coisa mágica já funciona, por que correr o risco de quebrá-la?"

Assim, você tem que virar a mesa. Torne mais arriscado não mudar para o git. A todo custo, não faça parecer que é um brinquedo novo.

Eu começaria dizendo que o git agora é amplamente usado. Use números como esses: http://ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/

Para um gerente, isso implica que eles devem ser capazes de encontrar muitos desenvolvedores usando o git. E todo um ecossistema de ferramentas de terceiros (ouvi dizer que até a Microsoft integra o git ao visual studio agora).

Além disso, um gerente não pode ser responsabilizado por seguir as principais coisas, não é? Por outro lado, quem usa $ other_cvs aqui?

Coloque ênfase em como os grandes projetos estão usando, porque é simples, rápido, flexível, poderoso ... Encontre grandes projetos com grandes nomes anexados (GNU / Linux, Google, Microsoft ...) que usam o git.

Tendo demonstrado que não pode ser uma má jogada, você pode continuar como isso melhoraria as coisas no seu caso.

Você quer que a empresa permaneça competitiva e não se deixe enganar por equipes mais rápidas e ágeis, certo? Eu tentaria encontrar algumas estimativas internas (escritas) sobre como a produtividade mudou usando o Clearcase vs Git. Você pode usar alguma ajuda de seus colegas desenvolvedores lá. Em seguida, extrapole para toda a empresa (ou seja, todos os desenvolvedores de software), com números e custo estimado para permanecer no Clearcase.

Se necessário, recapitularia tudo em um e-mail escrito após a reunião (inclua as pessoas certas).

O que eu realmente preciso é de algo poderoso o suficiente para interromper o processo "Este processo funcionou por 20 anos, por que devemos mudar?" argumento.

Esse é um argumento inválido (as carruagens puxadas a cavalo "funcionam há séculos", mas você provavelmente deseja comprar um carro).

Eu ouvi o mesmo argumento sobre svn vs. mercurial (fui eu que usei mercurial no meu sistema de desenvolvimento).

Esse problema não é sobre a substituição do que funciona; Não tente defini-lo como tal, e se esta é a pergunta que você precisa "derrotar", você deve começar apontando que não é uma questão do que funciona ou não - mas uma questão das vantagens que você tem com o git , quando ambos funcionam (e por que o git funciona melhor).

Bons argumentos para usar o git:

• O git é centrado no changeset, em vez do centrado no arquivo. Isso significa que as alterações são mais fáceis de rastrear arquivos entre os mesmos (rastreabilidade entre os projetos).

• o git é distribuído em vez de centralizado; Isso significa que o check-in não é limitado pela velocidade da rede - economizando muito tempo, novamente. Isso também significa que você não possui um ponto único de falha no caso do servidor ClearCase ficar inativo.

• por causa de seu sistema de ramificação, o git minimiza a necessidade de mesclar (ou seja, você não mescla arquivos em cada check-in, mas em todos os recursos concluídos). Você muda da solução de conflitos de mesclagem (se houver) algumas vezes por dia (em cada confirmação) para uma ou duas vezes por semana (em todos os recursos concluídos). Isso significa mais tempo de desenvolvimento para seus desenvolvedores (algo que os gerentes desejam maximizar).

Eu acho que o fato de as outras equipes terem começado a usar o Git internamente é um sinal significativo, mas ainda não é forte o suficiente, porque ainda pode ser descartado como preferência pessoal.

Você pode salientar que a diferença qualitativa é tão grande que os desenvolvedores em toda a sua empresa preferem as complicações de instalar, configurar e usar o git, em cima do Clearcase, por seus recursos extras. Na verdade, é um argumento forte (se não proporcionasse uma experiência ao usuário e um conjunto de recursos melhores, as pessoas não se esforçariam para usá-lo - especialmente porque é algo que não é exigido pela empresa).

Então, eu tenho uma reunião esta semana com o SVP em mudança de infraestrutura, que quer especificamente que eu explique a ela os méritos do Git.

Desenhe um gráfico representando confirmações com os dois sistemas e mostre a racionalização obtida pelos desenvolvedores que não confirmam publicamente (ou seja, se você copia um arquivo, o resto da equipe não fica bloqueado e não consegue compilar até que você o conserte). Explique também os controles extras de qualidade que você pode fazer quando pode fazer confirmações intermediárias sem afetar mais ninguém, o fato de que você pode obter diferenças limpas por recurso (essencial para revisões de código).

O que eu realmente preciso é de algo poderoso o suficiente para interromper o processo "Este processo funcionou por 20 anos, por que devemos mudar?" argumento.

É difícil realmente julgar o que seria um bom argumento sem ser uma testemunha da cena. Mas tentarei ajudá-lo a estruturar seus argumentos para que possam ser ouvidos.

Presumo que seu público tenha um nível de conhecimento não especializado sobre o tema e tenha interesse em continuar no curso atual. Eles têm preocupações e responsabilidades diferentes e podem sofrer sérias conseqüências se algo der errado, então você terá que trabalhar com essa mentalidade. Antecipe algumas das perguntas ou preocupações que possam ter:

• Que novos recursos isso traria? Existe algo que atualmente não podemos fazer, que gostaríamos de fazer e que essa nova coisa nos permitiria? Comece com uma nota positiva.

• Qual o impacto nas agendas de lançamentos? Qual é o custo da implementação dessa alteração no próximo lançamento imediatamente? Quais são os custos e benefícios para os seguintes lançamentos?

• Isso implicará uma mudança no processo? Diferente do cronograma de lançamento, essa mudança exigirá que as pessoas no processo de lançamento mudem de maneira? Isso será transparente para eles ou eles precisarão se adaptar? Você precisará cooperar com outros departamentos? As pessoas são resistentes à mudança.

• Existem perigos iminentes para se manter no sistema atual? O processo atual possui dependências de software ou hardware que foram encerradas ou que expirarão em breve? Depende do conhecimento especializado de indivíduos que aumenta os custos de contratação? Possui um potencial furo de segurança que o novo sistema soluciona (pontos de bônus se esse buraco puder levar a uma ação legal)? Não acene manualmente ou 'talvez' ou 'provavelmente' isso: a sensação é de que funcionou bem por 20 anos; portanto, o ônus da prova está no defensor da mudança.

Além disso, seja específico sobre problemas e soluções . Se você não encontrar exemplos específicos, use estimativas honestas da sua posição como especialista. Exemplos de outras empresas / departamentos / entidades que adotam essa mudança, de preferência do seu setor, e sua avaliação dessa mudança, o ajudarão. (Não escolha exemplos que tenham tido algum tipo de problema de TI divulgado nos últimos anos, caso contrário você poderá provar que essa mudança não foi a causa.)

Você pode encontrar esta resposta para convencer a empresa em que trabalho a implementar o controle de versão? útil.