Ricardo Serradas

Bom dia pessoal.

Hoje o que me fez elaborar mais um post não é uma novidade muito agradável.

Em testes que estava fazendo no provider do TFS (que postei sobre ele dias atrás), encontrei problemas quando temos um cenário em que ainda se faz necessário o uso do Source Safe.

Após a instalação do provider, não foi possível voltar a usar o Source Safe novamente através de um Switch de fontes de código amigável na IDE do Visual Studio 2003.

Para poder usar o VSS novamente sem desinstalar o Provider do TFS, foi necessário modificar a chave de registro “ProviderRegKey” que se encontra em:

[HLM\Software\SourceCodeControlProvider\ProviderRegKey]

O novo valor atribuido tem que ser o caminho de registro do Source Safe, que por default é:

“Software\Microsoft\SourceSafe”

Este valor pode ser encontrado na chave “Microsoft Visual SourceSafe”, contida em:

[HLM\Software\SourceCodeControlProvider\InstalledSCCProviders]

Se quiser voltar a usar o TFS Provider, basta voltar o valor da chave “ProviderRegKey” para o mesmo valor da chave “Microsoft Team Foundation Server MSSCCI Provider”, encontrada na localização informada logo acima.

Abraço galera.

Ricardo Serradas

Algo que causa muita preocupação e muito planejamento em empresas que pensam em migrar do VSS para o Team Foundation server é justamente a migração do código-fonte.

Há os que pensam que vão perder o histórico, outros que vão ter que recolocar os fontes no sourcecontrol manualmente, e por aí vai. O legal é destacar que o TFS conta com uma ferramenta chamadaVSSConverter, que colabora com essa migração.

Esta ferramenta transporta entre as plataformas os arquivos, pastas, histórico de versões e informações de usuários. É claro que algumas informações não são compatíveis entre o VSS e o TFS e não serão transportadas. Abaixo, veremos um overview de uma preparação de migração e falaremos de mais detalhes.

Para que possamos continuar com o assunto, é importante ter instalado as ferramentas abaixo na máquina em que você pretende rodar a ferramenta de conversão:

• Team Explorer
• Permissão de administrador na máquina
• SQL Server Express
• Visual Source Safe 2005 ou superior
• A base do VSS que você quer analisar. O formato da base deve ser 6.0 ou superior. Você deve rodar o conversor na mesma máquina em que se encontra sua base.
• Você precisa também da senha de administrador da base do VSS.

Preparando a base do VSS

Antes de começarmos…

- Peça a todos os usuários para fazer check-ins em seus arquivos
- Crie um backup da base que vai migrar
- Use a ferramenta de análise do VSS para localizar e resolver problemas de integridade de dados na sua base.

Analisando os projetos…

VSSConverter.exe é um utilitário de linhas de comando que precisa dos seguintes parâmetros:

• Um caminho para a pasta que contém o arquivo srcsafe.ini da base que está migrando
• Um arquivo XML que contém configurações
• VSSConverter está em [raiz]:\Arquivos de Programas\Microsoft Visual Studio 9.0\Common7\IDE\ e pode ser chamada através do utilitário de linha de comando do Visual Studio.

Vamos imaginar que sua base do VSS esteja em C:\VSSDB.

Depois que você decidiu que projetos da base vai analisar, é preciso criar um arquivo que contenha as configurações. Este arquivo é a lista de projetos que você quer migrar.

Para criar o arquivo de configurações…

• Vamos criar um diretório para trabalhar com nosso arquivos. Eu criei o C:\VSS2TFS
• Dentro dele, crie o arquivo settings.xml e abra-o com o Notepad.
• Copie o XML abaixo e cole dentro do arquivo, onde $\PastaA e$\PastaB são os projetos que quer migrar.

<?xml version=”1.0″ encoding=”utf-8″?>
<SourceControlConverter>
<ConverterSpecificSetting>
<Source name=”VSS”>
<VSSDatabase name=”C:\VSSDB”></VSSDatabase>
</Source>
<ProjectMap>
<Project Source=”$\PastaA”></Project>
<Project Source=”$\PastaB”></Project>
</ProjectMap>
</ConverterSpecificSetting>
<Settings>
<Output file=”Analysis.xml”></Output>
</Settings>
</SourceControlConverter>

* Para migrar o banco inteiro, use: <Project Source=”$/”></Project>.

• Em <VSSDatabase name, coloque o caminho do diretório onde está sua base do VSS a ser migrada.
• Salve e feche.

O próximo passo será rodar o conversor usando o caminho deste arquivo como parâmetro. O usuário logado no windows precisa ser administrador no SQL Express também. Por padrão, o usuário que instalou o SQL ou o Visual Studio que ele acompanhou já tem essa permissão.

Para analisar o projeto com o conversor…

• No prompt de comando do Visual Studio, digite: VSSConverter Analyze settings.xml
• Quando for solicitado, digite a senha de administrador da base do VSS.

O conversor irá mostrar o status da análise. Quando terminar, irá gerar um relatório (VSSAnalysisReport.xml) e um arquivo de mapeamento de usuários (usermap.xml) e vai salvá-los no diretório corrente.

O próximo passo, depois de ver que a migração terá sucesso fazendo a análise, será fazer efetivamente a migração, o que veremos no próximo post.

Um abraço

Ricardo Serradas

Um detalhe que notamos somente quando temos isso como problema é que os reports do TFS não são gerados em real time. Isso acontece porque a geração dos relatórios é uma tarefa custosa para o servidor e diminuiria sua performance.

Por padrão, o warehouse é atualizado de hora em hora. Porém, existem duas alternativas para “driblar” isto quando é caracterizado como problema.

Vamos imaginar que você gerencie um projeto de grande porte, que tem alimentação de dados quase que momentâneamente. Seu diretor precisa urgentemente de relatórios que mostrem a situação do projeto de forma mais atualizada possível. Seu report server foi atualizado há 40 minutos atrás e, até então, você precisaria de mais 20 para esperar a próxima atualização. Neste cenário, usaríamos a Solução 1: Requisitar manualmente a atualização do Warehouse.

Assim:

- Acessehttp://nomedoserver:8080/Warehouse/v1.0/Warehousecontroller.asmx;

- Clique no método “Run” e depois em “Invoke”.

Vai retornar true se a atualização ocorreu com sucesso. Se retornar false… 

Agora, se seu Diretor costuma fazer isso com frequencia, você provavelmente vai preferir a Solução 2: Modificar o intervalo de tempo entre atualizações. Desta forma:

- Acesse:http://nomedoserver:8080/Warehouse/v1.0/Warehousecontroller.asmx;

- Clique em “ChangeSetting”;

- Em “settingID” coloque “RunIntervalSeconds”;

- Em “newValue” especifique o novo intervalo, em Segundos. Por exemplo, para mudar o intervalo para 30 minutos, insira 1800.

Se a mudança ocorreu com sucesso, retornará uma mensagem informando isso.

* A não recomendação da solução 2, como já comentei no início do artigo, se dá ao fato de que atualizações mais frequentes do warehouse vão impactar na performance do servidor, já que consome recursos razoáveis quando está executando esta ação.

Abraço!

Ricardo Serradas

Creio que isso tenha sido feito de propósito, para enaltecer ainda mais a segurança que o Team System traz para uma empresa que trabalha com ele.

Para deletar um projeto do Team Foundation Server, não há como fazer isso através do Visual Studio Team Explorer. Para Fazer isso, é necessário usar uma linha comando no prompt do Windows. Assim:

C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE> TFSDeleteProject.exe /Server:ServerName ProjectName

Existe a opção de usar o /force para forçar a remoção mesmo que existam itens presos, mas isso não é recomendado.

A saída do comando é a seguinte:

Warning: Deleting a team project is an irrecoverable operation. All version control, work item tracking and Team Foundation build data will be destroyed from the system. The only way to recover this data is by restoring a stored backup of the databases. Are you sure you want to delete the team project and all of its data? (Y/N)?

Deleting from Build… Done
Deleting from Work Item Tracking… Done
Deleting from Version Control… Done
Deleting Report Server files… Done
Deleting SharePoint site… Done
Deleting Team Foundation Core… Done

Abraços

Edit 1:

Ao usar este comando na prática, encontrei problemas do tipo “SOAPException”, o que fizeram com que sobrassem os arquivos de alguns projetos no Source Control.

É inválido usar o tfsdeleteproject denovo, pois as principais referências do projeto já não existem mais, foram removidas do “Core”.

Para resolver esse problema, contei com a ajuda do Martin do Forum MSDN, que me orientou a usar o tf destroy (comando que não tem volta) para excluir o projeto do Source Control. Usei assim:

C:\Program Files\Microsoft Visual Studio 9.0\VC> tf destroy $/ProjectName

A saída é a seguinte:

Do you want to destroy $/ProjectName and all of its children? (Yes/No) Yes

Destroyed $/ProjectName

Depois disso, só dar um refresh no Source Control do Team Explorer pra ver o resultado 

Abs

Ricardo Serradas