Felizmente, Django é um dos poucos frameworks web que tornam este um problema simples de solucionar.

Como resolvemos este problema

Um jeito simples é criar um módulo settings.py separado para a versão “mobile”. Isso nos permite rodar dois sites diferentes reusando a mesma base de código. Além disso, cada versão pode ter seu próprio diretório de templates, configurações de URL, etc.

Vamos fazer isso. No diretório-raíz do projeto, crie um arquivo m_settings.py com o seguinte conteúdo:

# Arquivo: myproject/m_settings.py
 
"""Configurações para a versão "mobile" do website.
"""
 
# Carrega as configurações padrão
from settings import *
 
# Domínio "m.mydomain.com"
SITE_ID = 2
PREPEND_WWW = False
 
# Usado em outras partes do código para determinar qual versão está rodando
DEFAULT_VERSION = False
MOBILE_VERSION  = True
 
# URLs para a versão mobile
ROOT_URLCONF  = 'myproject.m_urls'
 
# Templates para a versão mobile
TEMPLATE_DIRS = (
    os.path.normpath(os.path.dirname(__file__) + '/template/mobile'),
)
 
# Outras configurações...

O fato de os dois sites compartilharem a mesma base de código não significa que eles devem ter as mesmas configurações de URL. Aliás, o normal é que versões próprias para dispositivos móveis sejam mais simples, com uma quantidade reduzida de mapeamentos de URLs.

Para definir as configurações de URL da versão mobile, crie um arquivo m_urls.py com o seguinte conteúdo:

# Arquivo: myproject/m_urls.py
 
"""Mapeamentos de URL para a versão "mobile".
"""
 
from django.conf import settings
from django.conf.urls.defaults import *
# from django.contrib import admin
 
# admin.autodiscover()
 
handler404 = 'website.views.error_404_handler'
handler500 = 'website.views.error_500_handler'
 
# URLs
urlpatterns = patterns('',
    # I18N
    (r'^i18n/', include('django.conf.urls.i18n')),
 
    # Apps internas
    (r'^contact/', include('contact.urls')),
 
    # (r'^admin/doc/', include('django.contrib.admindocs.urls')),
    # (r'^admin/', include(admin.site.urls)),
 
    # Outras configurações...
)

Perceba que, neste exemplo em particular, a app Admin não é acessível através da versão mobile. Isso apenas serve para mostrar que temos total liberdade para estruturar ambas as versões de diferentes formas, sem muitas dificuldades.

Desenvolvendo

Você certamente já sabe como rodar o servidor de desenvolvimento para a versão padrão. O que a maioria dos desenvolvedores desconhece, entretanto, é que é possível escolher qual a porta e/ou módulo settings.py deve ser usado pelo script, o que nos permite rodar um servidor para cada versão do nosso site:

# Terminal 1: versão padrão
$ python manage.py runserver 8000
 
# Terminal 2: versão mobile
$ python manage.py runserver --settings=m_settings 8001

Pronto, agora é só continuar com o desenvolvimento da forma que você já está acostumado.

Testando

Você provavelmente notou que temos duas configurações que podem ser usadas para determinar qual versão do site está rodando, DEFAULT_VERSION e MOBILE_VERSION.

Por isso, é só uma questão de checar tais configurações quando for necessário fazer coisas diferentes em cada uma das versões do site. Isso é particularmente útil quando você tem uma app usada em ambas as versões e quer criar testes para cada uma das versões:

# Arquivo: myproject/myapp/tests/__init__.py
 
"""Testes para MyApp.
"""
 
from django.conf import settings
 
if getattr(settings, 'DEFAULT_VERSION', False):
    # Testa a versão padrão
    from default_models_tests import *
    from default_navigation_tests import *
 
if getattr(settings, 'MOBILE_VERSION', False):
    # Testa a versão mobile
    from mobile_models_tests import *
    from mobile_navigation_tests import *

Você pode rodar os testes para cada versão de uma forma semelhante a que fizemos com o comando runserver:

# Versão padrão
$ python manage.py test [appname...]
 
# Versão mobile
$ python manage.py test --settings=m_settings [appname...]

Colocando em produção

Apesar do que você possa achar, esta é a parte fácil.

Uma vez que a forma recomendada de colocar Django em produção é com Apache e mod_wsgi, é possível que você já tenha um arquivo WSGI parecido com o seguinte:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Eggs de terceiros
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Tudo que precisamos fazer é configurar um outro sub-domínio WSGI no nosso servidor (ex: m.mywebsite.com) que referencia o seguinte arquivo de configurações WSGI:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Eggs de terceiros
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.m_settings' # Esta linha
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

A única diferença entre esses dois arquivos WSGI é que cada um aponta para um módulo settings.py diferente. E não, você não precisa ter uma cópia do site para cada versão, afinal estamos usando a mesma base de código para ambas as versões, lembra?

Minimizando o tráfego

Por incrível que pareça, nem todo mundo dispõe de conexões ultra-rápidas. Por isso, é muito importante que você mantenha seus sites tão leves quanto possível.

Existem vários projetos open source que podem ajudar nessa parte. Um deles é o django-compress, uma app Django que fornece um sistema automatizado para compressão de arquivos CSS e JavaScript.

Aliás, não importa se seus websites são para dispositivos móveis ou não; você deve sempre tentar minimizar o tráfego.

O que falta?

Ainda temos um pequeno problema: quando alguém visita a versão padrão do site através de um dispositivo móvel, ou vice-versa, eles não são redirecionados para a versão apropriada. Mas isso é assunto para um próximo artigo!

Fortunately, Django is one of the few web frameworks that makes this an easy problem to solve.

How we solved it

A simple way is to create a separate settings module for the mobile version. Doing this, we’re able to run two different webapps while reusing the existing codebase. Also, each version can have its own template directory, URL root configuration, etc.

Let’s do this. In the project root directory, create a file m_settings.py with the following content:

# File: myproject/m_settings.py
 
"""Django settings for the mobile-specific website.
"""
 
# Load the default settings
from settings import *
 
# Domain "m.mydomain.com"
SITE_ID = 2
PREPEND_WWW = False
 
# Used elsewhere to determine which version is running
DEFAULT_VERSION = False
MOBILE_VERSION  = True
 
# URLs for the mobile version
ROOT_URLCONF  = 'myproject.m_urls'
 
# Templates for the mobile version
TEMPLATE_DIRS = (
    os.path.normpath(os.path.dirname(__file__) + '/template/mobile'),
)
 
# Other settings...

These two webapps share the same codebase, but that doesn’t mean they have to use the same URL root configuration. In fact, websites suitable for mobile devices are usually simpler, with fewer URL mappings.

To define separate URL root configuration for the mobile version, create a file m_urls.py with the following content:

# File: myproject/m_urls.py
 
"""Mobile-specific URL definition.
"""
 
from django.conf import settings
from django.conf.urls.defaults import *
# from django.contrib import admin
 
# admin.autodiscover()
 
# Error page handlers
handler404 = 'website.views.error_404_handler'
handler500 = 'website.views.error_500_handler'
 
# Root URL patterns
urlpatterns = patterns('',
    # I18N
    (r'^i18n/', include('django.conf.urls.i18n')),
 
    # Internal apps
    (r'^contact/', include('contact.urls')),
 
    # (r'^admin/doc/', include('django.contrib.admindocs.urls')),
    # (r'^admin/', include(admin.site.urls)),
 
    # Other settings...
)

Note that, in this particular example, the Admin app isn’t accessible from mobile version. This just shows that we can structure each webapp differently without too much trouble.

Developing

You already know how to run the development server for the default version. Most people don’t know, however, that it’s possible to choose a different port number and settings module, which allows us to launch one development server for each webapp version:

# Terminal window 1: default version
$ python manage.py runserver 8000
 
# Terminal window 2: mobile version
$ python manage.py runserver --settings=m_settings 8001

Just develop your stuff and see the results in both versions right away. Easy peasy.

Testing

You probably noticed that we have two settings that can be used to identify what webapp version is being run, DEFAULT_VERSION and MOBILE_VERSION.

So it’s just a matter of checking those settings when you need to do different things in each webapp version. This is particularly useful when you use an app in both versions and want to create separate tests for each version:

# File: myproject/myapp/tests/__init__.py
 
"""Unit tests module for MyApp.
"""
 
from django.conf import settings
 
if getattr(settings, 'DEFAULT_VERSION', False):
    # Tests the default version
    from default_models_tests import *
    from default_navigation_tests import *
 
if getattr(settings, 'MOBILE_VERSION', False):
    # Tests the mobile version
    from mobile_models_tests import *
    from mobile_navigation_tests import *

We can run the tests for each version in a similar way we did before with the runserver command:

# Default version
$ python manage.py test [appname...]
 
# Mobile version
$ python manage.py test --settings=m_settings [appname...]

Deploying

Despite what you may think, this is the easy part.

Since deploying Django with Apache and mod_wsgi is the recommended way to get Django into production, it’s likely that you already have a WSGI file like this:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Third-party eggs
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

All we need to do is configure another WSGI-enabled subdomain on our server, e.g. m.mywebsite.com, that refers to another WSGI file like this one:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Third-party eggs
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.m_settings' # This line
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

The only difference between these two WSGI files is that each one points to a different settings module. And no, you don’t need to have a separate copy for each version. We are using the same codebase for both versions, remember?

Minimizing the traffic

Amazingly, not everyone has access ultra-fast internet connections on their devices, so it’s very important to keep your sites as lightweight as possible.

There are several open source projects that try to address this problem. One of them is django-compress, a Django app that provides an automated system for compressing CSS and JavaScript files.

In fact, doesn’t matter if your websites target mobile devices or not; you should always try to minimize the amount of traffic.

What’s left?

There’s one small problem though: when someone visit the regular website from a mobile device, or vice-versa, they are not redirected to the appropriate version. But this is a topic for another article!

Sim, eu disse que o Django 1.2 traz incluso um framework de “mensagens”. Bom, né? Django realmente precisava vir acompanhado de uma app para resolver essa questão. Isso não significa, no entanto, que Django-Flash será descontinuado ou abandonado.

Então, se você usa Django-Flash em seus projetos, não se preocupe! Nada mudará. Django-Flash já é compatível com Django 1.2, e nós ocontinuaremos a mantê-lo por algumas razões.

A primeira delas é que nos importamos com quem usa nosso software. Nós não quebraremos seus projetos se você decidir fazer o upgrade para uma versão mais recente do Django – ou se decidir continuar usando uma versão anterior.

A outra é a liberdade de escolha. Você sabe, não existe uma única forma de se resolver todos os problemas. As pessoas devem ser livres para escolher a ferramenta apropriada a uma determinada situação.

Por exemplo, baseado nas minhas primeiras impressões, existem algumas coisas que eu realmente não gostei no novo framework de “mensagens”:

1. Ele é verboso mesmo nos casos de uso mais simples
2. Ele associa mensagens a números de prioridade, encorajando os usuários a usá-lo como um framework de logging/debugging. Quero dizer, um framework de “mensagens” não é um framework de logging/debugging, certo?

Mas essa é apenas a minha opinião. Talvez seja isso que faz do open source algo tão formidável!

Yes, I said Django 1.2 comes with built-in user “messages” framework. Great, isn’t it? Django really needed a built-in contrib app to solve this problem. This doesn’t mean, however, that Django-Flash will be discontinued or abandoned.

So, if you use Django-Flash in your projects, don’t worry! Nothing will change. Django-Flash is already compatible with Django 1.2, and we’ll keep improving Django-Flash for a number of reasons.

First of all, we care about the people who use our software. We won’t break your stuff if you decide to upgrade to a newer version of Django – or if you decide to keep using the previous version.

Also, freedom of choice is a good thing. You know, there’s not only one true way to solve every problem. People should be free to choose whatever tool they think is right in a given situation.

For example, based on my first impressions, there are a couple of things I didn’t like at all about the new user “messages” framework:

1. It’s verbose even for the simple cases
2. It ties messages to priority numbers, encouraging you to use it like a logging/debugging framework. I mean, a user “messages” framework is not a logging/debugging framework, right?

But that’s just my opinion. I guess this is what makes open source so great!

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.

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.