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


24

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.


4
Eu acho que você os está julgando se acha que eles estão interessados ​​apenas em fatos com números em dólares. E eles podem querer explicações concisas, porque explicações detalhadas podem induzi-las a algo que não entendem. Talvez a melhor abordagem seja fornecer uma lista de coisas boas que o Git tem, mas o ClearCase não. No entanto, sinto que os executivos do ambiente corporativo não confiam no software de código aberto, especialmente se houver uma versão corporativa bem estabelecida.
InformedA


2
Demonstre quanto mais o uso do git torna você (e as outras equipes) eficaz no cumprimento de suas tarefas. Não faça a substituição voluntária do ClearCase sem ouvir o caso, mas mostre onde estão os benefícios do dia a dia. ClearCase pode ser necessário para construir auditoria ou Tracking Project questão ampla que Github não é forte no.
Kevin

3
Se eles estiverem interessados ​​em dólares, mostre a eles as taxas anuais de licenciamento do ClearCase e a equipe que você precisa pagar para mantê-las.
17 de 26

3
"retido como primariamente baseado em opiniões" Eu discordo muito disso. Da minha pergunta "O que estou tentando encontrar são fatos concretos que demonstram que os desenvolvedores trabalham mais efetivamente com o Git". Qual é a opinião baseada nisso?
Mike

Respostas:


22

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!


Nota: O ClearCase não tem 20 anos.
Jan Hudec

2
Acho que você não encontrará nada que não possa ser feito com o ClearCase. Mas muitas coisas serão muito mais complicadas com o ClearCase e, mais importante, lentas como o melaço . Felizmente fazer as coisas mais rápido é um argumento a maioria dos gerentes vai aceitar.
Jan Hudec

10
@JanHudec, o lançamento inicial do Rational ClearCase ocorreu em 1992, completando 22 anos.
Private_meta

@private_meta: Hm, não sei porque me lembrei de 1998.
Jan Hudec

14

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.


Bem, talvez o maior problema com o ClearCase seja que ele é lento como melaço. Portanto, se o processo for complicado (e pode haver uma boa razão para isso), mudar para algo mais rápido melhoraria.
Jan Hudec

11
@JanHudec Lembro-me do Clearcase ... não foi tão lento onde eu trabalhei, mas talvez seja um daqueles produtos em que o repositório é colocado em um servidor em um datacenter corporativo distante, cercado por muitas camadas de segurança e roteamento. Eu acho que o OP teria uma chance melhor com SVN ou TFS do que com o git, mas não é com isso que ele se concentra.
Gbjbaanb

3
O ClearCase é basicamente um sistema de arquivos de rede com controle de versão. Portanto, a largura de banda da rede e, especialmente, a latência são muito importantes. Com a réplica local, a maioria das operações era suportável (mas ainda muito mais lenta que no git, projetado para velocidade), mas algumas operações eram horríveis. O pior que fiz foi rotular todos os arquivos para lançamento, o que levou 15 minutos e não foi um projeto excepcionalmente grande.
Jan Hudec

11
+1 por apontar que é um problema de "pessoas" e não de tecnologia.
Kdgregory 6/08/14

11
O maior pesadelo que tive com o clearcase foi que, como o CVS, ele somente fazia a versão no nível de arquivo individual; significando problemas de mesclagem / etc resultaria na versão mais recente no CC para se tornar uma compilação quebrada e na incapacidade de reverter uma base de código inteira para uma data / hora arbitrária. O uso da opção para fazer uma exibição local em vez de uma unidade de rede virtual reduziu bastante a dor da latência de E / S.
Dan Neely

6

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.


3

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).


11
Se eles têm um departamento de lançamento dedicado, quase certamente não dão importância a nenhuma "equipe mais rápida e ágil". Eles provavelmente também não se importam com a produtividade do desenvolvedor. Eles se preocupam com a confiabilidade, a rastreabilidade das alterações e o controle do que acaba no lançamento.
Gbjbaanb

@gbjbaanb bom ponto, no entanto, eu não vi como argumentar sobre isso em uma discussão com um gerente quando outro CVS já está sendo usado.
nha

1

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).


3
O gerenciamento não técnico provavelmente não se importará com esses argumentos.
jcm

11
O problema de trazer pontos específicos de comparação é que você precisa conhecer as alternativas extremamente bem ou será rasgado. No caso dessa resposta, o único ponto válido é o "distribuído versus centralizado", e mesmo assim você precisa estar preparado para "você quer dizer que todo funcionário possivelmente descontente tem todo o repositório de origem em seu laptop?!?"
precisa saber é

2
@kdgregory Todo funcionário insatisfeito também possui vários arquivos zip e repositórios pessoais do código, porque o ClearCase é muito lento e complicado para trabalhar em 100% do tempo. :-)
Jace Browning

@kdgregory e eles entrarão no "você pode fazer o check-in sem que ele vá para o servidor; e se o seu PC travar, você perderá todos os seus check-ins. Onde estão os backups? como controlamos um único fluxo de fontes para criar cada liberar de? "
Gbjbaanb

1

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.