Pergunta

Por aqui, temos trabalhado com vários repositórios do Visual Source Safe há cerca de 10 anos ou mais.

Agora quero me livrar do sourcesafe e passar para o Team Foundation Server.

Você tem alguma dica ou truque para mim antes de embarcar nessa migração?Quais são as coisas com as quais devo ter cuidado?

Estou certo de que esta migração significará que os nossos hábitos de trabalho terão de ser modificados de alguma forma.Você acha que essas mudanças podem ser um problema para a organização?Pense em um grupo de cerca de 20 desenvolvedores .NET em um único site.

Foi útil?

Solução

Acabei de pesquisar no Google, mas este passo a passo parece uma boa referência e menciona a ferramenta VSSConverter que deve ajudá-lo a tornar a migração o mais simples possível.

Eu gostaria de recomendar uma coisa:Cópia de segurança.Faça backup de tudo antes de fazer isso.Se algo der errado, é melhor prevenir do que remediar.

Meus links não estão aparecendo.Este é o endereço: http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx

Outras dicas

Existem algumas maneiras diferentes de migrar.A ferramenta puxará seu histórico, etc.acabou, mas a maneira mais pragmática e simples é bloquear o VSS como um arquivo de histórico e começar do zero:

  1. Peça a todos que verifiquem todas as alterações no VSS, certifiquem-se de que tudo foi compilado, etc.
  2. Defina todos os bancos de dados VSS como "bloqueados" (direitos somente leitura para todos os usuários)
  3. Obtenha as últimas informações de todo o banco de dados VSS em um conjunto "limpo" de pastas em uma estação de trabalho
  4. Verifique todos os arquivos no TFS da estação de trabalho

Para qualquer histórico anterior à conversão, as pessoas precisam recorrer ao VSS, mas depois de uma ou duas semanas é realisticamente improvável que isso aconteça com tanta frequência.E você sabe que o histórico no VSS é preciso e não corrompido pelo processo de conversão.

Esteja ciente de que o TFS não oferece suporte ao compartilhamento de arquivos entre projetos diferentes, como o VSS faz.Se você tiver algum desses arquivos compartilhados, o link entre eles será quebrado durante a migração, resultando em arquivos inicialmente idênticos, mas agora distintos em cada projeto.As atualizações de um desses arquivos no TFS não serão mais propagadas para as cópias nos outros projetos.

Se você optar por usar a ferramenta VSSConverter.exe fornecida com o Visual Studio Team Foundation Server, deverá instalar TFS 2008 SP1 primeiro, pois inclui uma série de melhorias conforme detalhado neste blog pela equipe de ferramentas de migração.

Alguns dos principais recursos do lançamento incluem:

Eliminação de conflitos de namespace.Anteriormente, escrevi sobre isso como "o problema da renomeação" e corrigimos o conversor para migrar corretamente os arquivos com namespaces sobrepostos.Esse foi o maior ponto de dor para a maioria dos usuários que tentam usar versões anteriores da ferramenta.

Religação automática da solução. Nesta versão mais recente, os arquivos do VS Solution serão atualizados automaticamente para a versão 9.0 e verificados novamente no controle da versão.Anteriormente, os usuários eram obrigados a fazer isso manualmente.

Correção de inconsistências de registro de data e hora.O uso de registros de data e hora do cliente pelo VSS pode levar a revisões que estão sendo registradas na ordem oposta em que eles realmente ocorreram.A ferramenta agora reconhece esse problema e continua migrando alterações onde falharia anteriormente.

Registro aprimorado.Embora tenhamos corrigido muitos problemas, o fornecimento melhor e mais detalhado do log ajudará os usuários que tenham problemas a diagnosticar os problemas.

No momento, estamos no processo de fazer isso no meu trabalho diário.Na verdade, faremos a mudança em cerca de um mês.Sou uma parte importante da migração e uma grande parte do motivo pelo qual estamos saindo do SourceSafe.Para ajudar na migração, usei o Visual Studio® Team System 2008 Team Foundation Server e imagem VPC do Team Suite.Foi muito útil.De cara, a imagem contém uma instalação completa do TFS para você jogar e fazer uma demonstração.Também inclui laboratórios práticos e um dos laboratórios está executando a ferramenta de migração VSS -> TFS.Se você tiver uma assinatura do MSDN, depois de brincar com a imagem, o próximo passo seria instalar a edição TFS Small Team que acompanha sua assinatura.

Uma coisa a observar é certificar-se de obter os Service Packs mais recentes para Visual Studio 2008 e o .NET Framework instalados na imagem.Os service packs corrigiram alguns bugs irritantes e definitivamente aumentaram a usabilidade do sistema.Temos um banco de dados SourceSafe bastante grande com mais de 90 projetos e a ferramenta de migração levou cerca de 32 horas para ser concluída.Primeiro fiz um backup do nosso banco de dados sourcesafe para teste.Depois fiz a migração no banco de dados sourcesafe de teste.Depois, verifiquei a árvore de origem no TFS e tudo foi transferido corretamente.Mantivemos todo o histórico de nossos arquivos de origem do VSS, o que foi ótimo.Não há necessidade de manter aquele banco de dados VSS fedorento depois de entrarmos no ar.

Estamos realizando a migração em etapas.Primeiro, o controle de origem e permitir que nossos desenvolvedores se acostumem a usá-lo.Depois disso, migraremos os analistas de controle de qualidade e de negócios para usar os recursos de rastreamento de itens de trabalho.

Meu conselho é realizar a migração em etapas.Não faça muito de uma vez.Dê tempo para as pessoas que usarão o sistema treinarem.

VSS Converter está longe de ser uma solução perfeita.E há diferenças significativas entre as versões 2005 e 2008SP1 do conversor.

Por exemplo, em um banco de dados VSS que está em uso há muito tempo, haverá um grande número de usuários contribuindo para o VSS.Muitos desses usuários já terão saído da organização há muito tempo e, portanto, não terão mais contas de domínio.O TFS exige o mapeamento de usuários VSS para contas de domínio, portanto, você terá que decidir se mapeia usuários antigos para uma única conta de domínio “fictícia” ou para um membro atual da equipe.

Além disso, o VSS Converter 2008 exige que essas contas de domínio sejam contas TFS válidas.Considerando que o conversor de 2005 não impõe isso.

Se o seu histórico VSS contiver movimentações de pasta significativas, é provável que você perca todo o histórico antes dessa movimentação.Por exemplo, se você mover uma pasta para um novo local e excluir o pai anterior, perderá todo o histórico.Veja este artigo para mais explicações:http://msdn.microsoft.com/en-us/library/ms253166.aspx

Em uma migração na qual estive envolvido, tínhamos um banco de dados VSS de 10 anos que perdeu todo o histórico há 6 meses.Isto ocorreu devido a uma limpeza significativa que ocorreu há 6 meses.

Ferramenta de conversão TFS <-- Use isto

Já usei essa ferramenta algumas vezes, os resultados são bastante satisfatórios, pois ela vem com o histórico de conjuntos de alterações do SourceSafe, se desejar também.

De qualquer forma, usando esta ferramenta você deve sempre prestar atenção aos erros e avisos no log, e verificar se tudo construído está bem/passou bem.

É recomendado também executar uma análise no SS antes de executar isso.

Espero que ajude

Boa orientação do meu ex-colega Guy Starbuck.Outra coisa a acrescentar a essa abordagem - você pode ter decidido ao longo do tempo que deseja refatorar a forma como seu aplicativo é organizado (pastas, etc.) e isso lhe dará a oportunidade de fazê-lo.

Já estive em situações em que organizamos uma solução ao acaso, sem pensar (sem pensar em grandes mudanças no aplicativo), o que levou ao desejo de organizar as coisas de maneira diferente - e a mudança do VSS para o TFS é uma grande oportunidade para fazer isso.

Quanto à pergunta original:

E:esta migração significará certamente que os nossos hábitos de trabalho terão de ser modificados de alguma forma.Você acha que essas mudanças podem ser um problema para a organização?Pense em um grupo de cerca de 20 desenvolvedores .net, em um único site

Eu diria - sim, seus hábitos de trabalho mudarão, mas muito mais para melhor.

  1. Você não deve usar bloqueios de "Check-out" e "Get-Latest on Check-out".
  2. Agora você pode efetivamente ramificar e mesclar
  3. Agora você terá "Changesets" e todos os arquivos com check-in ao mesmo tempo serão agrupados.Isso torna o rastreamento de alterações históricas muito mais fácil - mas o mais importante é que as reversões são muito mais fáceis (ou seja, encontrar todos os arquivos com check-in ao mesmo tempo e revertê-los)
  4. Associando Check-ins a Itens de Trabalho.Não negligencie os itens de trabalho!O maior erro que você pode cometer é usar o TFS apenas como substituto do VSS.Os recursos de gerenciamento de construção e projeto são excelentes - você pagou por eles - USE-OS!

Quanto aos detalhes sobre como sua experiência mudará, outro ex-colega meu (e MVP do Team System) Steve St.Jean escreveu um artigo detalhado sobre as diferenças: Do VSS ao TFS

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top