Ricardo Serradas

E para fazer essa modificação, vamos seguir os passos abaixo (faça back-up dos arquivos antes de começar a customização):

- Abrir o arquivo WorkItemChangedEvent.xsl em algum editor de XML ou no próprio Visual Studio;

- Dentro do arquivo, procure pelo trecho “ReferenceName[.='System.AssignedTo”. Verá que existe uma definição de uma linha de tabela (TR). Assim:

Interpretando esse trecho de código: na primeira célula da linha (PropName), ele coloca o título do campo, que é “Assigned to:”. Na segunda (PropValue), é inserido o valor.

Dentro dessa segunda TD você pode enxergar uma estrutura de repetição (foreach) e uma de validação (IF) onde ele varre os campos da coleção CoreFields em busca de um campo do tipo “System.AssignedTo”; se encontrar, exibe seu valor, através da propriedade “NewValue”.

Vamos fazer uma simples modificação de HTML. Colocaremos a tag de bold (“<b>”) nas duas tds. Fica assim:

Sobre o Changed Date, basta procurar pelo texto “System.ChangedDate” no código e remover a TR que á contém.

Depois dessas edições, salve o arquivo e faça alguma modificação em algum work item para disparar o evento. No meu caso, o resultado foi o segunte:

Daí pra frente é só ir brincando com os campos e com o template dos alertas.

[]’s

Ricardo Serradas

Olá,

Muito falou-se sobre uma das features mais esperadas da versão 2010 do Visual Studio Team Foundation Server: o Gated Check-in. Neste post, vamos fazer um raio-x deste mais novo aliado na luta por uma integração contínua mais forte e código fonte de nossas aplicações de melhor qualidade.

De uma forma geral, como ele funciona?

Quando um desenvolvedor efetua um check-in, ele recebe uma notificação dizendo que suas alterações devem ser compiladas antes de serem persistidas no controle de versão. O TFS então desvia essas alterações para um shelveset. No servidor de build é feito um unshelve dessas alterações e em seguida todo o código é compilado. Se o build tiver sucesso, um novo changeset é criado a partir do shelve e o check-in é feito em nome do desenvolvedor.

Como configurá-lo?

Para que o Gated Check-in seja usado no seu time, precisamos criar uma Build Definition com essa característica. Vamos ver como funciona:

Vamos assumir que já temos configurado nosso servidor de build e que ele está definido como Build Agent e Controller no TFS.

Não vamos entrar em detalhes sobre a configuração completa de um build definition por não ser o foco principal deste post. Sendo assim, durante a configuração de uma build definition, vemos várias abas. Uma das abas que nos interessa neste momento é a de nome “Trigger”. É nela onde definimos que essa build configura o Gated Check-in:

Um passo muito importante (e que chega até ser uma “pegadinha”) no processo de configuração está na próxima aba, que é a “Workspace”. É lá que definimos para qual estrutura de pastas esta build funcionará. Veja:

Isto significa que esta política de gated check-in somada ao build automatizado só vai ser disparado se uma tentativa de check-in for realizada na estrutura de diretórios abaixo de $/TFS10Demo/dotnet/GatedCheckinDemo.

Se esta configuração não for feita da forma correta e, por exemplo, se deixarmos este campo com “$/”, esta política se aplicará para todos os projetos desta coleção. Sendo assim, um check-in em qualquer outro Team Project será barrado por este Gated Check-in e o código do projeto GatedCheckinDemo será compilado sem real necessidade.

Salvas essas e outras configurações, vamos testar se nosso Gated Check-in está funcionando. Para isso, vamos modificar algum fonte que está versionado debaixo da estrutura definida no workspace. Depois disso, vamos efetuar um check-in. Após isso, recebemos a seguinte mensagem:

*Ao clicar em Build Changes, uma nova build é disparada e as pendências de check-in na máquina do desenvolvedor são desfeitas, ficando apenas no shelveset que será usado pelo servidor de build.

Se tudo der certo, se tudo foi bem codificado e o processo de check-in foi bem feito (Get Latest Version antes, tentativa de compilação e etc), será mostrada essa mensagem na tela do desenvolvedor que efetuou o check-in:

Ela informa que o build teve sucesso e que as suas alterações foram persistidas no controle de versão. Se a opção para preservar os check-outs ficou marcada na hora de submeter o build, use o botão “Reconcilie…” para acertar seu workspace. Se não, basta apenas ignorar a mensagem e rodar um Get Latest Version para obter suas próprias alterações.

Já se o build falhar, uma janela semelhante será mostrada, sugerindo dar o unshelve das alterações que foram enviadas para que a correção possa ser feita.

* A opção “Bypass validation build and check-in my changes automatically on your behalf” é, por padrão, desabilitada para membros do grupo “Contributors”, que é o grupo onde costuma-se incluir desenvolvedores.

Você já conhecia este novo conceito? Gostou desta nova funcionalidade? Tem críticas? Comente!

[]’s

Ricardo Serradas

Olá,

Para quem é daqueles que está sempre querendo estar um passo à frente, é uma informação muito importante. A Microsoft já disponibiliza para download um kit de aprendizado sobre o Visual Studio 2010 e o Team Foundation Server 2010. As máquinas virtuais existem nas versões para Windows Virtual PC, Microsoft Virtual PC e Hyper V.

Este material contém tudo que é preciso para estudar e entender as capacidades desta poderosa ferramenta de ALM (Application Lifecycle Management). Inclusive, a base de dados do TFS já vem populada com dados de exemplo. Há apenas uma exceção: as funcionalidades de Lab Management não estão inclusas. Ainda espera-se uma novidade vinda do time de produto relacionada a isso.

Abaixo, o link para download de cada uma das versões:

• Windows 7 Virtual PC
• Microsoft Virtual PC SP1
• Hyper V

As máquinas tem validade até 9 de abril de 2010, data de expiração do trial do SQL Server. Notificações de ativação serão exibidas durante o uso, comportamento normal de uma versão trial do Windows. Não há com o que se preocupar.

Boa diversão!

[]‘s
Ricardo Serradas

Ultimamente tenho socorrido várias pessoas que vieram me fazer essa pergunta, ainda que para quem já está familiarizado com a ferramenta isso não seja um problema.

“Eu fiz o shelve lá conforme você recomendou só que agora não sei como recuperar as modificações do servidor! E agora, já era? As perdi? Como faz?”

Muita calma nessa hora. A solução é bem simples, porém, o problema é compreensível. O botão “Unshelve” está em localizações pouco intuitivas na IDE do Visual Studio 2008. Vamos à elas:

1 – Em “Pending Changes”: De um certo modo, concordo que umchangeset é composto de modificações pendentes de check-in, mas não são todos que pensam da mesma forma. Para grande maioria, “Pending Changes” são check-outs locais pendentes de commit paraversionamento. Concordo, afinal Shelveset é um conjunto de modificações armazenadas no Servidor, mas ainda não versionadas.

Mas voltando ao que interessa, o “Unshelve” está aqui: View -> Other Windows -> Pending Changes.

2 – Ao clicar com o botão direito em qualquer item no solution explorer. Sim, ali mesmo. Mas desde que você tenha algum projeto aberto. Não vale aquela “Solution1″ 

Ah, aproveitando! Galera, vamos dar mais atenção à essa feature do VSTS. Esse tal de Shelve pode ser muito últil para você!

Um abraço,

Ricardo Serradas

Infelizmente o VSTS 2008 usa a interface de compare que já existia no VSS. Eu, particularmente, não gosto. Acho que existem outras ferramentas no mercado que fazem compare muito melhor do que ela. Eu por exemplo uso o WinMerge.

Como vinha tendo problemas com o modo que o VSTS faz o compare, fui atrás de modificar a ferramenta que ele usa para esta ação. Para fazer isso, basta seguir os passos abaixo:

- No VSTS, clique em Tools > Options > Source Control > Visual Studio Team Foundation Server
- À direita, clique em “Configure User Tools…”
- Na nova janela, clique em “Add…”
- Em extensions, insira as extensões de arquivo as quais você quer usar a ferramenta para fazer compare;
- Em “Operation” deixe “Compare”;
- Em “Command”, localize o executável da ferramenta (no meu caso, “C:\Program Files\WinMerge\WinMergeU.exe”);
- Em “Arguments” configure conforme sua ferramenta de merge recebe os parâmetros;

Não aconselho fazer o mesmo para a ferramenta de merge essa sim eu acho que está legal 

[]’s

Ricardo Serradas

Uma feature que faltou ao Source Control Explorer foi poder visualizar o histórico literalmente completo do arquivo. Digo isso porque se um arquivo fez parte de um branch, todo o histórico antes disso não pode ser visualizado através do “View History”.

Para conseguir fazer isso através da IDE, seria necessário ir nas propriedades do arquivo, na aba Branches e consultar qual (ou quais) é o seu branch pai ao qual ele pertence, localizar este arquivo neste branch e visualizar o arquivo… Trabalhoso, não?

Pois é… E por isso existe no CodePlex um projeto chamado TFS Follow Branch History, que permite fazer isso tudo com apenas um clique, ou dois, se considerarmos o clique do botão direito no arquivo 

Ele funciona como um Add-in para o VS 2008 e, depois de instalado, disponibiliza mais um botão no menu exibido ao clicar com o botão direito em qualquer arquivo no Source Control Explorer, assim:

Acesse a página do projeto clicando aqui.

Vale lembrar que o TFS Power Tools também disponibiliza uma opção a mais para a visualização do histórico via linhas de comandos, que é “/followbranches”.

Abraços

Ricardo Serradas

Olá a todos,

Nesta semana, conseguimos efetuar a migração dos fontes armazenados no SourceSafe e SVN para o TFS aqui na empresa.

De um modo, a migração foi muito tranquila. A única perda foi a do histórico do SVN, pois ainda não há nenhuma ferramenta que faça essa migração anexando o histórico, diferente do que faz o VSSConverter.

O que tem sido um problema nos últimos dias é o gerenciamento dos workspaces por parte dos desenvolvedores, principalmente dos que trabalhavam com o SVN, que era integrado ao Windows Explorer. O que tem acontecido é que uma única pasta no source control é mapeada para diversas no disco da máquina.

O TFS permite que seja criado um template de workspace para a equipe, mas não oferece opção para evitar que os Colaboradores façam novos mapeamentos. É possível apenas evitar que novos workspaces sejam criados.

Para contornar isso então, precisava encontrar uma maneira de visualizar todos os workspaces de todos os usuários e orientá-los melhor a respeito desta feature. Mas como fazer isso?

Foi quando encontrei o Team Foundation Sidekicks. Com ele, além de executar esta ação, também é possível:

• Checar status de arquivos;
• Visualizar históricos, shelvesets e labels com dados mais detalhados;
• Gerenciar permissões;
• UI para melhorar auxiliar no processo de code review.

Eu achei a ferramenta muito bacana. Ainda estou a explorando e com certeza devo encontrar mais surpresas. Para quem quiser conhecer, segue o link abaixo. É 100% free:

Attrice TFS Sideckick

Abraços

Ricardo Serradas

Olá,

Para quem se preocupa com Database Projects no momento de um build ou deploy. Aquela preocupação que diz respeito à “vou ter que reconstruir meu banco para gerar o novo build?” ou “vou perder todos os dados da tabela X para poder adicionar uma nova coluna a ela?”…

O VSTS Database Edition (Codename “Data Dude”) tem total integração com o MSBuild. Ou seja, todo o esquema de build e deploy podem ser também utilizados para sua camada de dados do projeto.

As alterações no projeto de banco, sejam de adição de novas entidades ou alteração de alguma já existente, são adicionadas a um arquivo .sql. Este arquivo pode ou não ser integrado ao seu processo de build diretamente, dependendo do seu processo (validação de algum DBA, etc).

Lembrando que no processo de build, tanto podem ser usadas somente as alterações realizadas quanto o script inteiro do banco de dados.

Em um deploy Full (usado para entrega ao cliente, geração de versão), todo o banco de dados é criado no server de destino. É este o processo padrão quando, no destino, o banco não existe. Porém, isso pode ser forçado no build usando a opção “Always Recreate Database”.

Já num deploy incremental (útil para gerar builds para testes), somente os scripts de alterações realizadas são rodados no banco de dados.

Ainda podem ser utilizados scripts incrementais que validem versão do servidor no destino, nome do banco de dados e nível de compatibilidade. Caso alguma dessas validações falhe, o processo de build/deploy pode ser abortado.

Abraço,

Ricardo Serradas

Olá a todos,

Numa última discussão sobre TFS, me veio um pensamento sobre possíveis ‘obstáculos’ numa migração de VS Professional + VSS para Team System: a migração de framework.

Vamos imaginar um cenário em que alguns de nossos módulos são escritos ainda em .Net 1.1 (VS 2003). Já foram feitas tentativas de migração para 2.0 ou 3.5, mas houve impacto no funcionamento e foi feito um rollback da versão.

Uma alternativa para isso é simplesmente manter o framework 1.1, usando o provider do TFS para outras plataformas, o VSTS MSSCCI Provider.

Para utilizá-lo, basta ter o Team Explorer instalado na máquina. Ele é compatível com as seguintes IDEs de desenvolvimento:

- Visual Studio .NET 2003
- Visual C++ 6 SP6
- Visual Visual Basic 6 SP6
- Visual FoxPro 9 SP1
- Microsoft Access 2003 SP2
- SQL Server Management Studio
- Sparx Systems Enterprise Architect 6.1
- Sybase PowerBuilder 10.5
- Toad for SQL Server 2.0

Para baixá-lo, clique aqui.

Como exemplo, no VS 2003, depois que instalar o provider vá em Tools > Options > Source Control > Use Team Foundation Server.

Vale lembrar que não é uma obrigatoriedade que a aplicação seja em .Net para usar o TFS, como falamos aqui.

Um abraço

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