www.devmedia.com.br
[versão para impressão]
Link original: http://www.devmedia.com.br/articles/viewcomp.asp?comp=4263

Revista MSDN Magazine Edição 11 - A Arte de Versionar Integrando o VS.NET ao Visual SourceSafe (Parte I)

Artigo Originalmente Publicado na MSDN Magazine Edição 11

msdn11_capa.jpg

Clique aqui para ler todos os artigos desta edição

 

A Arte de Versionar

Integrando o VS.NET ao Visual SourceSafe

(Parte I)

por André Furtado

 

Costuma-se dizer que a única certeza de um novo projeto de software é que o mesmo sofrerá mudanças. Apesar de tal afirmação estar focada nas mudanças de requisitos, ela é perfeitamente aplicável ao item que mais está sujeito a alterações em um projeto: seu código-fonte. Desse modo, o popularmente adotado processo de desenvolvimento incremental de software, caracterizado por sucessivos builds, releases,  patches e correções, pode-se tornar um sério risco ao projeto caso não haja um gerenciamento produtivo e eficaz da evolução do código-fonte, assim como do controle de seu compartilhamento entre os desenvolvedores. Através deste artigo você encontrará na ferramenta Visual SourceSafe (VSS) uma poderosa aliada para automatizar e gerenciar o controle de versão de seus projetos, além de descobrir como aumentar consideravelmente a produtividade de sua equipe através da integração do VSS com o Visual Studio .NET.

Nesta primeira parte, você entenderá o porquê do controle de versão, os fundamentos básicos do VSS e como implantar a ferramenta, além de descobrir que cuidados devem ser tomados com suas soluções e projetos no VS.NET para garantir um controle versão eficiente.

Por que versionar?

Ao contrário de muitos problemas e soluções que existem na Tecnologia da Informação, o controle de versão não é uma necessidade originada pelas recentes tecnologias ou pela complexidade do atual processo de desenvolvimento de software. Na verdade, desde que um programador necessitou desenvolver sucessivas versões para sua aplicação e desde que duas pessoas (e não apenas uma) decidiram somar seus esforços para implementar uma aplicação, criou-se a necessidade pela Gerência de Configuração.

Se você não está antenado com processos e a Engenharia de Software em geral, talvez nunca tenha ouvido falar em Gerência de Configuração. Entretanto, a verdade é que ela está cada vez mais em evidência e merecendo a atenção dos projetos de software da atualidade (existem, inclusive, profissionais especializados apenas nessa área: os gerentes de configuração). Em resumo, a Gerência de Configuração é um processo que, através do controle e organização da evolução do software em construção, procura maximizar a produtividade e diminuir a burocracia do projeto, evitando desperdício de trabalho e enganos comuns cometidos por desenvolvedores.

O cenário a seguir exemplifica alguns problemas decorrentes da ausência de um processo adequado de Gerência de Configuração. Imagine que dois desenvolvedores, João e Maria, estão trabalhando conjuntamente na implementação de um software, conforme mostra a Figura 1. Além de desenvolver suas próprias classes (J1, M1, J2, M2, etc.), João e Maria estão compartilhando a classe C, mostrada ao centro da figura. Suponha que João acessa a classe compartilhada e realiza algumas modificações na mesma. Mais tarde, Maria também realiza algumas alterações em C mas, ao tentar compilar suas classes (M1, M2 e M3) com C, diversos erros são apontados pelo compilador, nenhum deles na parte que Maria alterou. Resultado: Maria não tem a menor idéia sobre a causa do problema, portanto não sabe resolvê-lo e está com seu desenvolvimento bloqueado!

 

 

image002.jpg

Figura 1. João e Maria desenvolvem software, compartilhando a classe C

 

Você poderia propor a seguinte solução: que tal se cada desenvolvedor trabalhasse com uma cópia local da classe compartilhada, salvando-a em um repositório comum a cada alteração, como mostra a Figura 2? Sim, esta abordagem resolve a situação anterior, mas cria um outro problema.

 

image004.jpg

Figura 2. João e Maria desenvolvem software, utilizando cópias locais (CJ e CM) da classe compartilhada

 

Suponha que João encontre e corrija um defeito em sua versão local da classe compartilhada, salvando esta alteração na classe C do repositório. Maria, com sua versão local desatualizada, pode encontrar e corrigir o mesmo defeito já corrigido por João. Resultado: o trabalho de João é desperdiçado! Uma situação pior ainda se dá quando João encontra e corrige um defeito, salvando C no repositório, e Maria, ainda com sua versão local desatualizada, encontra e corrige um outro defeito, também salvando suas modificações no repositório. Além do trabalho de João ser desperdiçado, a versão atual de C no repositório continua com um defeito, embora João considere-o como resolvido.

Estes cenários ilustram como um simples projeto de software pode ficar prejudicado sem a existência de um repositório para o código-fonte e de um controle adequado para a entrada e saída de itens nesse repositório. Desse modo, um bom planejamento e execução do controle de versão deve ser considerado, permitindo produtividade e sincronia entre os desenvolvedores.

Apresentando o Visual SourceSafe

Se você nunca utilizou um mecanismo de controle de versão, espero que os argumentos da seção anterior tenham despertado seu interesse na utilização do VSS, uma ferramenta de controle de versão baseada no modelo cliente-servidor, conforme a Figura 3. Entretanto, você poderia afirmar que já trabalha com controle de versão, porque já foi criado um “local central” para o código-fonte de seus projetos e foi combinada uma política entre os desenvolvedores para saber quem está trabalhando com um determinado arquivo em um dado momento. A questão é: Por que você precisaria de uma ferramenta?

Parte da resposta consiste no fato de que o VSS permite a realização de suas atuais políticas de controle de versão de maneira mais rápida, confiável e automatizada, além de funcionalidades que seriam complicadas de se obter com um sistema de controle de versão ad hoc. Por exemplo, é possível verificar que o arquivo index.aspx acabou de ser modificado pelo usuário João e, antes disso, Cliente.cs foi adicionado ao projeto EntidadesBasicas por Maria; recuperar o projeto CamadaDeDados excluído acidentalmente por João;  criar um rótulo (como “Beta Final”) para todos os arquivos da solução; recuperar, a qualquer instante, o estado exato da solução no momento em que o rótulo foi aplicado e, por fim, visualizar diferenças entre duas versões de um mesmo arquivo, rejeitando ou aceitando, através de um suporte visual, as mudanças encontradas.

 

image006.jpg

Figura 3. Componentes do VSS: um servidor central (repositório) e múltiplos clientes

 

Além desses benefícios, o VSS traz mais uma vantagem para o desenvolvimento colaborativo, controlado e produtivo de software: a integração com o ambiente integrado de desenvolvimento Visual Studio .NET. Desse modo, os desenvolvedores participam do controle de versão sem a necessidade de interagir diretamente com o VSS, pois todos os comandos são executados a partir do próprio VS.NET. Os principais comandos e conceitos do VSS são:

·         Repositório (ou “base VSS”): espaço no servidor VSS em que os arquivos de uma aplicação estão armazenados. Um repositório também contém versões antigas da aplicação e geralmente está sujeito a políticas de acesso.

·         Área local de trabalho: espaço na estação de trabalho de um desenvolvedor, no qual ele descarrega cópias da aplicação a partir do repositório e realiza suas modificações.

·         get latest version: ação de recuperar a última versão de um arquivo do repositório, criando uma cópia apenas para leitura (read-only) na área local de trabalho.

·         check out: ação de recuperar a última versão de um arquivo do repositório, criando uma cópia editável (read/write) na área local de trabalho. Por padrão, quando você executa check out em um arquivo, você detém seu controle exclusivo (outros desenvolvedores não poderão executar check out no arquivo, embora ainda possam executar get latest version). Costuma-se dizer que um arquivo está “checado” quando algum usuário executou check out no mesmo.

·         check in: ação de inserir ou atualizar, no repositório, um arquivo checado. Por padrão, o controle exclusivo do arquivo é perdido após o check in.

·         undo check out: desfaz o check out de um arquivo, isto é, o arquivo volta a estar liberado para os demais desenvolvedores. Nenhuma atualização é feita no arquivo do repositório quando o mesmo sofre undo check out.

·         label: ação de rotular um conjunto de arquivos do repositório

 

Este é, portanto, o funcionamento básico do VSS: um desenvolvedor executa check out em um arquivo (bloqueando-o aos demais usuários), faz suas alterações locais e depois realiza check in desse mesmo arquivo. Caso seja identificado que as mudanças realizadas localmente possam acarretar problemas futuros, o desenvolvedor executa undo check out ao invés de check in. Um gerente de configuração, por fim, executa o comando label após a conclusão de uma etapa da implementação, como um release interno.

Contextualizando o Visual SourceSafe

O controle de versão e a Gerência de Configuração em geral não existem por si sós. Pelo contrário, estão inseridos em um contexto de desenvolvimento muito maior, caracterizado pela interação entre processos, estações de trabalho e servidores de diferentes propósitos. A Figura 4 ilustra esse cenário (as setas circulares azuis são alguns dos diferentes processos do ciclo de vida de software).

 

image008.gif

Figura 4. Servidor VSS no contexto dos demais elementos no processo de desenvolvimento de software

 

Como é possível observar, o processo de desenvolvimento não é o único com o qual um servidor VSS pode interagir. A produtividade de seu projeto pode ser consideravelmente aumentada caso sua equipe disponha de um processo de geração de build, na qual uma máquina, denominada “servidor de build”, realiza periodicamente a operação get latest version do servidor VSS e compila a aplicação, podendo, inclusive executar alguns scripts de teste para garantir a corretude da versão mais recente da aplicação. Caso ocorram falhas na compilação da aplicação ou na execução dos scripts de testes, um e-mail contendo um log sobre a geração do build pode ser enviado ao gerente de configuração e à equipe, permitindo que ações corretivas sejam prontamente executadas.

O processo de geração de build é ainda mais útil quando combinado com outros processos, como o de testes e o de geração de release (“empacotamento”) da sua aplicação. Por ora, saiba que o VSS pode ser estendido e automatizado de acordo com as suas necessidades, de modo a se integrar com os processos de ciclo de vida de software. Existem diversas ferramentas, como o BuiltIt, capazes de gerenciar com maestria essa integração (consulte os links no final do artigo).

Implantando o Visual SourceSafe

O Visual SourceSafe 6.0 acompanha as versões Developer e Enterprise do VS.NET, mas não é instalado por padrão. Como o VSS se trata de uma aplicação cliente-servidor, você deverá executar sua instalação de duas maneiras diferentes, dependendo da máquina-alvo.

Após executar o setup.exe do CD de instalação o VSS, escolha a opção Shared Database Server para instalar o módulo servidor do VSS, que armazena e controla os arquivos versionados, além de oferecer um console administrativo através do qual é possível gerenciar usuários e aplicar configurações específicas ao controle de versão (veja a Figura 5). Após a instalação, compartilhe a pasta em que foi instalado o VSS com acesso a leitura, para permitir que clientes do VSS visualizem e executem o arquivo de instalação de rede Netsetup.exe.

 

image010.jpg

Figura 5. Console administrativo do VSS

 

O próximo passo é utilizar o console administrativo do VSS para criar uma nova base VSS (menu Tools / Create Database). É recomendada a criação dessa nova base (e não a utilização da base default do VSS), por motivos de segurança. Além disso, ela não deve ser criada em um subdiretório de Arquivos de Programas.

Você deve considerar a criação de bases adicionais caso sua base atual esteja excedendo 4GB, pois bases acima deste tamanho tornam lentas as tarefas administrativas. Uma opção adicional é criar bases separadas para projetos de software independentes (por exemplo, em uma base podem estar as soluções internas da sua organização, enquanto outras bases armazenam soluções desenvolvidas para clientes). Com esta divisão, tarefas como manutenção e backup de uma base se tornam mais produtivas.

Uma vez criada a base VSS, compartilhe seu diretório dando controle total aos usuários da rede do Windows que terão acesso ao VSS (tipicamente, esses usuários são desenvolvedores e contas utilizadas pelo processo de geração automática de builds)[1]. Como a segurança integrada do VSS não é total, você ainda precisa criar contas de usuário VSS através do console administrativo (menu Users / Add User). Entretanto, quando um cliente VSS tenta logar em uma base VSS através do VS.NET, a ferramenta procura saber se existe uma conta VSS com o mesmo nome do usuário de rede do Windows que está logado. Caso verdadeiro, essa conta VSS será utilizada para o logon, não sendo necessário ao usuário informar suas credenciais. Caso contrário, a janela de diálogo de logon do VSS será exibida (conforme a Figura 6).

 

image012.jpg

Figura 6. Diálogo de logon do VSS

 

Outra situação em que o VSS não executará logon automaticamente, mesmo no caso em que os nomes das contas VSS e de rede do Windows são os mesmos, acontece quando você solicita a adição de uma solução ou projeto ao controle de versão. Isso acontece porque o diálogo de logon é utilizado também, nesse caso, para que você especifique a base VSS na qual pretende adicionar a solução ou o projeto (campo Database da Figura 6). Entretanto, caso você abra uma cópia local de uma solução ou projeto que já faz parte do controle de versão, o cliente do VSS no VS.NET fará seu logon silenciosamente.

É importante não confundir as permissões de acesso ao compartilhamento do diretório da base VSS (através do Windows Explorer), atribuídas às contas de usuário de rede do Windows, com as permissões de execução de comandos (check in, check out, etc.) na base VSS, atribuídas às contas de usuário do VSS. Esses comandos só podem ser executados através da interface do VSS ou de uma ferramenta integrada, como o VS.NET, enquanto o acesso via Windows Explorer ao diretório da base sequer permite a visualização dos arquivos versionados (pois o VSS possui um mecanismo próprio para o armazenamento físico dos dados). Por segurança, é interessante instruir os usuários do VSS para que eles não utilizem a mesma senha para a conta do VSS e para a conta de rede do Windows. Adicionalmente, você pode especificar detalhes de autorização habilitando a opção Enable Rights and Assignments commands, acessível através do menu Tools / Options / guia Project Rights. Feito isso, será possível acessar uma opção do menu Tools anteriormente desabilitada, chamada Rights By Project. Esta opção permite o controle detalhado de acesso de cada usuário a cada diretório da base VSS, como mostra a Figura 7.

 

image014.jpg

Figura 7. Especificando permissões detalhadas para cada diretório da base VSS

 

Recomenda-se remover a permissão Destroy de todos os usuários garantindo que o administrador do VSS sempre possa recuperar um arquivo deletado por um desenvolvedor. A remoção definitiva dos arquivos deletados deve ser uma tarefa periódica do administrador, assim como a execução da ferramenta auxiliar Analyze, que acompanha o VSS, para checar e corrigir corrupção de dados.

Para instalar o módulo cliente do VSS nas estações de trabalho, por fim, execute o arquivo Netsetup.exe localizado no compartilhamento do diretório de instalação do VSS no servidor. Esta instalação habilitará a integração do VSS com o VS.NET, portanto, é recomendado que o VS.NET já esteja instalado antes da execução do Netsetup.exe.

O que é versionado?

Os desenvolvedores são encorajados a utilizar apenas a interface do VS.NET  para interagir com o VSS, e nunca o VSS diretamente, pois o VS.NET submete ao VSS apenas o que é necessário ao controle de versão, ignorando os arquivos de configuração específicos de um desenvolvedor. Por exemplo, os seguintes arquivos não são submetidos ao VSS:

·         Arquivos .suo (solution user options), que contêm customizações personalizadas do VS.NET definidas por um desenvolvedor, como o tamanho de cada janela dentro da IDE;

·         Arquivos .csproj.user ou .vbproj.user, que contêm opções de projeto específicas para um desenvolvedor, como caminhos opcionais para que o VS.NET localize os assemblies referenciados pelo projeto;

·         Arquivos .csproj.webinfo ou .vbproj.webinfo, que especificam o diretório virtual de um projeto Web na máquina de um desenvolvedor;

·         Outputs dos projetos da solução, como assemblies (dll e executáveis). É importante observar que assemblies externos à solução (isto é, que não são gerados pelo processo de build) devem ser adicionados aos projetos que os referenciam (como normalmente é feito com arquivos .bmp, por exemplo), de modo a fazerem parte do controle de versão e serem submetidos ao VSS pelo VS.NET.

 

Por outro lado, os seguintes tipos de arquivo dizem respeito a todos os desenvolvedores e são submetidos ao controle de versão pelo VS.NET:

·         Arquivos .sln, que contêm as informações sobre uma solução, como a lista dos projetos que a constituem e informações de dependência, por exemplo;

·         Arquivos .csproj ou .vbproj, que contêm as informações sobre um projeto, como a lista dos arquivos que o constituem e os assemblies referenciados, por exemplo;

·         Arquivos de configuração da aplicação (App.config ou Web.config), que controlam vários aspectos da aplicação em tempo de execução;

·         Arquivos de código fonte (.cs, .vb, .aspx, .asax, .resx, .vsdisco, .css, etc.).

Estruturando soluções e projetos

Você está quase pronto a submeter sua primeira solução ao controle de versão. Entretanto, de modo a garantir um controle de versão organizado e eficiente, alguns cuidados devem ser tomados no VS.NET antes mesmo de utilizar o VSS. O principal deles é pensar antecipadamente em como estruturar as soluções e projetos necessários para a aplicação. A abordagem mais adequada é utilizar o modelo de solução simples, em que apenas uma solução funciona como um container para todos os projetos da aplicação (veja a Figura 8).

A principal vantagem é que, caso um projeto necessite fazer referência a um assembly gerado por um outro projeto, uma referência de projeto pode ser utilizada, conforme a Figura 9, não sendo necessário utilizar referência de arquivo. Isto é interessante porque referências de projeto funcionam em qualquer máquina de desenvolvimento sem a necessidade de ajustes, mesmo que o caminho físico da solução e de seus projetos sejam diferentes. Além disso, o VS.NET consegue inferir a ordem em que os projetos devem ser compilados a partir das referências de projeto.

 

image016.jpg

Figura 8. O modelo de solução simples

 

image018.jpg

Figura 9. Adicionando referências de projeto a um outro projeto

 

Outra vantagem do modelo de solução simples é que o VS.NET gerencia automaticamente a necessidade de recompilação de um projeto. Além disso, alterações na configuração de compilação da solução, como exibido na Figura 10 são propagadas a todos os projetos da solução e não demandam a atualização de referências. Por fim, o processo de geração de build e os scripts de builds a serem utilizados são mais simples quando o modelo de solução simples é utilizado.

 

image019.gif

Figura 10. Selecionando a configuração de compilação da solução

 

Você deve conseguir trabalhar sem problemas com até 30 projetos no modelo de solução simples. Entretanto, essa abordagem pode não corresponder a sua realidade e possui algumas desvantagens:

·         Mesmo que você deseje trabalhar com apenas um único projeto da solução no momento, você será obrigado a adquirir todos os projetos da solução;

·         Qualquer mudança simples em um projeto, como uma atualização de comentário, pode resultar na reconstrução imediata de vários outros projetos. Isso pode levar bastante tempo, principalmente para soluções com um grande número de projetos;

 

Se a aplicação a ser desenvolvida realmente demanda um número considerável de projetos e você não pode conviver com essas desvantagens considere a utilização do modelo de solução simples particionado. Aqui, além de uma solução principal que agrupa todos os projetos, existem “subsoluções” que englobam apenas um subconjunto dos projetos (veja a Figura 11).

 

image021.jpg

Figura 11. O modelo de solução simples particionado

 

Este modelo é interessante para grandes projetos, pois permite o trabalho em um subconjunto de projetos da solução sem a necessidade de se obter todos os projetos da mesma. Além disso, é possível que um projeto individual seja alterado sem a obrigatoriedade de recompilação imediata de todos os demais projetos da solução. A solução principal (S, na Figura 11) engloba todos os projetos e é utilizada para reconstruir facilmente toda a aplicação, sendo, portanto, utilizada também no processo de geração de build. Por fim, referências de projeto e seus benefícios continuam sendo utilizados.

O modelo de solução simples particionado, também possui suas desvantagens. Quando você deseja adicionar um novo projeto, você precisará atualizar mais de uma solução. Além disso, podem existir algumas restrições no particionamento dos projetos em subsoluções, minimizando os benefícios dessa abordagem. Por exemplo, se você deseja trabalhar nos projetos de interface gráfica, como aplicações ASP.NET, fatalmente precisará obter muitos outros projetos referentes às camadas inferiores de sua aplicação.

A escolha entre os dois modelos apresentados depende da aplicação a ser desenvolvida. Sempre que possível, prefira a utilização do modelo de solução simples, a não ser que a complexidade da aplicação realmente demande o modelo de solução simples particionado. Existe ainda um modelo chamado modelo  multi-solução. Este modelo é parecido com o modelo de solução simples particionado, sendo a principal diferença a inexistência de uma solução principal (isto é, existem apenas subsoluções). Apesar deste modelo facilitar a adição de novos projetos, ele deve ser evitado sempre que possível, pois neste caso o assembly gerado por um projeto é referenciado por projetos de outra solução através de referências de arquivo, e não mais por referências de projeto. Isto dificulta a determinação da ordem de compilação dos projetos (que não poderá mais ser inferida pelo VS.NET), além de exigir a alteração manual das referências caso a configuração de compilação da solução (Figura 10) seja alterada.

Além da estruturação da solução e projetos, outros cuidados devem ser tomados antes da utilização do VSS:

·         Pense antecipadamente nos nomes para suas soluções, seus projetos, pastas e assemblies. Apesar de ser possível renomear esses itens posteriormente, isso deve ser evitado;

·         Mantenha a consistência entre o nome de um assembly e o nome do projeto que o gerou. Por exemplo, deve ser possível assumir que o assembly Northwind.Util.Data.dll foi gerado pelo projeto Northwind.Util.Data. Caso você modifique o nome de um assembly considere modificar o nome do projeto, e vice-versa;

·         O nome de um projeto e do assembly gerado pelo mesmo devem estar consistentes com o nome do namespace definido no projeto. Por exemplo, é de se esperar que o assembly Northwind.Util.Data.dll tenha sido gerado a partir dos tipos (estruturas, classes, interfaces, etc.) definidos no namespace Northwind.Util.Data. Na necessidade de haver mais de um namespace no projeto, é interessante que eles possuam a mesma raiz, como Northwind.Util.Data.Client e Northwind.Util.Data.Company.

 

A definição de uma estrutura de diretórios adequada para suas soluções e projetos, criados no VS.NET, é outra etapa simples, porém importante, para o controle de versão. A estrutura de diretórios ideal é aquela em que o modelo de solução simples é aplicado e existe um diretório para a solução e um subdiretório para cada um dos projetos da solução. De modo a garantir esta estrutura, entretanto, alguns cuidados devem ser tomados no VS.NET tanto para projetos locais quanto para projetos Web.

Cuidados na criação de projetos locais

Quando você cria um novo projeto local (Windows ou Console Application, por exemplo) para uma nova solução no VS.NET, a IDE sugere, por padrão, um único diretório tanto para a solução quanto para o projeto, contrariando a estrutura ideal de diretórios apresentada anteriormente. Felizmente, podemos informar ao VS.NET que gostaríamos de ter a nova solução em um diretório pai e o novo projeto em um subdiretório filho. Para isso, clique no botão More quando você for criar um novo projeto para a nova solução, conforme a Figura 12.

 

image023.jpg

Figura 12. Criação de um novo projeto no Visual Studio .NET

 

Marque o checkbox Create directory for Solution (conforme a Figura 13) e digite o nome da nova solução no campo New Solution Name, o qual será utilizado para a criação de um diretório específico para a solução.

image025.jpg

Figura 13. Informando um diretório específico para a nova solução.

 

Observe a diferença do label Project will be created at, entre a Figura 12 e a Figura 13. Na primeira, o projeto será criado no diretório C:\Temp\MyWindowsApp, no qual também seriam salvos os arquivos da solução. Na segunda o projeto será criado em C:\Temp\MySolution\MyWindowsApp, havendo, portanto, uma hierarquia de diretórios entre a solução (que será criada em C:\Temp\MySolution) e o projeto. Sempre que você adicionar outros projetos à solução, certifique-se, através do label Project will be created at, que esta hierarquia está sendo respeitada.

Cuidados na criação de projetos Web

Por padrão, quando você cria um projeto Web (como uma ASP.NET Web Application, por exemplo) no VS.NET, os arquivos do projeto são colocados em um diretório virtual que fisicamente é um subdiretório do seu Default Web Site (geralmente \inetpub\wwwroot), enquanto os arquivos da solução são colocados em um subdiretório de \Meus Documentos\Visual Studio Projects. Isso vai de encontro à estrutura ideal de diretórios, pois não há com esta configuração uma hierarquia pai-filho entre a solução e o projeto. Para resolver este problema, você precisa realizar o seguinte procedimento:

·         Crie uma solução em branco no VS.NET (menu File / New / Blank Solution), especificando um nome para a solução como, por exemplo, MyWebSolution.

·         Através do Windows Explorer, localize o diretório MyWebSolution. Dica: através das propriedades da solução, você pode encontrar facilmente seu diretório físico.

·         Crie através do Windows Explorer um subdiretório (por exemplo, MyWebApp) no diretório MyWebSolution. É neste subdiretório que os arquivos do projeto Web estarão localizados.

·         Através do IIS ou do próprio Windows Explorer, transforme o subdiretório MyWebApp em um diretório virtual.

·         Volte ao VS.NET e solicite a adição de um novo projeto Web à solução. No campo Location, como mostra a Figura 14, especifique o endereço http correspondente ao diretório virtual criado (http://localhost/MyWebApp).

 

image027.jpg

Figura 14. Especificando a localização para um novo projeto Web.

Conclusão

Nesta primeira parte deste artigo, você compreendeu os problemas ocasionados pela ausência de controle de versão e foi apresentado ao Visual SourceSafe, ferramenta baseada na arquitetura cliente-servidor que objetiva resolver tais problemas. Adicionalmente, você aprendeu os conceitos básicos do VSS, seu contexto no ciclo de vida de desenvolvimento e como implantar a ferramenta, além de ter identificado as abordagens de estruturação e os cuidados necessários com projetos e soluções do VS.NET para a permitir uma integração eficiente com o VSS.

Na segunda parte, identificaremos as mudanças de interface do VS.NET ocasionadas pela instalação do VSS e desenvolveremos uma pequena aplicação submetida ao controle de versão, aplicando os conceitos aqui apresentados e identificando boas práticas de um desenvolvimento submetido à Gerência de Configuração.

Referências:

Team Development with Visual Studio .NET and Visual SourceSafe

       http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg_rm.asp

Managing Projects in Visual SourceSafe

http://msdn.microsoft.com/library/en-us/dnvss/html/msdn_mngproj.asp

Microsoft Knowledge Base

http://search.support.microsoft.com

[awbf1] 

OLHO1:[awbf2]  Sem controle de versão e políticas organizacionais bem definidas, a produtividade em um projeto de software jamais será proporcional à quantidade dos recursos envolvidos.

OLHO2:[awbf3]  A integração do VS.NET com o VSS permite que os desenvolvedores participem do controle de versão sem precisar abandonar o VS.NET.

OLHO3:[awbf4]  O VS.NET submete ao VSS apenas o que é necessário ao controle de versão, ignorando os arquivos de configuração específicos de um desenvolvedor.

OLHO4[awbf5] : [awbf6] Para garantir um controle de versão organizado e eficiente, alguns cuidados devem ser tomados no VS.NET antes mesmo de utilizar o VSS.


[1] Caso você não deseje oferecer controle total aos usuários VSS, será necessário buscar informações mais detalhadas na Microsoft Knowledge Base (artigo Q131022) para identificar exatamente os privilégios necessários.

 [awbf1]Obs.: Os olhos abaixo não são exatamente uma cópia do texto no artigo, mas expressam resumidamente um conceito estudado em uma seção. Sinta-se à vontade para excluir um olho caso falte espaço.

 [awbf2]esse olho deve ficar na seção “Por que versionar?”

 [awbf3]esse olho deve ficar na seção “Apresentando o Visual SourceSafe”

 [awbf4]esse olho deve ficar na seção “O que é versionado?”

 [awbf5]esse olho deve ficar na seção “estruturando soluções e projetos”

 [awbf6]Confira todos os olhos de acordo com o texto alterado

André Furtado

Guru .net e tecnologias MS