De um tempo para cá, eu fui contactado por alguns desses usuários perguntando sobre a possibilidade de ter o nosso projeto incluído na distribuição do Django, na forma de uma Contrib app. Eu achei a idéia excelente, pois eu penso que um framework como o Django deveria se preocupar em resolver um problema tão recorrente quanto este que o Django-flash se propõe a resolver.

Se você utiliza Django-flash em seus projetos, não deixe de acompanhar essa discussão. Se possível, nos dê sua opinião sobre o que poderia ser feito para melhorar ainda mais o projeto e, assim, facilitar sua inclusão no Django.

O poder do Python

Quem não está acostumado a trabalhar com Django pode estranhar o fato deste utilizar um script Python para fazer a configuração do projeto: o famoso settings.py. E essa estranheza é justificada, afinal muitos desenvolvedores — principalmente os que vêm de outras linguagens — estão acostumados a trabalhar com ferramentas onde tal tarefa é feita com arquivos XML ou coisa assim.

O fato é que utilizar um script Python para tal é uma excelente idéia, pois você deixa de depender de algum tipo de estrutura estática (e muitas vezes inconveniente) para algo mais flexível e poderoso, que, no caso, é a própria linguagem de programação. Isso faz uma grande diferença em situações onde tal flexibilidade é necessária.

Quer exemplos?

Ambientes de desenvolvimento/produção

Eis como fizemos aqui. Primeiramente, defina a variável de ambiente WORKSPACE. No Linux, isso pode ser feito através do arquivo ~/.bashrc:

export WORKSPACE=1

A idéia é possibilitar a criação de perfis de configuração, cada qual correspondente a um ambiente de execução. A existência ou não da variável de ambiente é o que define o ambiente no qual a aplicação roda.

Continuando com o exemplo, no diretório raíz do seu projeto Django, crie o módulo environment.py, com o seguinte conteúdo:

import os
 
def production_mode():
    return not development_mode()
 
def development_mode():
    return 'WORKSPACE' in os.environ

Finalmente, modifique o módulo settings.py para que este utilize tais métodos onde for necessário definir configurações diferentes para ambientes de execução diferentes:

from environment import production_mode
 
# Configurações padrão
PREPEND_WWW = False
DEBUG = True
 
# Configurações para ambiente de produção
if production_mode():
    PREPEND_WWW = True
    DEBUG = False
 
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.middleware.doc.XViewMiddleware',
    'pages.middleware.PageFallbackMiddleware',
    'django.contrib.redirects.middleware.RedirectFallbackMiddleware',
)
 
# Habilitando caching em modo de produção
if production_mode():
    MIDDLEWARE_CLASSES += (
        'django.middleware.cache.UpdateCacheMiddleware',
        'django.middleware.cache.FetchFromCacheMiddleware',
    )

Não tenha medo de utilizar os recursos do Python onde eles se fizerem necessários, apenas tomando cuidado para não exagerar e acabar criando acidentalmente um Algoritmo Genético para configurar seu projeto!

Informações secretas (IPs, usernames, passwords, etc)

Praticamente não há quem ignore a importância de um bom sistema de controle de revisões (Subversion, Git, etc). O problema é que, muitas vezes, não tomamos o devido cuidado com o que colocamos dentro dos nossos repositórios. Sempre que possível, informações secretas — como endereços de IP, usernames e passwords — devem ser mantidas fora dos repositórios.

Em um projeto Django, as informações de acesso a servidores de e-mail e bancos de dados devem estar disponíveis através do módulo  settings.py. Felizmente, existe um jeito simples de manter essas informações separadas das outras configurações.

Primeiramente, abra o arquivo settings.py do seu projeto e remova todas as senhas e outras informações que você considere secretas. Em seguida, cole o seguinte trecho de código no final do arquivo:

try:
    from private import *
except ImportError:
    pass

Feito isso, crie o módulo private.py no diretório raíz do seu projeto Django. Coloque nele as configurações que você removeu do settings.py no passo anterior. Exemplo:

from environment import production_mode
 
SECRET_KEY = 'secret_key_do_seu_projeto'
 
EMAIL_HOST = 'localhost'
EMAIL_HOST_PASSWORD = 'senha_email_local'
 
DATABASE_HOST = 'localhost'
DATABASE_USER = 'username_db_local'
DATABASE_PASSWORD = 'senha_db_local'
 
if production_mode():
    EMAIL_HOST = 'ip_email_producao'
    EMAIL_HOST_PASSWORD = 'senha_email_producao'
 
    DATABASE_HOST = 'ip_db_producao'
    DATABSE_USER = 'username_db_producao'
    DATABASE_PASSWORD = 'senha_db_producao'

Certifique-se de adicionar o arquivo private.py no ignore (.cvsignore para CVS, .gitignore para Git, etc) correspondente ao sistema de controle de revisões sendo utilizado. Faça o commit e pronto.

Para finalizar, se o seu repositório já contém uma versão “insegura” do módulo settings.py, mude as senhas dos seus servidores.

E você, o que recomenda?

Tem alguma dica útil para compartilhar conosco? Nós adoraríamos ouvir o que você tem a dizer!

Francamente, eu achava que não iria dar certo, talvez por culpa de uma screencast horrível que eu acabara de ver, não sei. Mas o fato é que, contrariando minhas expectativas, o Django vem se mostrando uma ferramenta muito interessante. Se você ainda não conhece, veja você mesmo o que Django (e Python, claro!) podem fazer por você.

Mas voltando ao assunto, a primeira vez que precisei usar algo que o Django não oferecia por padrão foi quando tentei utilizar um recurso muito querido  pelo pessoal do Rails: as mensagens flash.¹ Por esse motivo, eu comecei um projeto open source chamado django-flash, cujo objetivo é (pasmem!) levar as mensagens flash do Rails ao Django.

O projeto vem sido desenvolvido no meu tempo livre e hoje chega à versão 1.4.1, oferecendo todos os recursos então presentes no seu irmão mais velho. Acredito que o projeto chegou num grau interessante de maturidade: API estável, documentação abundante, código extremamente bem comentado e apoiado por testes (unitários e de integração).

Portanto, se você precisa de algo semelhante às mensagens flash do Rails em seu projeto Django, não deixe de conferir o site do projeto. Conto com a ajuda de vocês para tornar este projeto cada vez melhor!

Um bom fim de semana a todos!

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.

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:

daniel ~ $ 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:

set(
    project = 'project_name',
 
    package     = '$(project).zip',
 
    # Remote servers
    fab_user    = 'usuario_ssh',
    fab_hosts   = ['servidor1.com', 'servidor2.com'],
)
 
 
def deploy():
    "Deploy the application to the production servers."
    build()
 
def build():
    "Build the application."
    prepare()
 
def prepare():
    "Prepare the build directory."
    clean()
 
def clean():
    "Remove the build directory."
    pass

Cada método definido no arquivo é equivalente a uma task do Capistrano. No início temos o método set que nos permite configurar as variáveis necessárias para o script. Veja que, neste método set, indicamos na variável fab_hosts os servidores nos quais os comandos remotos devem ser executados.

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

daniel ~  $  fab
   Fabric v. 0.0.9, Copyright (C) 2008 Christian Vest Hansen.
   Fabric comes with ABSOLUTELY NO WARRANTY; for details type `fab warranty'.
   This is free software, and you are welcome to redistribute it
   under certain conditions; type `fab license' for details.

No commands given.
Available commands are:
   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.
Done.

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:

daniel ~  $  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 fab_hosts);
• put: Envia um arquivo para as máquinas remotas. Ex: put('arquivo.zip', '/home/user/app.zip').

Antes de prosseguirmos, vamos voltar a olhar a chamada ao método set, no início do código. Nele, eu usei um recurso do Fabric conhecido como lazy evaluation. No caso, temos a variável package que recebe o valor '$(project).zip'. Esse $(project) indica que queremos que o valor da variável project substitua o placeholder. Isso permite que variáveis sejam interpoladas umas dentro das outras.

Por exemplo, se dentro de uma task executarmos o comando local('rm $(package)'), isso significa que o Fabric irá parsear a string, transformando-a em 'rm project_name' para só então executar tal comando na máquina local.

Como veremos a seguir, eu utilizei este recurso exaustivamente no meu script. Em caso de dúvidas, consulte a documentação do Fabric.

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:

set(
    project = 'destaqueweb',
 
    # Build output directory
    build_path  = 'build',
    package     = '$(project).zip',
 
    # Media
    media_src   = 'media',
    media_root  = 'public_html',
    media_path  = '$(media_root)/$(project)/$(media_src)',
    media_build = '$(build_path)/$(media_path)',
 
    # Application code
    app_root  = 'wsgi_apps',
    app_path  = '$(app_root)/$(project)',
    app_build = '$(build_path)/$(app_path)',
 
    # Remote servers
    fab_user    = 'destaquenet',
    fab_hosts   = ['destaquenet.com'],
 
    destination = '/home/destaquenet',
    touch       = '$(destination)/$(media_root)/$(project)/index.wsgi',
)
 
def deploy():
    "Deploy the application to the production server."
    build()
 
    # Upload the zip file
    put('$(build_path)/$(package)', '$(destination)/$(package)')
 
    # Extract the zip file
    run('cd $(destination); unzip -uo $(package); rm $(package)')
 
    # Reload the application
    run('touch $(touch)')
 
def build():
    "Build the application."
    prepare()
 
    # Copy application files to the build directory
    local('cp -R $(project)/* $(build_path)/$(app_path)')
    local('cp -R $(media_src)/* $(build_path)/$(media_path)')
 
    # Remove unecessary files
    local('find $(build_path) -name *.pyc -delete')
    local('find $(build_path) -path *upload* -delete')
    local('find $(build_path) -path *fixtures* -delete')
 
    # Create the zip file
    local('cd $(build_path);zip -r $(package) $(media_root) $(app_root)')
 
def prepare():
    "Prepare the build directory."
    clean()
 
    local('mkdir -p $(media_build)')
    local('mkdir -p $(app_build)')
 
def clean():
    "Remove the build directory."
    local('rm -fR $(build_path)')

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:

set(
    # ...
    fab_user = 'production',
    fab_hosts = ['app.com']
)
 
def staging():
    # deploy to staging servers
    set(fab_user = 'staging', fab_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, através do método set. Então, quando executamos o comando fab staging deploy, o Fabric executa a task staging, substituindo o valor das variáveis fab_user e fab_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.