Colaboração em projetos Rails e Django usando o Github

Nos posts anteriores, foi mostrada a criação de projetos Rails e Django, e explicado o uso do Bundler e do PIP para gerenciamento de dependências do projeto. Foi mostrado também como iniciar servidores web com os comandos

rails s

e

python manage.py runserver,

nos projetos recém criados, bem como os utilitários para acesso rápido a banco de dados

rails db

e

python manage.py dbshell.

Já temos material suficiente para iniciar um repositório Git, compartilhar no Github, e o mais importante: testar o workflow de colaboração em diferentes máquinas. Este passo é muito importante, para verificar se o setup inicial do projeto está suficientemente simples e documentado, permitindo que outros colaboradores, sem dor de cabeça, possam baixar e configurar o projeto em suas máquinas.

Adicionando o projeto Rails no Github

Clonando o projeto

Na listagem acima, o projeto é clonado do github através do comando

git clone

Em seguida, o diretório do projeto recém clonado é listado. Porém, a despeito da presença do arquivo .rvmrc na raiz do projeto, nada acontece ao entrar no diretório, sendo que era esperado que o RVM carregasse o ambiente Ruby do projeto.

Neste post foi mostrado que o .rvmrc pode ser usado para executar um script

rvm use 1.9.2@ambiente_app_contatos

para carregar o ambiente ruby ao entrar no diretório.

Nesta nova máquina, porém, o RVM ainda não está instalado, portanto, os scripts do arquivo .rvmrc não foram executados. O projeto tem, portanto, um pré-requisito de configuração de ambiente após ser clonado: instalar o RVM e o Ruby 1.9.2.

Graças a este simples teste, foi possível detectar o mais cedo possível a necessidade de documentar este fato.

O arquivo README

Neste ponto, a opção mais simples é documentar este pré-requisito, criando um arquivo README. Tudo bem, tudo bem, muitos de nós desenvolvedores nem sempre dá a atenção devida a este tipo de documentação tão primária. Porém isso não nos exime de escrevê-la, com pelo menos as informações gerais do projeto e as instruções de setup para que ele seja facilmente configurado e executado ṕor qualquer desenvolvedor.

Um ponto para o Github: o README é mostrado na página principal do projeto, o que melhora bastante sua exposição e aumenta a probabilidade de ele ser lido por novos desenvolvedores ao baixar o projeto.

Vale notar também que este arquivo pode ser escrito usando linguagens de marcação como o markdown e o textile, melhorando ainda mais a sua apresentação e legibilidade.

Colocada a importância de fornecer um arquivo README, visite a página inicial do projeto e avalie você mesmo o quanto essas instruções podem ser úteis ao clonar um projeto.

Documentação executável

Um fato interessante que comumente ocorre ao escrever um README é perceber que vários passos de setup inicial podem ser facilmente automatizados em arquivos de script. Foi exatamente o que aconteceu enquanto documentei o setup deste projeto: o README deu origem ao arquivo setup-project, que pode ser executado com o comando:

source ~/App-Contatos-Rails/setup-project

Ao final, este exercício de documentação levou também o benefício da automatização :-)

Adicionando o projeto Django no Github

Clonando o projeto

Similarmente como ocorreu ao clonar o projeto Rails em uma outra máquina (que não tinha o RVM instalado), ao entrar no diretório do projeto, não ocorreu o carregamento automático do VirtualEnv configurado no arquivo .rvmrc.

As instruções de setup - para instalação do RVM e do VirtualEnv - também foram documentadas num README, cujas instruções foram facilmente aproveitadas para a criação de um script setup-project:

O arquivo .gitignore em projetos Django

À medida que vamos trabalhando na aplicação, são gerados alguns arquivos que não precisamos versionar no Git. Por exemplo, os arquivos compilados do python (*.pyc) e o arquivo do banco de dados sqlite local. Para evitar que estes arquivos sejam submetidos para o Git, podemos adicionar um arquivo .gitignore ao projeto:

Nota: Em aplicações Rails, este arquivo é gerado junto com a criação da aplicação. Isso pode ser notado na listagem do início deste post que mostra o commit inicial do projeto, com o arquivo .gitignore já presente.

Apesar de esta versão inicial estar bem simples, novas adições podem ser feitas todas as vezes que se perceber que um diretório ou um padrão de arquivos não precisa ser controlado pelo Git.

Procurando no Google por palavras chave [Django .gitignore] são listados vários exemplos de arquivos .gitignore mais abrangentes - para este post, prefiro manter as coisas simples.

Caso já tenha comitado arquivos indesejados para o Git, além de adicionar o padrão no arquivo .gitignore, é necessário também remover os arquivos comitados - nada que não poassa ser resolvido com o git rm.

Considerações Finais

Ao iniciar um projeto, é muito importante colocá-lo o mais cedo possível num repositório de controle de versão. São inúmeros os benefícios: backup, versionamento desde as primeiras versões, compartilhamento, e geração da documentação mínima necessária para que o projeto seja facilmente configurável e acessível para outros desenvolvedores, pra citar alguns.