Método para integrar vários sistemas de controle de versão ou escolher um sobre outros, devido a fusões e aquisições?

11

As empresas adquirem outras empresas que usam diferentes sistemas de controle de versão.

Existe uma sabedoria comum sobre como integrar esses sistemas juntos, por exemplo, usando uma ponte Subverson-GIT ou até mesmo decidir usar apenas uma ferramenta sobre outra - e como migrar entre sistemas?

As pessoas usam um conjunto de critérios para essa tomada de decisão, por exemplo, um equivalente ao teste "Joel" no desenvolvimento de software?

version-control migration therobyouknow
fonte

Respostas:

11

Para responder à pergunta de migração da experiência pessoal de várias migrações:

Não tenha medo de colocar a versão atual do software no novo sistema de controle de origem como linha de base e trabalhar a partir daí.

Na grande maioria das vezes você não precisará da história. Isso significa que é uma tarefa a menos a ser executada durante a integração e menos uma coisa a dar errado.

Arquivos / projetos que estão sendo desenvolvidos ativamente em breve irão gerar um novo histórico. Portanto, quando você precisar descobrir por que uma alteração foi feita, é provável que o histórico esteja no repositório atual, pois será uma alteração recente.

Os arquivos / projetos que estavam estáveis ​​antes da migração (todos os itens são iguais) permanecem estáveis ​​após a migração, para que você não precise consultar o histórico. Descobrimos que, se tivéssemos que investigar um bug em um arquivo / projeto tão antigo, ter o histórico não teria nenhum benefício. Contanto que você mantenha o repositório antigo disponível por 6 meses / ano, você terá a referência nesses casos.

ChrisF
fonte
+1 de ponto justo, migre apenas o que você precisa, deixe as versões antigas no repositório anterior herdado. Não migre por si só. Essa abordagem é uma variação da abordagem da escolha entre organização e pesquisa. Se a pesquisa conseguir o que você deseja rapidamente, sempre não será necessário organizar o que você procura.
Therodyouknow
1
+1 da OMI a melhor estratégia. Continue usando apenas um, os outros no modo somente leitura, por precaução.
user281377
1
+1: resposta mais precisa da parte da migração.
VonC
1
+1 - difícil o suficiente para entender o código existente e muito menos as três últimas versões.
JeffO
1
Convertemos muitos repositórios CVS para SVN usando o script cvs2svn, que funcionou muito bem. Eu nunca me lembro de alguém olhando a história além das 'mudanças recentes', então isso realmente não valia o espaço em disco. Se eu fizesse novamente, basta marcar o repositório CVS, marcar como SVN como novo e marcar o repositório CVS como somente leitura.
precisa saber é o seguinte
4

No lado gerencial, é principalmente uma questão de:

  • suporte : a empresa que está liberando o VCS ainda estará lá em caso de problemas.
    Infelizmente, é uma das principais razões pelas quais produtos obsoletos como o ClearCase ainda são considerados (o ClearCase é desde 2003 um ... produto IBM )
  • custo de licença : mesmo que haja alternativas de freeware, algumas vezes "licenças de grupo" para um VCS podem ser negociadas ou realmente incluídas em um contrato muito maior, incluindo servidores, redes, suporte, etc ... Uma licença global para esse tipo de produto pode terminar custando muito menos do que o preço público.

No lado do projeto, é também uma questão de:

  • administração : em qual servidor você instalará um VCS (ou muitos VCS, se estivermos falando sobre Git, SVN e outros)? Com qual política de backup? Qual DRP (Plano de Recuperação de Desastre)?
  • suporte local : quem receberá o suporte de nível 1? nível 2?
  • conhecimento de mercado : você tem certeza de encontrar desenvolvedores e / ou administradores suficientes com o conhecimento adequado para alavancar esse VCS e todos os seus recursos?

Com freeware ou não, lembre-se de que um software "gratuito" é gratuito como em "liberdade de expressão" (você pode escolher e implantar o que deseja), não como em "cerveja grátis" (ainda custará muito dinheiro no servidor , backup, administração, suporte, ...)

Os critérios mencionados acima são um começo para determinar quais VCS manter e o que abandonar.
Mas neste último caso, você precisa considerar:

  • estratégia de migração : você pode exportar / importar um histórico de projeto de um VCS para outro?
  • estratégia de bridge : faz sentido ter uma história em dois VCS diferentes?
  • obsolescência do projeto : se um projeto estiver no status de manutenção / fim da vida útil, talvez seja melhor oferecer suporte a um VCS antigo por um curto período de tempo.
VonC
fonte
Com uma boa resposta, os marcadores descrevem os critérios que estou procurando e suas explicações com eles também ajudam. Vou dar uma chance aos outros antes de aceitar uma resposta. Obrigado.
Therobyouknow
1

Você realmente precisa integrar sistemas diferentes? Em nossa equipe, cada projeto vive em seu próprio repositório e, portanto, suas histórias são independentes. Não temos nenhum problema aqui para trabalhar com alguns projetos em subversão e outros em mercurial, mesmo se houver dependências entre eles.

Se você optar por migrar de um VCS para outro, observe as ferramentas de conversão disponíveis. Pela minha experiência, não há razão técnica para descartar a história dos projetos.

Editar

Acho que entendi algo implícito na pergunta e em outras respostas. É o fato de que os VCS também são usados ​​para gerenciar dependências. Eu sei que é bastante comum usar recursos de VCS, como svn:externalsintegrar um repositório (a dependência) a outro.

Acho que a razão (técnica) pela qual nossa equipe não sente a necessidade de conectar (ou integrar) nossos 2 sistemas diferentes é que temos uma ferramenta separada para gerenciar dependências. Nosso repositório não se conhecem.

barjak
fonte
Necessidade de integrar diferentes sistemas? Sim, se o trabalho de uma equipe for usado por outra equipe. A integração pode ser difícil ou perder, dependendo do nível de necessidade e de recursos da equipe disponíveis. Não, se os projetos forem completamente independentes. A única preocupação restante é apoiar mais de um sistema e se isso é percebido como bom ou ruim. Bom se aceitarmos que vivemos em um mundo da computação variado ou ruim se pensarmos que devemos nos concentrar e mostrar determinação por si mesmos, escolhendo uma ferramenta que possa ser excessivamente solipstística!
therobyouknow
PS. +1 Sorte sua, barjak, por estar em uma organização que tolera um ambiente de computação variado.
Therobyouknow
0

Muitas boas respostas. Outra coisa a se pensar é não deixar que os membros da equipe se acostumem a pensar em mudar o VC. Haverá um revés com a migração, uma curva de aprendizado etc., mas se tiverem muitos problemas, eles deverão questionar seu nível de habilidade e / ou cooperação.

JeffO
fonte
+1 Um realismo aqui. As pessoas precisam manter a calma, ser corajoso e prosseguir. Os riscos precisam ser bem definidos. Um aprendizado que estou vendo e ouvindo outras pessoas dizerem no meu local de trabalho é que às vezes não trabalhamos o suficiente para reduzir a incerteza / definir claramente os riscos / contigências antes de nos envolvermos. Parece que há tempo de sobra para a iteração de errar / corrigir, mas não há tempo suficiente para fazê-lo da primeira vez. A correção de problemas é recompensada e vista como atividade em andamento, mesmo que algumas vezes elas fossem desnecessárias.
Therobyouknow
1
Isso depende dos VCS em questão e quão bem a migração é feita. Mudar do Git ou mesmo do CVS para qualquer VCS bloqueado será extremamente chocante.
David Thornley