Como prometido, esta é a primeira edição do CodePlex em destaque – primeira de muitas, espero eu .

O projeto que gostaria de destacar hoje é o Team Development with Team Foundation Server – um projeto conjunto do time de Patterns & Practices da Microsoft e do time de produto do Team Foundation Server, além de alguns parceiros e especialistas do mercado.

A idéia do guia é consolidar um guia de “boas práticas” para utilização do TFS num ambiente de desemvolvimento. Leitura obrigatória para qualquer um quer pretenda usar o TFS!

Os tópicos abordados são:

• Fundamentals
• Source Control
• Builds
• Large Project Considerations
• Project Management
• Process Templates
• Reporting
• Setting Up and Maintaining the Team Environment
• Visual Studio Team System 2008 Team Foundation Server

 

Tem muita gente que nunca ouviu falar no CodePlex. Para quem não conhece, o CodePlex é um site que oferece a desenvolvedores de software livre (código aberto, open source) toda a infraestrutura para que possam hospedar seus projetos. Esses projetos podem ser desenvolvidos em qualquer tecnologia, para qualquer plataforma. A única exigência é que o software seja oferecido com algum tipo de licença de código aberto.

Esse site tem uma característica técnica bastante interessante: a estrutura de Gerência de Configuração (Controle de Versão e Gestão de Problemas) é baseada no Team Foundation Server. Ou seja, você pode usar o TFS de forma gratuita para hospedar seus projetos open-source. Você pode inclusive baixar o Team Explorer (também gratuito) para integrar seu Visual Studio (Standard ou superior) ao CodePlex.

Se o próprio site é desconhecido, o que dizer dos projetos hospedados lá? Há muita coisa bacana, bastante útil, e que poderia ajudá-lo a resolver problemas que você possa ter no seu dia-a-dia. Por isso, resolvi criar uma categoria especial (e recorrente) de postagens: CodePlex em destaque.

Toda sexta-feira irei destacar algum projeto hospedado no Codeplex e que esteja de alguma forma ligado ao Visual Studio Team System. Amanhã teremos o primeiro post da série.

Aguarde!

 

Quantas vezes já passamos (ou vimos alguém passar) por isso?

“Um funcionário saiu da empresa e largou um monte de arquivos em check-out. Ninguém sabe a senha dele. Mas nem ia adiantar, a máquina já foi formatada mesmo…”

E agora, como cancelar os check-outs feitos por outro usuário? O segredo está na (relativamente pouco conhecida) ferramenta de linha de comando do Team Explorer, tf.exe. Abra o prompt de comando do Visual Studio 2008 e execute:

tf workspaces /owner:<nome_do_usuário> /server:<nome_do_servidor>

 

Com isso você consegue listar os workspaces do usuário em questão. Você vai precisar dessa informação para a próxima etapa:

 

tf undo /workspace:<nome_do_workspace>;<nome_do_usuario> /recursive /server:<nome_do_servidor> $/*.*

 

Para cada workspace listado na etapa anterior, execute o comando acima.

 

Com o recente lançamento do Service Pack 1 do Visual Studio 2008 e Team Foundation Server 2008, muitas coisas são atualizadas em seu computador:

 

Visual Studio 2008 SP1

• Visual Studio (todas as edições)
• .NET Framework 3.5

Team Foundation Server SP1

• Team Foundation Server (AT)
• .NET Framework 3.5

 

Mas há algumas ferramentas que, de tão naturais no nosso dia-a-dia, que acabam se tornando “invisíveis”. Esquecemos que elas são downloads adicionais e que não fazem parte do produto original.

Esse é o caso com o pacote “Team Foundation Server Power Tools”. São ferramentas extremamente úteis e que complementam o Visual Studio e o TFS.

Dentre todos os componentes do pacote Power Tools, provavelmente o mais conhecido é o Team System Web Access.

Porém, muitos acreditam que o TSWA é parte integrante do Team Foundation Server – e que, com isso, ele será atualizado automaticamente durante a instalação do Service Pack do TFS. Bom, na verdade o SP1 não atualiza o TSWA. Ele deve ser atualizado à parte, como todo o restante do pacote Power Tools. Devemos ter, em breve, o lançamento da versão “correnpondente ao SP1” do TSWA.

No futuro, o Rosario trará mudanças nesse aspecto. O Team System Web Access finalmente passará a ser parte integrante do produto e, por isso, será atualizado junto com quaisquer service packs que venham a ser criados.

 

Recentemente, o Jeff Atwood (“Coding Horror”) escreveu um post com o título acima. Vale a pena dar uma liad no post inteiro; por enquanto, veja o trecho abaixo que extraí – foi o que mais me chamou a atenção:

Johanna Rothman makes the same point in a recent email newsletter, and offers specific actions you can take to avoid being stuck 90% done:

1. List everything you need to do to finish the big chunk of work. I include any infrastructure work such as setting up branches in the source control system.
2. Estimate each item on that list. This initial estimate will help you see how long it might take to complete the entire task.
3. Now, look to see how long each item on that list will take to finish. If you have a task longer than one day, break that task into smaller pieces. Breaking larger tasks into these inch-pebbles is critical for escaping the 90% Done syndrome.
4. Determine a way to show visible status to anyone who's interested. If you're the person doing the work, what would you have to do to show your status to your manager? If you're the manager, what do you need to see? You might need to see lists of test cases or a demo or something else that shows you visible progress.
5. Since you've got one-day or smaller tasks, you can track your progress daily. I like to keep a chart or list of the tasks, my initial estimated end time and the actual end time for each task. This is especially important for you managers, so you can see if the person is being interrupted and therefore is multitasking. (See the article about the Split Focus schedule game.)

I'm not big on scheduling -- or lists -- but without the latter, I cannot have the former. It's like trying to defy the law of gravity. Thus, on our project, we're always 90% done. If you'd like escape the 90% done ghetto on your software project, don't learn this the hard way, like I did. Every time someone asks you what your schedule is, you should be able to point to a list of everything you need to do. And if you can't -- the first item on your task list should be to create that list.

On Our Project, We're Always 90% Done

Sabe o que mais me chamou a atenção no trecho acima? É que quando visito cliente para falar de Team Foundation Server e explico como usar work items para a gestão de projetos, é exatamente desse jeito que eu sugiro usar o TFS!

Se você seguir essas dicas como um princípio de boas práticas no uso de work items (independentemente do processo de desenvolvimento que esteja usando) sua experiência será muito mais rica.

Relacione tudo o que você tem que fazer (“List everything you need to do to finish the big chunk of work”)

Aqui o Excel é seu aliado. Use-o para relacionar rapidamente todas as atividades-macro que você já identificou durante a fase de levantamente/especificação/planejamento (ou como chamar no seu processo de desenvolvimento). Aproveite para dividir as atividades por área e/ou iteração.

 

Estime cada item na lista (“Estimate each item on that list”)

Use o Excel ou o Project (para muitos, o Project é o preferido nesse tipo de atividade). Faça uma estimativa inicial do tempo que se levaria para executar cada uma das atividades identificadas no processo anterior. Não se preocupe em ser preciso; você vai refinar essas estimativas depois.

Divida suas atividades em pedaços de no máximo 8 horas (“If you have a task longer than one day, break that task into smaller pieces”)

Na minha opinião, este é o ponto-chave para um uso bem-sucedido do TFS. Se você fizer um bom WBS (work breakdown structure), chegando um nível de detalhamento que garanta que suas atividades terão no máximo 8 horas, terá conseguido algo muito difícil: o comprometimento da equipe de desenvolvedores com a prática de relatório de status (status report).

O “pulo-do-gato” é que nenhum desenvolvedor seria obrigado a fazer nada além daquilo que ele faz normalmente: o check-in do código que acabou de produzir. Ao dividir as atividades em unidade de até oito horas, você praticamente garante que seus desenvolvedores:

1. Farão check-in apenas de código completo (afinal, eles terminam a atividade no mesmo dia em que começaram);
2. Farão check-in ao menos uma vez por dia (pelo mesmo motivo do item 1).

Alie-se a isso a política de check-in de work items e você terá feedback diário das atividades dos seus desenvolvedores – tudo o que eles precisam fazer é clicar uma checkbox na caixa de diálogo de check-in. “Magicamente” seus relatórios começarão a ter dados para os alimentar.

Divulgue o status do seu projeto (“Determine a way to show visible status to anyone who's interested”)

Quer ferramenta melhor que o Portal do Projeto do TFS, feito em SharePoint, para isso? Crie seus painéis de controle (“dashboards”) para que os interessados possam acompanhar o andamento do projeto.

Acompanhe o progresso do projeto diariamente (“Track your progress daily”)

Além do Excel, Project ou mesmo os relatórios disponíveis no Portal do Projeto, você pode usar também as inúmeras consultas de work items do TFS (e até mesmo criar suas próprias) para acompanhar seu projeto.

 

 

Viu? Com alguns cuidados básicos (e com um esforço relativamente pequeno) você consegue tirar proveito facilmente dos recursos de gestão de projetos do TFS!

 

Boas notícias! O SQL Server 2008 já está disponível para download para assinantes MSDN e Technet.

“Legal. E o que isso tem a ver com o Team System?”

Que bom que você perguntou… :-)

O Service Pack 1 do Visual Studio 2008 (às vésperas de ser lançado) oferece suporte nativo ao SQL Server 2008. Com isso:

• Será possível usar o SQL Server 2008 como back-end do TFS (hoje você precisa usar o SQL 2005);
• O VSTS Database Edition reconhecerá a nova versão do SQL, para que possamos fazer controle de versão, testes unitários de bancos de dados, comparação de schema etc.

 

Mais uma da série “dúvidas comuns que respondemos infinitas vezes”: Por que as políticas de check-in não são obrigatórias?

O recurso de check-in policy (política de check-in) é percebido pelos usuários do TFS como uma grande vantagem. Com ele, é possivel definir algumas premissas para a aceitação do código-fonte:

• Você testou seu código antes de fazer check-in?
• Você analisou o seu código para garantir que ele atende aos padrões da empresa?
• Você lembrou de associar suas alterações no código à atividade/demanda que originou essas alterações?

 

 

As políticas de check-in são definidas em nível de projeto (Team Project) e se aplicam a todos os desenvolvedores que atuam no tal projeto. Toda vez que eles tentam efetuar um check-in, as políticas são validadas e o usuário é alertado caso elas não sejam atendidas.

O ponto mais polêmico em relação às políticas de check-in é que elas podem ser ignoradas pelo usuário!

Por quê isso? Já ouvi pessoas falando que a Microsoft fez o serviço “pela metade”, deixando de fora a possibilidade de barrar o check-in. Bom, temos algumas explicações para isso. A primeira delas vem de um blog de FAQ do Team System:

Can we disable the “Override CheckIn Policy Failure” checkbox? Can that be customized based on User Login, Policy Type or File type?

No. We get a lot of requests for this but our contention is that the person defining the policy can’t envision the situations that will arise where policy will need to be overridden. Thus, we designed it to be fully auditable by including policy compliance data in the changeset details and in the checkin mail that is delivered, but left it up to the developer to determine whether they have a good reason for overriding.

A razão é simples: se o desenvolvedor optou por ignorar a política de check-in, ele deve ter um bom motivo. Trabalho em equipe presume confiança entre seus membros, logo não faz sentido partir da premissa que todos são imaturos e irresponsáveis. Entretanto, como auditoria é fundamental em qualquer projeto (mesmo nos “ágeis”), o TFS registra no evento de check-in sempre que alguém optou por desconsiderar políticas de check-in que não estavam sendo atendidas.

Dica:  Na edição de Julho/2008 do Team Foundation Server Power Tools há uma nova ferramenta, o Alert Editor, que simplifica bastante o processo de auditoria das políticas de check-in. Adicione um alerta para ser notificado sempre que alguém optar por ignorar uma política definida num team project:

Entendendo políticas de check-in - com sorte, de uma vez por todas :-)

Há uma triste verdade a respeito das políticas de check-in, uma ainda pior que o fato de podermos usar o famigerado “override”: políticas de check-in não são universais. Ou seja, elas não são executadas e garantidas pelo servidor. Cada aplicativo-cliente é responsável por executar as políticas de check-in que lhe convierem.

Do ponto de vista técnico, check-in policies nada mais são que assemblies .NET instalados em cada computador onde serão executados. Esses assemblies contêm algumas classes que implementam interfaces específicas definidas no SDK do Visual Studio. Quando instalamos o Team Explorer (cliente do TFS), recebemos “de brinde” as quatro políticas de check-in originais.

No ato do check-in, o programa que o desenvolvedor estiver usando (por exemplo, o Visual Studio 2008) contata o servidor e obtém uma lista com os nomes das políticas de check-in que deveriam ser executadas, junto com suas respectivas configurações (que também foram definidas no servidor). Em seguida, verifica se essas políticas estão disponíveis no computador local e procede à sua execução. Com isso, podemos entender a afirmação de que “cada aplicativo-cliente é responsável por executar as políticas de check-in que lhe convierem”.

O Visual Studio (2005/2008) é o cliente “premium” para o TFS. Como tal, é o único que garante executar todas as políticas de check-in que estiverem devidamente registradas no servidor e instaladas no computador do desenvolvedor. Isso traz uma variável adicional ao já conturbado universo das check-in policies. Ainda que possamos criar nossas próprias políticas de check-in (acrescentando novas opções às quatro originais), não há nada que garanta que elas serão executadas. Isso me faz lembrar de um velho problema que aflite desenvolvedores Web há muito tempo: Validação no Cliente vs. Validação no Servidor.

Validação no Cliente vs. Validação no Servidor

No universo da Web, aplicativos feitos em qualquer tecnologia (ASP.NET, PHP, Ruby, Java etc…) certamente se vêem às voltas com a necessidade de solicitar dados ao usuário. Formulários são usados para as mais diferentes entradas de dados. Porém, o HTML não é exatamente a melhor tecnologia para a criação de formulários de dados. Ele não tem praticamente nenhum recurso padrão de validação de conteúdo que os browsers possam usar para conferir o que o usuário nos levou. Isso geralmente leva a duas opções:

 

	Prós	Contras
Validação no Cliente	Rápido. Feedback instantâneo ao usuário. Dados incorretos podem ser facilmente corrigidos, sem a necessidade de uma “viagem de ida e volta” dos dados ao servidor para a validação	Inseguro. Como depende de Javascript, pode não ser executado (ex.: o usuário desativou a execução de scripts em seu browser). Além disso, o usuário poderia, maliciosamente ou não, subverter o script, fazendo-o aceitar dados inválidos.
Validação no Servidor	Seguro. O código rodando dentro do servidor está fora do alcance de usuários maliciosos, que não poderão alterar as regras de validação. Não há como forçar a entrada de dados inválidos.	Lento. Os dados precisam ser enviados ao servidor para que possam ser validados. Se forem encontrados erros nas informações prestadas pelo usuário, é necessário enviar uma notificação ao browser para que seja feita a correção – depois da qual o processo recomeça.

 

As boas práticas do desenvolvimento para a Web nos dizem que devemos, sempre que possível, oferecer as duas opções ao mesmo tempo. A conveniência da validação no cliente aliada à segurança da validação no servidor. Repare que a validação no cliente tem apenas o papel da conveniência, nunca podendo substituir a validação no servidor. Se tiver que optar por apenas uma delas, não há dúvidas: fique com o servidor.

Bom, você deve estar se perguntando, mas o que isso tem a ver com o assunto em pauta? Tudo! Encare as políticas de check-in do TFS como client-side validation: rápidas, porém inseguras. Se eu realmente quiser garantir que o check-in é seguro e atende às definições do meu processo de desenvolvimento, preciso ter o equivalente TFS da server-side validation. As alternativas são:

• Team Build + Integração Continua (CI, Continuous Integration): Com o TFS 2008 é possível disparar o processo de build automatizado do Team Build simplesmente fazendo um check-in. Com isso, podemos verificar se as alterações que acabaram de ser produzidas se integram adequadamente ao restante do código já existente no repositório. Efetuar o build a cada check-in visa a validar continuamente a integração entre os diversos trechos de código produzidos todo o tempo pela equipe de desenvolvimento. Daí vem o termo integração contínua. Como o processo de build é disparado automaticamente pelo ato de check-in, e como ele ocorre no agente de build (e não na máquina do desenvolvedor), ele acaba sendo o equivalente da validação de servidor das aplicações Web. Podemos rodar a análise estática de código, podemos rodar testes unitários, podemos auditar o código. Se houver algum problema, o build é marcado como falho (“quebrado”). O changeset (as alterações feitas pelo desenvolvedor) que deu origem ao build pode, então, ser desfeito (usando, por exemplo, o comando tfpt rollback).
• Gated check-in: O problema da solução apresentada acima, baseada apenas no servidor de build, é que o check-in precisa ser feito antes de ser validado. Ou seja, em caso de problemas eu necessariamente terei que desfazer manualmente as alterações que quebraram o build. O ideal seria que eu pudesse disparar o buid antes do check-in, só efetivando a alteração no controle de versão se tudo corresse bem. É justamente disso que trata o conceito de gated check-in: As operações de check-in são interceptadas (geralmente usando shelvesets) e redirecionadas para um servidor de build especial. Esse servidor combina o código-fonte que já existe no TFS com as alterações que acabaram de vir do desenvolvedor. Se tudo correr bem, só então é que o check-in será consumado. O TFS “Rosario” terá suporte nativo a gated check-in. Por enquanto, você pode usar o OpenGauntlet para ter esse recurso à disposição no TFS 2008.

Resumo da ópera

Politícas de check-in são um recurso bastante poderoso e conveniente. Devido ao fato de poderem ser facilmente burlados, devem ser usados apenas como lembrete para os desenvolvedores. Dessa forma, eles serão lembrados de testar seu código, associar work items etc. Para garantir que o código produzido por sua equipe atenda aos critérios definidos em sua empresa, utilize alguma técnica de gated check-in.