Recentemente tenho trabalhado com muitas aplicações e não dá para ter tudo instalado na mesma máquina por que vários serviços podem conflitar entre si, seja por versões ou duplicidade de instâncias, por exemplo versões de banco de dados de diferentes verões na mesma máquina.

O que fazer? Configurar VMs (Virtual Machines)!

Se você tem um PC relativamente novo já deve ter experimentado utilizar máquinas virtuais para emular algum sistema, por exemplo linux ou versões de sistemas betas e etc. Digamos que você queira ter um servidor *NIX rodando na sua máquina com um servidor web para desenvolvimento, seja Java/PHP/Python o que for, uma vez que em grande parte esses sistemas são colocados em produção nesses tipos de sistemas e não no Windows.

Estou usando o VMWare 2.0 para isso, agora estou de Mac e portanto estou usando a versão Fusion que é a única disponível dos produtos da VMWare. No caso do mundo Windows, temos Player, Workstation e Server. Usei também a versão Workstation 6.5.x.

Um pouco de teoria…

Acontece que a configuração padrão de rede é NAT que é um tradutor de endereços de rede. Veja a imagem abaixo para ilustrar a configuração NAT:

Como pode ver na figura acima, você tem uma máquina virtual rodando no seu computador e utiliza a interface de rede dele para acessar sua rede local. Veja que o recurso de rede é compartilhado, de modo que sua VM não fica exposta na rede externa, onde o seu computador atua como um “firewall”.

Digamos que eu queira expor meu servidor web para o resto da rede, neste caso na VM estou com a porta 80 aberta, porém o IP virtual que é configurado na VM não é visto pela rede. Entenda isso como o analogo a sua configuração de rede que provavelmente deve ter um roteador que interfaceia sua rede local com o seu provedor de acesso a internet. Ou seja, o pessoal de fora não vê seu PC e sim o roteador. Se desejarmos expor precisamos “traduzir” as requisições para que sejam enviadas ao destino correto, em nosso caso seu PC-Roteador ou VM-Computador.

Para entendermos melhor, precisamos entender como uma comunicação é feita, não vou entrar em muitos detalhes.

Para que você se conecte a uma máquina precisamos do endereço IP e a porta de comunicação. Digamos que vá acessar uma página na Web pelo seu navegador predileto. Você digita www.fabioyamate.com este endereço será traduzido para um endereço IP por servidores DNS e a requisição será enviada para a porta 80 (default), que é padronizada para servidores Web. Neste caso não explicitamos a porta, pois o navegador já estabelece isso por padrão. Se precisássemos de outra porta, digamos 8080, precisaríamos requisitar www.fabioyamate.com:8080.

Ok, agora que sabemos disso, como expomos a porta 80 da minha máquina virtual? Se você não entendeu o problema, veja que a porta 80 da sua máquina não é a mesma da máquina virtual. Precisamos ensinar que as requições que cheguem na porta 80 do meu computador vão para a porta 80 da minha máquina virtual, essa etapa é que chamamos de tradução.

Assim, queremos relacionar vm:80 <-> comp:80, poderíamos associar a portas diferentes, digamos: vm:80 <-> comp:12345. Então faríamos requisições para a porta 12345 para acessarmos o serviço rodando na máquina virtual.

Colocando em Prática

Agora que entendemos o conceito do funcionamento, precisamos saber como configurar isso na VM. No VMWare, novas interfaces de redes são adicionadas, que neste caso são virtuais. No VMWare Fusion, a tabela de tradução de endereços encontra-se no diretório:

/Library/Application Support/VMWare Fusion/vmnet8/nat.conf

Uma boa prática é sempre mantermos uma cópia da verão em funcionamento para caso realizemos uma besteira podemos restaurar.

sudo cp nat.conf nat.conf.backup
sudo vi nat.conf

Agora basta adicionarmos a tradução da seguinte forma:

porta_local_maquina = endereco_vm:porta_vm

Exemplo:

# Servidor Web
8080 = 172.16.250.130:80

Basta salvar o arquivo usando :wq! (pois o arquivo é readonly) no vi, se sentir dificuldade de uma navegada na internet, ou use outro editor a sua escolha.

Agora precisamos reconfigurar a interface virtual para que as alterações tenham efeito.

No diretório /Library/Application Support/VMWare Fusion temos um script boot.sh, assim digite:

sudo ./boot.sh –restart

Isso irá reconfigurar. Pode ser que necessite desligar a máquina virtual, mas normalmente não é necessário.

Com isso você já pode acessar de fora a máquina virtual configurada.

No Windows o processo é igual, mas é feito por interface gráfica, se não me engando Network Editor ou algo do gênero.

Note que se você usa algum firewall você deve liberar as portas da máquina virtual para que o serviço seja realmente exposto.

Um utilitário muito bom é o nmap que tem tanto para todas as plataformas. Basta usar o comando:

nmap -p <PORTA> <ENDERECO_IP>

ou

nmap -p <PORTA_INICIAL>-<PORTA_FINAL> <ENDERECO_IP>

Caso ping esteja restrito no firewall, use -PN.

Espero que este texto seja de ajuda.

Baseado no post anterior, pretendo escrever uma série de posts usando o TortoiseSVN para trabalhar com controle de versão num projeto que estou realizando, que se der pretendo colocar minhas experiências aqui, mas isto fica para outros posts.

O Visual Studio não possui integrado outros controles de versão senão o Visual Source Safe (VSS) da própria Microsoft. Eu já trabalhei com o VSS numa empresa o qual estagiei, mas era disponível para desenvolvimento numa rede local. Ter um servidor rodando Windows e com o VSS não é nada comum. Por este motivo optei pelo Subversion.

No post anterior, expliquei sobre como importar um projeto no repositório, dar checkout e realizar um commit simples. Agora vou citar algumas configurações que devem ser feitas quando lidamos com solutions do Visual Studio.

Uma solução é composta de 1 ou mais projetos, estas informações ficam no arquivo *.sln. Cada projeto é compilado e gera dois diretórios bin e obj. Estes arquivos não são de interesse ao controle de versão, uma vez que a responsabilidade dele é apenas gerenciar códigos.

Portanto, devemos eliminar estes diretórios do repositório para isso utilizamos properties do SVN, usando a property svn:ignore.

A configuração do property é particular de um diretório e fica registrado nos arquivos contidos no diretório .svn (ou _svn) que só podem ser vistos se alterar a visualização de arquivos do Windows para exibir arquivos ocultos. Pelo fato desta configuração ser inserida nestes diretórios, ao criarmos um projeto novo que não esta no repositório, esta informação não fica registrada para este projeto, resultando na adição dos diretórios bin e obj. Seria necessário selecionar manualmente cada arquivo que seria submetido excluindo tudo que tem relação com o diretório bin e obj.

Para este problema podemos declarar globalmente o que remover. Assim teremos de remover os seguintes arquivos para uma solução no SVN:

bin obj *.suo *.user

• bin e obj – são diretório de arquivos binários (compilados)
• *.suo – corresponde às configurações de usuário para a solução
• *.user – corresponde às configurações de usuário para o projeto

 

A seguir vou apresentar como realizar cada operação (inserindo properties e global ignore) e comentários sobre problemas que tive e como tratei eles.

Ignorando Diretórios e Arquivos no Subversion

Num diretório com o projeto gerenciado pelo SVN, clique com o direito e TortoiseSVN > Properties, como ilustra a figura abaixo:

 

Em seguida vamos adicionar uma properti svn:ignore com valores

bin obj *.suo *.user

Com espaços entre cada entrada. Marque a opção: Apply property recursively. Isso irá aplicar a todos os subdiretórios recursivamente a mesma property facilitando o trabalho de ter que replicar a mesma configuração para todos os diretórios.

Entretanto, os diretórios que não estão sobre controle (sem .svn/_svn) não terão esta restrição, entao ao dar um Add os arquivos não desejados serão adicionados, sendo necessário fazer a seleção manual. Para este problema a melhor solução é usar configurações globais de ignore aplicando isso a qualquer diretório.

Ignorando Globalmente Arquivos e Diretórios

Vá em TortoiseSVN > Settings

Adicione os elementos “bin obj *.suo *.user” como feito acima em “Global ignore patterns“

Agora o trabalho de dar Add simplificou, garantindo que será adicionado apenas arquivos de código ou necessários para a solução.

Problemas e Soluções

Um dos detalhes que tem que se considerar quando se trata de Visual Studio é que os arquivos que gerenciam os arquivos de solução e projeto, são atualizados somente se for realizando um build da solução e projeto.

Por exemplo, se adicionamos uma referência a um projeto ou *.dll o arquivo que gerencias estas referências será alterando somente se houver alguma classe que referêncie a ela, usando o using por exemplo.

Da mesma forma, para remover uma referência não utilizada mais, é preciso removê-la do references e em seguida executar um Build do projeto ou solução para que as alterações sejam registradas no arquivo e assim resultar numa nova versão do arquivo.

Outra situação é se você já deu commit nos arquivos que devem ser ignorados. O jeito é removê-los antes de aplicar o ignore, senão você não terá como dar commit nos arquivos deletados. Realize estas operações com a solução fechada no Visual Studio.

Uma vez corrigido você poderá aplicar as restrições e assim colocar ordem no repositório.

Todo desenvolvedor um dia irá trabalhar em equipe e não há como trabalhar sem um controle de versão. Temos vários sistemas para esta tarefa mas há dois principais: CVS (Concurrent Versions System) e SVN (Subversion). Entre eles o SVN, do que vejo, tem sido o mais usado.

Novamente, como no post anterior sobre o Grep, sou usuário Windows e interface é mais prático que linha de comando, pelo menos para mim.

Em termos de cliente para SVN o TortoiseSVN é o mais popular, e é mantido pelo próprio pessoal do SVN.

Pretendo, nos próximos posts mostrar como usar ele para trabalhar. Já trabalhei com Eclipse e Netbeans quando programei em Java e ambos integram diretamente com o IDE tanto para CVS como SVN.

No momento estou realizando um projeto em .NET usando Visual Studio, e infelizmente ele só trabalha com o Source Safe (da Microsoft) como controle de versão, não sendo possível usar o SVN nem o CVS diretamente. Existem soluções para isso, mas não é o intuito deste post.

Este post também não pretende mostrar como configurar um servidor local SVN, pode ficar para um outro post.

Baixe o TortoiseSVN aqui.

Importando o Projeto Inicial

Agora vou entrar num ponto em que me confundiu demais e acredito para outros também. No SVN o Import refere-se a Importar um projeto ao SVN e não importar um projeto do SVN, como da-se a entender.

Selecione o diretório com o projeto existe e clique com o botão direito sobre ele e TortoiseSVN > Import

Uma janela irá aparecer e será pedido a URL do servidor SVN e uma mensagem import.

Checkout

Uma vez feito isso é possível realizar o primeiro Checkout. O Checkout irá baixar uma versão do repositório podendo ser HEAD (a corrente) ou uma versão qualquer existente. Cada commit corresponde a uma versão.

Crie um diretório e com o botão direito Checkout SVN…

Após o checkout o diretório irá ficar marcado com um símbolo de OK.

Adicionando Arquivos ao Repositório

Crie um arquivo no diretório o qual o projeto está guardado e clique em TortoiseSVN > Add.

Um sinal de “+” será marcado no arquivo dizendo que ele foi adicionado. Isso é necessário sempre que um novo arquivo for criado. O diretório com alterações ficará marcado com uma “!”

Feito esta etapa o arquivo ainda não foi submetido ao repositório, para isso é necessário realizar um commit.

TortoiseSVN > Commit

Será pedido uma mensagem identificando o motivo do commit. É importante ser claro e objetivo para que quando necessário retornar um versão saber a que ela representa.

Uma vez realizado o commit a revisão será incrementada e o diretório ficará marcado com um OK novamente.

Até um próximo post sobre o TortoiseSVN.