Temos portanto dois problemas a serem resolvidos. O primeiro problema, relacionado a automatização de tarefas repetitivas, pode ser facilmente solucionado com Fabric, uma ferramenta muito útil para criação de scripts de build e deployment de aplicações. Já escrevemos um texto introdutório sobre a mesma, não deixe de conferir.

O segundo problema, entretanto, é um pouco mais complicado de se resolver, mas não é nenhum bicho de sete cabeças. Com VirtualEnv, é possível criar ambientes Python isolados com o objetivo de testar e executar aplicações em uma espécie de sandbox onde temos total controle sobre as bibliotecas ali instaladas.

Instalando as diferentes versões do Python

O primeiro passo é instalar as versões do Python a serem usadas nos testes. Rode o comando abaixo para instalar os diferentes interpretadores, supondo que você utilize Debian e sua aplicação precise funcionar nas versões 2.4, 2.5 e 2.6 do Python:

$ sudo apt-get install python2.4 python2.4-dev \
    python2.5 python2.5-dev \
    python2.6 python2.6-dev

A versão atual do Ubuntu já inclui o Python 2.6 por padrão. Veja também que aproveitamos para instalar os arquivos de desenvolvimento para cada versão, pois eventualmente precisamos deles para compilar bibliotecas com extensões escritas em C.

Instalando Fabric e VirtualEnv

Da mesma forma:

$ sudo apt-get install python-setuptools

Após a instalação do SetupTools, execute o seguinte comando para instalar o Fabric e o VirtualEnv:

$ sudo easy_install Fabric virtualenv

Configurando ambientes isolados para sua aplicação

O próximo passo é criar ambientes de execução isolados para sua aplicação, sendo que cada ambiente deve usar uma versão diferente do interpretador do Python. Para fazer isso, execute os comandos abaixo, substituindo o APP pelo nome da sua aplicação ou biblioteca:

$ mkdir ~/.virtualenvs
$ cd ~/.virtualenvs
$ virtualenv --python=/usr/bin/python2.6 --no-site-packages APP-py2.6
$ virtualenv --python=/usr/bin/python2.5 --no-site-packages APP-py2.5
$ virtualenv --python=/usr/bin/python2.4 --no-site-packages APP-py2.4

Primeiramente criamos o diretório ~/.virtualenvs, que é por convenção o diretório padrão para armazenamento dos ambientes. Em seguida, criamos três ambientes para nossa aplicação APP. A flag --no-site-packages é opcional e indica que as bibliotecas instaladas no diretório site-packages do Python em questão não devem ser visíveis ao ambiente sendo criado.

Finalmente, não esqueça de instalar, em cada um dos ambientes, as dependências exigidas pela sua aplicação:

$ source ~/.virtualenvs/APP-py2.6/bin/activate
(APP-py2.6) $ easy_install biblioteca1 biblioteca2 ... bibliotecaN
(APP-py2.6) $ source ~/.virtualenvs/APP-py2.5/bin/activate
(APP-py2.5) $ easy_install biblioteca1 biblioteca2 ... bibliotecaN
(APP-py2.5) $ source ~/.virtualenvs/APP-py2.4/bin/activate
(APP-py2.4) $ easy_install biblioteca1 biblioteca2 ... bibliotecaN

Supondo que sua aplicação utilize o SetupTools para a configuração dos metadados do projeto (através do script setup.py), os comandos abaixo devem indicar se a aplicação funciona nos ambientes que criamos:

$ source ~/.virtualenvs/APP-py2.6/bin/activate
(APP-py2.6) $ python setup.py test
...
(APP-py2.6) $ source ~/.virtualenvs/APP-py2.5/bin/activate
(APP-py2.5) $ python setup.py test
...
(APP-py2.5) $ source ~/.virtualenvs/APP-py2.4/bin/activate
(APP-py2.4) $ python setup.py test
...

Automatizando!

Se tudo funcionou até aqui, estamos prontos para criar um script que nos permita rodar os testes de forma automática, nos diferentes ambientes.

Supondo que sua aplicação utilize o SetupTools para a configuração dos metadados do projeto, o exemplo abaixo resolve o problema:

# -*- coding: utf-8 -*-
 
# Environment info
config.project = 'APP'
config.virtualenv_dir = '~/.virtualenvs'
 
# Supported Python versions
config.versions = ('2.4', '2.5', '2.6',)
config.default_version = '2.6'
 
def setup(command, version=config.default_version):
    """Executes the given setup command with a virtual Python installation.
    """
    local('%s/%s-py%s/bin/python setup.py %s' % (config.virtualenv_dir, config.project, version, command))
 
def test():
    """Runs all tests in different Python versions.
    """
    for version in config.versions:
        setup('test', version)

Agora é só alegria:

$ fab test
Fabric v. 0.1.1.
Running test...
[localhost] run: ~/.virtualenvs/APP-py2.4/bin/python setup.py test
...
[localhost] run: ~/.virtualenvs/APP-py2.5/bin/python setup.py test
...
[localhost] run: ~/.virtualenvs/APP-py2.6/bin/python setup.py test
...

Devo lembrar que o script mostrado é só um exemplo. Você pode (e deve) modificá-lo para que este atenda às suas necessidades.

(Bônus!) Distribuindo sua aplicação para diferentes versões do Python

Com mais algumas linhas de código, podemos criar tasks que nos permitam gerar arquivos para distribuição da aplicação para diferentes versões do Python:

def dist_src():
    """Create source archive.
    """
    setup('sdist')
 
def dist_eggs():
    """Create binary archives, one for each Python version.
    """
    for version in config.versions:
        setup('bdist_egg', version)

(Bônus!) Automatizando geração de documentação e upload para o PyPI

Ainda acha pouco? Este outro exemplo de script vai além e mostra, numa aplicação real, como automatizar o registro e upload dos pacotes para o PyPI, atualizar site de documentação, entre outras coisas.

Na verdade, ninguém parecia se importar em automatizar tarefas “mecânicas” como o deployment, coisa que mudou de figura ao passo que metodologias ágeis — juntamente com técnicas como Integração Contínua — passaram a se tornar populares. Desde então, algum esforço vem sendo investido para criar ferramentas para automatização de muitas dessas tarefas.

Atualização: Trechos de código adaptados para as versões mais recentes do Fabric (22/06/2010).

Fabric: ferramenta Python para deployment

Apesar de já ter utilizado algumas dessas ferramentas no desenvolvimento de projetos em Java, plataforma na qual eu possuo uma experiência maior, eu ainda não conhecia nenhuma ferramenta em Python que me permitisse automatizar o deployment de uma aplicação.

Como eu estava começando a ficar de saco cheio de ter que atualizar os arquivos de uma aplicação Django via SCP, eu resolvi que já era hora de ir atrás de alguma ferramenta que me ajudasse a automatizar esse processo. Finalmente, depois de muita procura, eu encontrei Fabric, uma ferramenta mais ou menos parecida com um Capistrano “capado”.

A instalação do Fabric é bem simples para quem costuma usar o easy_install:

$ sudo easy_install Fabric

Basta executar esse comando para que os fontes da última versão do Fabric (0.0.9 no momento da publicação deste texto) sejam baixados e instalados.

Atenção: Quem utiliza máquinas Windows, provavelmente precisará do Cygwin, já que o Fabric assume o uso de ambientes Unix.

Fabric a 3.000 pés

Neste momento você já deve conseguir executar o comando fab no terminal. Se tudo correu bem até aqui, estamos prontos continuar.

Vamos começar criando o arquivo fabfile.py no diretório-raíz da aplicação. Coloque o seguinte conteúdo neste arquivo:

from fabric.api import *
 
env.project = 'project_name',
env.package = '$(project).zip',
 
# Remote servers
env.user  = 'usuario_ssh',
env.hosts = ['servidor1.com', 'servidor2.com'],
 
 
def deploy():
    "Deploys the application to the production servers."
    build()
 
def build():
    "Builds the application."
    prepare()
 
def prepare():
    "Prepares the build directory."
    clean()
 
def clean():
    "Removes the build directory."
    pass

Cada método definido no arquivo é equivalente a uma task do Capistrano. No início temos as variáveis env.* necessárias para o script. Destaque para a variável env.hosts, que indica os servidores nos quais os comandos remotos devem ser executados.

Ok, tente executar o comando fab -l no terminal, no mesmo diretório onde se encontra o arquivo fabfile.py. Se tudo correr bem, você receberá a seguinte saída:

$  fab -l
Available commands:
   build      Build the application.
   clean      Remove the build directory.
   deploy     Deploy the application to the production servers.
   help       Display Fabric usage help, or help for a given command.
   license    Display the Fabric distribution license text.
   list       Display a list of commands with descriptions.
   prepare    Prepare the build directory.
   set        Set a Fabric variable.
   shell      Start an interactive shell connection to the specified hosts.
   warranty   Display warranty information for the Fabric software.

Veja que as tasks que criamos estão disponíveis para serem executadas via linha de comando. Para executar as tasks clean e deploy, por exemplo, utilizaríamos o seguinte comando:

$  fab clean deploy

Simples, não é? Antes de vermos um exemplo de script completo, vamos conhecer os três principais métodos utilizados em scripts Fabric: local, run e put:

• local: Serve para executar comandos na máquina local. Ex: local('mkdir build');
• run: Igual ao local, mas executa os comandos nas máquinas remotas (indicadas na variável env.hosts);
• put: Envia um arquivo para as máquinas remotas. Ex: put('arquivo.zip', '/home/user/app.zip').

Finalmente, o script completo!

Antes de mostrar o script que eu venho utilizando para fazer o deployment de uma aplicação Django, veja como seus arquivos e diretórios estão organizados: (isso deve ajudar a entender melhor o script)

Estrutura do projeto

E, finalmente, o script:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
"""Build script.
"""
 
from fabric.api import *
 
 
env.project = 'destaqueweb'
 
# Build output directory
env.build_path = 'build'
env.package    = '%s.zip' % env.project
env.local_path = '%s/%s' % (env.build_path, env.package)
 
# Media
env.media_src   = 'media'
env.media_root  = 'public_html'
env.media_path  = '%s/%s/%s' % (env.media_root, env.project, env.media_src)
env.media_build = '%s/%s' % (env.build_path, env.media_path)
 
# Application code
env.app_root  = 'wsgi_apps'
env.app_path  = '%s/%s' % (env.app_root, env.project)
env.app_build = '%s/%s' % (env.build_path, env.app_path)
 
# Remote servers
env.hosts       = ['destaquenet.com']
env.destination = '/home/destaquenet'
 
 
def clean():
    """Removes the build directory.
    """
    local('rm -fR %s' % env.build_path)
 
def prepare():
    """Prepares the build directory.
    """
    clean()
    local('mkdir -p %s' % env.media_build)
    local('mkdir -p %s' % env.app_build)
 
def build():
    """Builds the application.
    """
    local('cp -R %s/* %s/%s' % (env.project, env.build_path, env.app_path))
    local('cp -R %s/* %s/%s' % (env.media_src, env.build_path, env.media_path))
    local('find %s -name *.pyc -delete' % env.build_path)
    local('find %s -path *upload* -delete' % env.build_path)
    local('find %s -path *fixtures* -delete' % env.build_path)
    local('cd %s;zip -r %s %s %s' % (env.build_path, env.package, env.media_root, env.app_root))
 
def reload_app():
    """Reloads the app.
    """
    run('touch %s/%s/%s/index.wsgi' % (env.destination, env.media_root, env.project))
    run('python %s/%s/manage.py ping_google /sitemap.xml' % (env.destination, env.app_path))
 
def deploy():
    """Deploys the application to the production server.
    """
    build()
    put(env.local_path, env.destination)
    run('cd %s; unzip -uo %s; rm %s' % (env.destination, env.package, env.package))
    reload_app()

Este código deve ser facilmente entendido por quem tem trabalha com uma certa facilidade no terminal.

Basicamente o que o código faz é organizar os arquivos da aplicação para que estes fiquem dispostos da mesma forma utilizada pelo servidor de produção, enviar os arquivos dentro de um pacote ZIP para os servidores e descompactá-los no local correto, além de executar um touch no script WSGI para que o Apache recarregue a aplicação.

Tudo pronto. Agora basta executar fab deploy no terminal para subir a aplicação para o(s) servidor(es) desejado(s).

Fabric e ambiente de homologação

Uma coisa que vem se tornando comum é o uso de diferentes ambientes onde uma aplicação costuma ser implantada (ex: ambiente de homologação). Se sua empresa costuma trabalhar dessa forma, o Fabric ainda pode te ajudar.

Por exemplo, vamos supor que sua empresa possua um servidor de produção e um servidor de homologação. Podemos, então, adequar o script para que ele possa trabalhar com ambos os ambientes:

# ...
env.user  = 'production',
env.hosts = ['app.com']
 
def staging():
    # deploy to staging servers
    env.user  = 'staging'
    env.hosts = ['staging.app.com']
 
# other tasks...

Fazendo as mudanças mostradas acima, para executar o deployment no ambiente de homologação basta rodar o comando fab staging deploy; o deployment em ambiente de produção continua disponível através do comando fab deploy.

Isso é possível pois podemos substituir o valor de uma variável (ou configurar novas variáveis) a qualquer momento. Então, quando executamos o comando fab staging deploy, o Fabric executa a task staging, substituindo o valor das variáveis env.user e env.hosts, fazendo com que os comandos contidos na task deploy sejam executados nos servidores de homologação em vez de nos servidores de produção.