Conhecendo o Visual Studio Team System Source Control

Se você é feliz com o Visual SourceSafe, ficará radiante de alegria com esta nova ferramenta. Se você não é feliz com o Visual SourceSafe, conheça a definitiva e mais completa solução integrada para controle e armazenamento de códigos fontes e documentos. Primando por uma apresentação simples e direta, abordaremos neste artigo a evolução das ferramentas de Software Configuration Management - SCM.

por Fabio Camara

por Fábio Câmara e Igor Abade V. Leite

Se você é feliz com o Visual SourceSafe, ficará radiante de alegria com esta nova ferramenta. Se você não é feliz com o Visual SourceSafe, conheça a definitiva e mais completa solução integrada para controle e armazenamento de códigos fontes e documentos. Primando por uma apresentação simples e direta, abordaremos neste artigo a evolução das ferramentas de Software Configuration Management - SCM.

Software Configuration Management

SCM tem um fundamental papel no SDLC - Software Development Life Cycle, mesmo para times pequenos de desenvolvimento. Todas as metodologias, algumas superficialmente, outras profundamente, tratam sobre este importante quesito crucial a organização de um projeto de desenvolvimento de software. Para exemplificar com maior ênfase a importância, o CMMI (Capability Maturity Model Integration) possui uma área de processo chamada CM - Configuration Management para regulamentar especificamente este item.

Podemos explicar SCM como um conjunto de práticas, regras e processos que uma organização usa para:

• Controlar acesso a arquivos
• Gerador de compilação de arquivos
• Gerenciador de versões de arquivos

Tradicionalmente as organizações são obrigadas a optar por uma das duas abordagens de SCM: a "ad hoc" e a baseada em alguma ferramenta como, por exemplo, o Subversion, o Visual SourceSafe ou o CVS.

Na abordagem ad hoc é definida uma série de regras e processos, contudo não existem ferramentas que automatizem estas regras e processos. As vantagens desta abordagem é o baixo custo inicial e a flexibilidade, pois os participantes do projeto não se sentem vigiados a fazer os procedimentos somente de uma forma rígida e podem ajustar os processos a suas preferências e requisitos. As desvantagens, na minha leitura, é exatamente o texto que escrevi como vantagem, por mais contraditório que possa parecer. Na minha visão, essa flexibilidade é perigosa e pode colocar a perder o resultado de meses de trabalho.

Na outra abordagem, temos uma ferramenta de ponta-a-ponta que se propõe a gerenciar todos os produtos resultantes de seu SDLC previamente estabelecido. Um incalculável resultado positivo, muitas vezes até difícil de mensurar, é a comunicação que uma ferramenta desta promove entre todos os integrantes de um projeto, permitindo o desenvolvedor "A" saber que não pode alterar um determinado artefato devido ao desenvolvedor "B" está com ele em uso no mesmo momento.

Comentando ainda sobre vantagens, destacamos a previsibilidade que este tipo de ferramenta gera conforme as regras e "milestones" definidos na ferramenta. Em outras palavras, perguntar ao desenvolvedor se determinada tarefa esta pronta é subjetivo. Fazer a mesma pergunta a ferramenta de controle de código fonte é binário. Como disse uma vez o poeta, os números não têm sentimentos.

Na parte das desvantagens, das quais particularmente questiono se podemos classificar desvantagem, contudo me responsabilizo em seriamente apresentar, o ponto negativo é o preço - geralmente não indicado para empresas pequenas. Não somente ao preço da ferramenta adiciona-se mais investimentos em treinamento, mas investimentos em personalização de processos e regras. Provavelmente alguns times de projeto também reclamaram da rigidez que estas ferramentas impõem aos desenvolvedores acostumados a trabalhar artesanalmente e obviamente eu discordo novamente sobre a classificação "desvantagem".

Para atender as necessidades cada vez maiores de produtividade e qualidade dos projetos de software, a Microsoft criou o Visual Studio Team System (Figura 1), uma família de produtos que oferece o que há de mais moderno em ambientes integrados de desenvolvimento (IDEs) e gerência de configuração de software.

Figura 1 - Visual Studio Team System

Como começar?

Para podermos experimentar tudo que o Visual Studio Team System tem a oferecer, precisamos do Visual Studio Team Foundation Server (veja a nota "O Team Foundation Server não é um servidor tradicional"). O TFS tem por finalidade servir como repositório do sistema de controle de versão, bem como armazenar e gerenciar os items de trabalho - work items - que integram o time e permitem o controle do projeto.

Para nosso trabalho, além do servidor, precisamos também configurar nossos clientes. Para que possamos extrair o máximo do produto, deveremos usar alguma das edições de trabalho em equipe (conhecidas como Team Editions) do Visual Studio 2005, que são os clientes por excelência do TFS. As edições foram criadas pensando nos papéis mais comuns desempenhados pelo pessoal de desenvolvimento nas equipes de projeto de software. Os papéis e suas edições correspondentes são:

Papel (role)	Edição (Team Edition)	Funções principais
Arquiteto	Team Edition for Software Architect	Modelagem, diagramas de aplicação e sistema, geração de código
Desenvolvedor	Team Edition for Software Developer	Codificação, design visual de formulários Windows e Web, unit tests
Testador	Team Edition for Software Tester	Testes automatizados, testes de carga, análise de cobertura de código, unit tests
Todos os papéis	Team Suíte	Contém as funções de todas as edições num mesmo pacote

Todas as edições do Visual Studio 2005 acessam o TFS a partir de uma ferramenta de integração conhecida como Team Explorer (Figura 2). Distribuído como parte do TFS, ele estende o IDE do Visual Studio de maneira a oferecer os novos recursos do Team System.

Figura 2 - Team Explorer (dir.) com Source Control Explorer (centro) O TFS deve ser instalado em uma máquina exclusiva para sua finalidade e obrigatoriamente o sistema operacional deve ser o Windows 2003. Para seus testes iniciais, recomendamos você usar uma máquina virtual - o TFS se "comporta" muito bem dentro do Microsoft Virtual PC, desde que você tenha ao menos 1 GB de RAM em seu computador.

O Team Foundation Server não é um servidor tradicional

Normalmente quando falamos em servidores pensamos em sistemas desenvolvidos como uma caixa preta, ou seja, produtos completamente fechados e desenvolvidos a partir do zero a fim de desempenhar o papel para que foram projetados. Pensando nessa classe de servidores, é inevitável imaginá-los como um conjunto de um ou mais serviços, que podem ser iniciados e parados a qualquer momento usando o snap-in de Serviços do Windows. Produtos como o Internet Information Services (IIS) e o SQL Server encaixam-se perfeitamente nessa descrição. O Team Foundation Server é uma classe completamente diferente de servidores. Ao invés de reinventar a roda, a Microsoft inteligentemente aproveitou o que havia de melhor em alguns de seus principais produtos de servidor - Windows 2003, IIS 6.0, SQL Server 2005, SharePoint 2.0 - e usou-os como a plataforma ideal para uma aplicação baseada em Web Services que é extremamente eficiente, escalável e que pode ser acessada pela Internet, desde que esteja devidamente configurado para tal. Em outras palavras você não encontrará um serviço que corresponda ao TFS em seu servidor. Na prática há uma série deles trabalhando em uníssono para lhe oferecer subsídios que permitam retomar o controle de seus projetos de software.

Principais recursos do TFVC

O serviço de controle de versão do Team Foundation Server, também conhecido como Team Foundation Version Control, é a parte central dos seus esforços de gerência de configuração. Utilizando um repositório baseado em SQL Server 2005, oferece uma plataforma robusta de controle de versão, capaz de suportar projetos com milhares de arquivos, vários milhões de linhas e inúmeros usuários simultâneos.

Listamos alguns dos pontos-chave que fazem com que este produto se destaque no mercado de ferramentas de controle de versão:

Segurança: O Team Foundation Server utiliza os mecanismos de autenticação integrada do Internet Information Services com uma granularidade de permissões muito maior e mais eficiente que a encontrada em produtos como o Visual SourceSafe, por exemplo. Você pode dar permissões a seus usuários usando a mesma conta de usuário e senha que eles usam para acessar a rede (Active Directory).

Figura 3 - Caixa de diálogo de configuração de permissões do TFS

Escalabilidade: Times pequenos precisam de apenas um computador para desempenhar o papel de servidor TFS. Entretanto, conforme as necessidades de sua empresa crescem, é possível distribuir o TFS em dois servidores diferentes, um responsável pelos dados e o outro pela aplicação. Usando um hardware de preço relativamente acessível é possível atender a times de mais aproximadamente quinhentas pessoas trabalhando simultaneamente.

Confiabilidade: A partir do SQL Server 2005 como back-end, o TFVC oferece suporte total a transações. Se houver qualquer problema no meio de uma operação de check-in, como uma queda de conexão, a transação é desfeita automaticamente e o repositório continua perfeitamente íntegro. Finalmente podemos dizer "adeus" aos repositórios corrompidos!

Changesets: As operações de check-in são, como explicamos anteriormente, protegidas por uma transação. Isso é o mesmo que afirmarmos que os check-ins do TFVC são atômicos, ou seja, ou um check-in é confirmado como um todo ou nada é inserido no repositório. Ao afirmarmos que essas operações são atômicas, significa dizer que todos os arquivos são agrupados numa mesma transação. A essa transação denominamos de changeset (conjunto de mudanças). Um changeset é a unidade básica de controle de versão do TFVC. A cada novo check-in é gerado um changeset e a ele é dado um número de versão (Figura 4). Esse número de versão é aplicado a todos os arquivos do changeset (Figura 5).

Figura 4 - Histórico do controle de versão de um projeto, mostrando lista de changesets

Figura 5 - Changeset com vários arquivos Shelveset: O recurso de shelveset é muito mais facilmente compreendido se imaginarmos primeiro os cenários que ele atende. Se você nunca passou por uma das situações abaixo enquanto usava o Visual SourceSafe, provavelmente deve conhecer alguém que já viveu isso:

• Depois de um dia inteiro de trabalho, as alterações ainda não foram concluídas. O dilema aqui é "faço check-in para não correr o risco de perder o que fiz mas atrapalho os outros" ou "não faço check-in para não atrapalhar os outros mas corro o risco de perder tudo"? A estação de trabalho do desenvolvedor não é um lugar seguro para se manter o trabalho de um dia inteiro. Normalmente as estações de uma rede não estão incluídas no backup automático da empresa, que costuma contemplar apenas os servidores. O mais seguro é sempre fazer o check-in e colocar o código num servidor com backup. Por outro lado, fazer check-in de um código incompleto significa que qualquer um que fizer um "Get Latest Version" depois deste ato não conseguirá compilar mais nada!

Para esta e outras situações semelhantes é que foi criado o shelveset (Figura 6). Pense nesse recurso como uma espécie de "check-in particular". Você pode fazer o commit das suas alterações (ou seja, seu changeset) que, ao invés de ir para o repositório principal do projeto, vai para uma área distinta com um nome definido por você. Desta forma é possível manter as alterações em curso, voltar para qualquer versão anterior (Figura 7), fazer a correção e depois combinar tudo para o check-in definitivo.

Figura 6 - Caixa de diálog de criação de shelveset

Figura 7 - Caixa de diálog de Unshelve

Check-in policy: Muitas vezes é desejável assegurar-se que o desenvolvedor que está prestes a fazer um check-in tomou certos cuidados para garantir a qualidade ou mesmo a rastreabilidade do código. Seria muito bom ter uma forma automática de lembrar os desenvolvedores que é preciso colocar comentários no changeset, associar as alterações a um determinado work item, ou ainda exigir que os testes unitários tenham sido executados para evitar que o check-in inviabilize o build? Melhor ainda seria se pudéssemos ser alertados caso um desenvolvedor esquecido tivesse ignorado estas regras, mesmo que tivéssemos tido o cuidado de lembrá-lo. É justamente para isso mesmo que foi criada a política de check-in (check-in policy, Figura 8).

Figura 8 - Caixa de diálogo de configurações de Check-in Policy

No TFVC é possível configurar um projeto de forma que o desenvolvedor será sempre lembrado de:

• Rodar a análise de código, para garantir que o código atende a padrões mínimos de qualidade - além de assegurar que a solução compila corretamente;
• Executar os testes unitários e prevenir o check-in caso haja algum erro;
• Associar o check-in a algum work item, de forma a obter uma excelente rastreabilidade das alterações.

No momento em que o usuário tenta um check-in, será avisado se alguma política não for satisfeita (Figura 9).

Figura 9 - Aviso de check-in policy não atendida

Além dessas políticas que vêm disponíveis no produto, você pode criar de forma bastante simples políticas personalizadas que atendem a seu processo. Copy-modify-merge: O modelo padrão de trabalho do Visual SourceSafe é o lock-modify-unlock, ou seja, a cada check-out é colocado um bloqueio exclusivo no arquivo que impede que outras pessoas o alterem simultaneamente. Depois de editarmos o arquivo, a operação de check-in irá desbloqueá-lo para que outros possam usá-lo. Esse modelo tem um grande inconveniente, que é o de reduzir a capacidade de trabalho em paralelo da sua equipe, especialmente para times e/ou projetos grandes. Já com o TFS, a idéia é que cada desenvolvedor tenha uma cópia do arquivo em seu computador. Se necessário, mais de uma pessoa pode trabalhar no mesmo arquivo ao mesmo tempo. Se duas pessoas alterarem o mesmo arquivo, no instante em que o segundo fizer seu check-in o TFS tentará mesclar (merge) as duas versões automaticamente. Se não for possível será exibida a tela de solução de conflitos (Figura 10 e Figura 11). Por mais que possa parecer assustador no primeiro momento, asseguramos que este é o modelo ideal de trabalho do ponto de vista da produtividade, pois permite efetivamente o escalonamento e o paralelismo do desenvolvimento.

Figura 10 - Caixa de diálogo de aviso de conflitos

Figura 11 - Solução manual de conflitos

Conclusão

É impossível classificar o TFVC simplesmente como uma evolução do Visual SourceSafe. Suas funcionalidades ultrapassam esta fronteira imaginária que poderíamos estabelecer. Apesar de o custo inicial de configuração de regras e controles ser alto e considerarmos também um razoável investimento em capacitação do seu time de desenvolvimento na ferramenta, continuamos acreditando que o esforço será plenamente recompensado. A frase de Joe Hummel, PHD e importante evangelista da Microsoft baseado nos Estados Unidos, em um webcast sobre o tema é sabiamente um resumo conclusivo digno de nossa análise quando avaliamos implantar o TFVC: _ "Sofrimento a curto prazo, ganhos reais a longo prazo". Sucesso em seus projetos.

Fabio Camara (fabio.camara@csharpbr.com.br) possui o título Microsoft MVP em VSTS e as certificações MCAD Charter, MCDBA, MCSE 2003, MCSD.NET, MSF Practitioner e ITIL Foundations - é Consulting Manager da FórumAccess Consultoria e membro fundador do VSTS Rocks Brasil Core Team (http://www.vstsrocks.com.br). Entre suas missões na FA implantou uma área de arquitetura e pesquisa, implantou uma área de testes e ajudou em várias áreas de processo na implantação do CMMI nível 3, especialmente CM.

Igor Leite (igoravl@gmail.com) possui as certificações MCAD, MCDBA e MCSD.NET - é arquiteto de soluções da FórumAccess Consultoria e membro fundador do VSTS Rocks Brasil Core Team (http://www.vstsrocks.com.br).