Prerequisites¶

1. Clean Debian Lenny, Debian Squeeze, Ubuntu 10.04 or 10.10 server/VPS with root or sudo-enabled user ssh access;
2. working ssh key authentication;

Prepare the project¶

1. Install django-fab-deploy its requirements:

   pip install django-fab-deploy
   pip install jinja2
   pip install "fabric >= 1.4"

2. Create fabfile.py at project root. It should provide one or more function putting server details into Fabric environment. Otherwise it’s just a standart Fabric’s fabfile (e.g. project-specific scripts can also be put here). Example:

   # my_project/fabfile.py
   from fab_deploy import *
   
   def my_site():
       env.hosts = ['my_site@example.com']
       env.conf = dict(
           DB_USER = 'my_site',
           DB_PASSWORD = 'password',
   
           # uncomment this line if the project is not stored in VCS
           # default value is 'hg', 'git' is also supported
           # VCS = 'none',
       )
       update_env()
   
   my_site()
   

   There is a simpler syntax for the code above:

   from fab_deploy import *
   
   @define_host('my_site@example.com')
   def my_site():
       return dict(
           DB_USER = 'my_site',
           DB_PASSWORD = 'password',
       )
   
   my_site()
   

   In order to make things simple set the username in env.hosts string to your project name. It should be a valid python identifier. Don’t worry if there is no such user on server, django-fab-deploy can create linux user and setup ssh access for you, and it is preferrable to have linux user per project if possible.

   Note

   There are some defaults, e.g. DB_NAME equals to INSTANCE_NAME, and INSTANCE_NAME equals to username obtained from env.hosts.

   Read fabfile.py API for more details.

3. Copy config_templates folder from django-fab-deploy to your project root, manually or by running the following command from the project root:

   django-fab-deploy config_templates

   Read the configs and adjust them if it is needed. Basic configs are usually a good starting point and should work as-is.

   Note

   {{ variables }} can be used in config templates (engine is jinja2). They will be replaced with values from env.conf on server.

   If you change web server config file or env.conf variables after initial deployment, apply the changes in web server configs by running

   fab setup_web_server

4. Create config.server.py at project root. This file will become config.py on server. Example:

   # my_project/config.server.py
   # config file for environment-specific settings
   
   DEBUG = False
   DATABASES = {
       'default': {
           'ENGINE': 'django.db.backends.mysql',
           'NAME': '{{ DB_NAME }}',
           'USER': '{{ DB_USER }}',
           'PASSWORD': '{{ DB_PASSWORD }}',
           'HOST': '',
           'PORT': '',
           'OPTIONS': {
               "init_command": "SET storage_engine=INNODB"
           },
       }
   }
   

   Then create config.py for local development. Import config in project’s settings.py:

   # Django settings for my_project project.
   # ...
   from config import *
   # ...
   

   config.py trick is also known as local_settings.py (make sure config.py is ignored in your VCS if one is used).

   Note

   {{ variables }} can be used in config.server.py. They will be replaced with values from env.conf on server.

   If you change config.server.py or env.conf variables after initial deployment, apply the changes to config.server.py by running

   fab update_django_config

5. Create reqs folder at project root. This folder should contain text files with pip requirements.

   You can get basic/example reqs folder by running

   django-fab-deploy example_reqs

   One file is special: reqs/all.txt. This is the main requirements file. List all project requirements here one-by-one or (preferrable) by including other requirement files using “-r” syntax.

   There is also

   django-fab-deploy generate_reqs

   command. It creates reqs folder with all.txt file containing a list of currently installed packages (obtained from pip freeze).

The project should look like that after finishing steps 1-5:

my_project
    ...
    config_templates <- this folder should be copied from django-fab-deploy
        apache.config
        django_wsgi.py
        hgrc
        nginx.config

    reqs             <- a folder with project's pip requirement files
        all.txt      <- main requirements file, list all requirements in this file
        active.txt   <- put recently modified requirements here
        ...          <- you can provide extra files and include them with '-r' syntax in e.g. all.txt

    config.py        <- this file should be included in settings.py and ignored in .hgignore
    config.server.py <- this is a production django config template
    fabfile.py       <- your project's Fabric deployment script
    settings.py
    manage.py

The project is now ready to be deployed.

Prepare the server¶

1. If the server doesn’t have sudo installed (e.g. clean Lenny or Squeezy) then install sudo on server:

   fab install_sudo

   Note

   Fabric commands should be executed in shell from the project root on local machine (not from the python console, not on server shell).

2. If there is no linux account for user specified in env.hosts then add a new linux server user, manually or using

   fab create_linux_account:"/home/kmike/.ssh/id_rsa.pub"

   You’ll need the ssh public key. create_linux_account creates a new linux user and uploads provided ssh key. Test that ssh login is working:

   ssh my_site@example.com

   SSH keys for other developers can be added at any time:

   fab ssh_add_key:"/home/kmike/coworker-keys/ivan.id_dsa.pub"

3. Setup the database. django-fab-deploy can install mysql and create empty DB for the project:

   fab mysql_install
   fab mysql_create_db

   mysql_install does nothing if mysql is already installed on server. Otherwise it installs mysql-server package and set root password to env.conf.DB_ROOT_PASSWORD. If this option is empty, mysql_install will ask for a password.

   mysql_create_db creates a new empty database named env.conf.DB_NAME (it equals to env.conf.INSTANCE_NAME by default, which equals to the user from env.hosts by default). mysql_create_db will ask for a mysql root password if DB_USER is not ‘root’.

   Note

   If the DB enging is not mysql then DB should be created manually now.

4. If you feel brave you can now run fab full_deploy from the project root and get a working django site.

   This command:

   • installs necessary system and python packages;
   • configures apache and ngnix;
   • creates virtualenv;
   • uploads project to the server;
   • runs python manage.py syncdb and python manage.py migrate commands on server.

   Project sources will be available under ~/src/<INSTANCE_NAME>, virtualenv will be placed in ~/envs/<INSTANCE_NAME>.

   Warning

   django-fab-deploy disables ‘default’ apache and nginx sites and takes over ‘ports.conf’ so apache is no longer listening to 80 port.

   If there are other sites on server (not managed by django-fab-deploy) they may become unaccessible due to these changes.

Working with the server¶

django-fab-deploy provides additional commands that should be useful for updating the server:

1. Source changes are deployed with fab_deploy.deploy.push() command:

   fab push

   Another example (deploy changes on ‘prod’ server, update pip requirements and perform migrations in one step:

   fab prod push:pip_update,migrate

2. Update web server configuration:

   fab setup_web_server

3. Update django configuration (config.server.py):

   fab update_django_config

4. Requirements are updated with fab_deploy.virtualenv.pip_update() command. Update requirements listed in reqs/active.txt:

   fab pip_update

   Update requirements listed in reqs/my_apps.txt:

   fab pip_update:my_apps

5. Remotely change branch or revision (assuming env.conf.VCS is not ‘none’):

   fab up:my_branch

Full list of commands can be found here.

Customization guide is also worth reading.

Custom deployment scripts¶

django-fab-deploy is intended to be a library, not a framework. So the preferred way for customizing standard command is to just wrap it or to create a new command by combining existing commands:

# fabfile.py
from fab_deploy import *
from fab_deploy.utils import run_as_sudo
import fab_deploy.deploy

@run_as_sudo
def install_java():
    run('aptitude update')
    run('aptitude install -y default-jre')

def full_deploy():
    install_java()
    fab_deploy.deploy.full_deploy()

fab_deploy.deploy.push() accepts callable ‘before_restart’ keyword argument. This callable will be executed after code uploading but before the web server reloads the code.

# fabfile.py
from fab_deploy import *
import fab_deploy.deploy

@inside_src
def rebuild_docs():
    with cd('docs'):
        run ('rm -rf ./_build')
        run('make html > /dev/null')

def push(*args):

    # run local tests before pushing
    local('./runtests.sh')

    # rebuild static files before restarting the web server
    def before_restart():
        manage('collectstatic --noinput')
        manage('assets rebuild')

    # execute default push command
    fab_deploy.deploy.push(*args, before_restart=before_restart)

    # rebuild developer documentation after pushing
    rebuild_docs()

Custom project layouts¶

User Guide describes standard project layout:

my_project
    ...
    config_templates <- this folder should be copied from django-fab-deploy
        ...

    reqs             <- a folder with project's pip requirement files
        all.txt      <- main requirements file, list all requirements in this file
        active.txt   <- put recently modified requirements here
        ...          <- you can provide extra files and include them with '-r' syntax in e.g. all.txt

    config.py        <- this file should be included in settings.py and ignored in .hgignore
    config.server.py <- this is a production django config template
    fabfile.py       <- your project's Fabric deployment script
    settings.py
    manage.py

django-fab-deploy does not enforce this layout. Requirements handling, config templates placement, local settings file names and project source folder can be customized using these options:

• env.conf.PROJECT_PATH
• env.conf.LOCAL_CONFIG
• env.conf.REMOTE_CONFIG_TEMPLATE
• env.conf.CONFIG_TEMPLATES_PATHS
• env.conf.PIP_REQUIREMENTS_PATH
• env.conf.PIP_REQUIREMENTS
• env.conf.PIP_REQUIREMENTS_ACTIVE

my_project
    hosting                 <- a folder with server configs
        staging             <- custom configs for 'staging' server
            apache.config   <- custom apache config for staging server

        production          <- custom configs for 'production' server
            apache.config
            nginx.config

        apache.config       <- default configs
        django_wsgi.py
        nginx.config

    src                     <- django project source files
        apps
            ...

        local_settings.py   <- local settings
        stage_settings.py   <- local settings for staging server
        prod_settings.py    <- local settings for production server

        settings.py
        manage.py

    requirements.txt        <- single file with all pip requirements
    fabfile.py              <- project's Fabric deployment script

from fab_deploy.utils import define_host

# Common layout options.
# They are separated in this example in order to stay DRY.
COMMON_OPTIONS = dict(
    PROJECT_PATH = 'src',
    LOCAL_CONFIG = 'local_settings.py',
    PIP_REQUIREMENTS = 'requirements.txt',
    PIP_REQUIREMENTS_ACTIVE = 'requirements.txt',
    PIP_REQUIREMENTS_PATH = '',
)

@define_host('user@staging.example.com', COMMON_OPTIONS)
def staging():
    return dict(
        REMOTE_CONFIG_TEMPLATE = 'stage_settings.py',
        CONFIG_TEMPLATES_PATHS = ['hosting/staging', 'hosting'],
    )

@define_host('user@example.com', COMMON_OPTIONS)
def production():
    return dict(
        REMOTE_CONFIG_TEMPLATE = 'prod_settings.py',
        CONFIG_TEMPLATES_PATHS = ['hosting/production', 'hosting'],
    )

my_project
    my_project
        config_templates
            ...
        reqs
            ...
        ...
        config.py
        config.server.py
        settings.py

    fabfile.py
    manage.py
    ...

from fab_deploy.utils import define_host

@define_host('user@example.com')
def staging():
    return dict(
        CONFIG_TEMPLATES_PATHS=['my_project/config_templates'],
        LOCAL_CONFIG = 'my_project/config.py',
        REMOTE_CONFIG_TEMPLATE = 'my_project/config.server.py',
        PIP_REQUIREMENTS_PATH = 'my_project/reqs/',
    )

Overview¶

• Write a function populating env.hosts and env.conf for each server configuration.

• Call update_env() at the end of each function.

• It is possible to reduce boilerplate by using define_host decorator:

  from fab_deploy import *
  
  @define_host('my_site@example.com')
  def my_site():
      return {
          # ...
      }
  

• In order to specify configuration the fab commands should use, run the configuring function as a first fab command:

  fab my_site mysql_install

• In order to make configuration default call the configuring function at the end of fabfile.py:

  from fab_deploy import *
  
  def my_site():
      env.hosts = ['my_site@example.com']
      env.conf = {
          # ...
      }
      # ...
      update_env()
  
  my_site()
  

  This way it’ll be possible to run fab commands omitting the config name:

  fab mysql_install

Configuring¶

fab_deploy.utils.update_env()[source]¶

Updates env.conf configuration with some defaults and converts it to state._AttributeDict (that’s a dictionary subclass enabling attribute lookup/assignment of keys/values).

Call update_env() at the end of each server-configuring function.

from fab_deploy import *

def my_site():
    env.hosts = ['my_site@example.com']
    env.conf = dict(
        DB_USER = 'my_site',
        DB_PASSWORD = 'password',
    )
    update_env()

env.hosts¶

A list with host string. Example:

env.hosts = ['user@example.com']

See fabric docs for explanation.

User obtained from this string will be used for ssh logins and as a default value for env.conf.INSTANCE_NAME.

Note

multiple hosts are supported via multiple config functions, not via this option.

Warning

Due to bug in Fabric please don’t use env.user and env.port. Put the username and non-standard ssh port directly into host string.

env.conf¶

django-fab-deploy server configuration.

All env.conf keys are available in config templates as jinja2 template variables.

env.conf.INSTANCE_NAME¶

Project instance name. It equals to username obtained from env.hosts by default. INSTANCE_NAME should be unique for server. If there are several sites running as one linux user, set different INSTANCE_NAMEs for them.

env.conf.SERVER_NAME¶

Site url for webserver configs. It equals to the first host from env.hosts by default.

env.conf.DB_NAME¶

Database name. It equals to env.conf.INSTANCE_NAME by default.

env.conf.DB_USER¶

Database user. It equals to ‘root’ by default.

env.conf.DB_PASSWORD¶

Database password.

env.conf.DB_ROOT_PASSWORD¶

Database password for a ‘root’ user. django-fab-deploy will ask for mysql root password when necessary if this option is not set.

env.conf.SUDO_USER¶

User with sudo privileges. It is ‘root’ by default. Use create_sudo_linux_account in order to create non-root sudoer.

env.conf.PROCESSES¶

The number of mod_wsgi daemon processes. It is a good idea to set it to number of processor cores + 1 for maximum performance or to 1 for minimal memory consumption. Default is 1.

env.conf.THREADS¶

The number of mod_wsgi threads per daemon process. Default is 15.

Note

Set env.conf.THREADS to 1 and env.conf.PROCESSES to a bigger number if your software is not thread-safe (it will consume more memory though).

env.conf.OS¶

A string with server operating system name. Set it to the correct value if autodetection fails for some reason. Supported operating systems:

• lenny
• squeeze
• maverick

env.conf.VCS¶

The name of VCS the project is stored in. Supported values:

• hg
• git
• none

Default is ‘hg’.

VCS is used for making project clones and for pushing code updates. ‘none’ VCS is able to upload tar.gz file with project sources on server via ssh and then extract it. Please prefer ‘hg’ or ‘git’ over ‘none’ if possible.

One can write custom VCS module and set env.conf.VCS to its import path:

env.conf = dict(
    # ...
    VCS = 'my_utils.my_vcs',
)

VCS module should provide ‘init’, ‘up’, ‘push’ and ‘configure’ functions. Look at fab_deploy.vcs.hg or fab_deploy.vcs.none for examples.

env.conf.HG_BRANCH¶

Named hg branch that should be active on server. Default is “default”. This option can be used to have 1 repo with several named branches and run different servers from different branches.

env.conf.GIT_BRANCH¶

Git branch that should be active on server. Default is “master”. This option can be used to run different servers from different git branches.

env.conf.PROJECT_PATH¶

Path to django project (relative to repo root). Default is ‘’. This should be set to a folder where project’s manage.py reside.

env.conf.LOCAL_CONFIG¶

Local django config file name. Default is ‘config.py’. Common values include ‘local_settings.py’ and ‘settings_local.py’. This file should be placed inside env.conf.PROJECT_PATH, imported from settings.py and excluded from version control.

Note

Default value is not set to one of widely-used file names by default (e.g. ‘local_settings.py’) in order to prevent potential data loss during converting existing project to django-fab-deploy: this file is overwritten on server during deployment process; it is usually excluded from VCS and contains important information.

env.conf.REMOTE_CONFIG_TEMPLATE¶

The name of file with remote config template. Default is ‘config.server.py’. This file should be placed inside env.conf.PROJECT_PATH. It will become env.conf.LOCAL_CONFIG on server.

env.conf.CONFIG_TEMPLATES_PATHS¶

An iterable with paths to web server and other config templates. Default is ['config_templates'].

env.conf.PIP_REQUIREMENTS_PATH¶

Default is ‘reqs’. This path is relative to repo root.

env.conf.PIP_REQUIREMENTS¶

The name of main requirements file. Requirements from it are installed during deployment. Default is ‘all.txt’.

env.conf.PIP_REQUIREMENTS_ACTIVE¶

The name of pip requirements file with commonly updated requirements. Requirements from this file are updated by fab_deploy.virtualenv.pip_install() and fab_deploy.virtualenv.pip_update() commands when they are executed without arguments.

fab push:pip_update command also updates only requirements listed here.

Default is ‘all.txt’.

env.conf.APACHE_PORT¶

The port used by apache backend. It is managed automatically and shouldn’t be set manually.

You can put any other variables into the env.conf. They will be accessible in config templates as template context variables.

Writing custom commands¶

While django-fab-deploy commands are just Fabric commands, there are some helpers to make writing them easier.

fab_deploy.utils.inside_project(func)[source]¶

Decorator. Use it to perform actions inside remote project dir (that’s a folder where manage.py resides) with virtualenv activated:

from fabric.api import *
from fab_deploy.utils import inside_project

@inside_project
def cleanup():
    # the current dir is a project source dir and
    # virtualenv is activated
    run('python manage.py cleanup')

fab_deploy.utils.inside_src(func)[source]¶

Decorator. Use it to perform actions inside remote source dir (repository root) with virtualenv activated.

fab_deploy.utils.run_as_sudo(func)[source]¶

Decorator. By default all commands are executed as user without sudo access for security reasons. Use this decorator to run fabric command as user with sudo access (env.conf.SUDO_USER):

from fabric.api import run
from fab_deploy import utils

@utils.run_as_sudo
def aptitude_update():
    run('aptitude update')

fab_deploy.utils.define_host(host_string, defaults=None)[source]¶

This decorator populates env.hosts, env.conf and calls update_env():

from fab_deploy import *

@define_host('my_site@example.com')
def my_site():
    return {
        'DB_USER': 'my_site',
        'DB_PASSWORD': 'password',
    }

Decorated function should return a dict with desired env.conf values.

Django¶

fab_deploy.django_commands.migrate(params='', do_backup=True)[source]¶

Runs migrate management command. Database backup is performed before migrations if do_backup=False is not passed.

fab_deploy.django_commands.manage(*args, **kwargs)[source]¶

Runs django management command. Example:

fab manage:createsuperuser

fab_deploy.django_commands.syncdb(params='')[source]¶

Runs syncdb management command.

fab_deploy.django_commands.test(*args, **kwargs)[source]¶

Runs ‘runtests.sh’ script from project root. Example runtests.sh content:

#!/bin/sh

default_tests='accounts forum firms blog'
if [ $# -eq 0 ]
then
    ./manage.py test $default_tests --settings=test_settings
else
    ./manage.py test $* --settings=test_settings
fi

Deployment¶

fab_deploy.deploy.full_deploy()[source]¶

Prepares server and deploys the project.

fab_deploy.deploy.deploy_project()[source]¶

Deploys project on prepared server.

fab_deploy.deploy.make_clone()[source]¶

Creates repository clone on remote server.

fab_deploy.deploy.update_django_config(restart=True)[source]¶

Updates config.py on server (using config.server.py)

fab_deploy.deploy.up(branch=None, before_restart=<function <lambda> at 0x36ea6e0>)[source]¶

Runs vcs up or checkout command on server and reloads mod_wsgi process.

fab_deploy.deploy.setup_web_server()[source]¶

Sets up a web server (apache + nginx).

fab_deploy.deploy.push(*args, **kwargs)[source]¶

Run it instead of your VCS push command.

The following strings are allowed as positional arguments:

• ‘notest’ - don’t run tests
• ‘syncdb’ - run syncdb before code reloading
• ‘migrate’ - run migrate before code reloading
• ‘pip_update’ - run virtualenv.pip_update before code reloading
• ‘norestart’ - do not reload source code

Keyword arguments:

• before_restart - callable to be executed after code uploading but before the web server reloads the code.

Customization example can be found here.

fab_deploy.deploy.undeploy(confirm=True)[source]¶

Shuts site down. This command doesn’t clean everything, e.g. user data (database, backups) is preserved.

fab_deploy.system.create_linux_account(*args, **kwargs)[source]¶

Creates linux account, setups ssh access and pip.conf file.

Example:

fab create_linux_account:"/home/kmike/.ssh/id_rsa.pub"

fab_deploy.system.create_sudo_linux_account(*args, **kwargs)[source]¶

Creates linux account, setups ssh access and adds the created user to sudoers. This command requires root ssh access.

fab_deploy.system.ssh_add_key(pub_key_file)[source]¶

Adds a ssh key from passed file to user’s authorized_keys on server.

fab_deploy.system.install_sudo(*args, **kwargs)[source]¶

Installs sudo on server.

Virtualenv/pip¶

fab_deploy.virtualenv.pip(*args, **kwargs)[source]¶

Runs pip command

fab_deploy.virtualenv.pip_install(*args, **kwargs)[source]¶

Installs pip requirements listed in <PIP_REQUIREMENTS_PATH>/<file>.txt file.

fab_deploy.virtualenv.pip_update(*args, **kwargs)[source]¶

Updates pip requirements listed in <PIP_REQUIREMENTS_PATH>/<file>.txt file.

fab_deploy.virtualenv.pip_setup_conf(username=None)[source]¶

Sets up pip.conf file

MySQL¶

fab_deploy.mysql.mysql_execute(sql, user=None, password=None)[source]¶

Executes passed sql command using mysql shell.

fab_deploy.mysql.mysql_install(*args, **kwargs)[source]¶

Installs mysql.

fab_deploy.mysql.mysql_create_db(db_name=None, db_user=None, root_password=None)[source]¶

Creates an empty mysql database.

fab_deploy.mysql.mysql_create_user(db_user=None, db_password=None)[source]¶

Creates mysql user.

fab_deploy.mysql.mysql_grant_permissions(db_name=None, db_user=None)[source]¶

Grants all permissions on db_name for db_user.

fab_deploy.mysql.mysqldump(dir=None, db_name=None, db_user=None, db_password=None)[source]¶

Runs mysqldump. Result is stored at <env>/var/backups/

Working with crontab¶

fab_deploy.crontab.crontab_set(content)[source]¶

Sets crontab content

fab_deploy.crontab.crontab_add(content, marker=None)[source]¶

Adds line to crontab. Line can be appended with special marker comment so it’ll be possible to reliably remove or update it later.

fab_deploy.crontab.crontab_show()[source]¶

Shows current crontab

fab_deploy.crontab.crontab_remove(marker)[source]¶

Removes a line added and marked using crontab_add.

fab_deploy.crontab.crontab_update(content, marker)[source]¶

Adds or updates a line in crontab.

Web servers¶

fab_deploy.apache.touch(wsgi_file=None)[source]¶

Reloads source code by touching the wsgi file.

fab_deploy.apache.apache_restart(*args, **kwargs)[source]¶

Restarts apache using init.d script.

fab_deploy.nginx.nginx_install(*args, **kwargs)[source]¶

Installs nginx.

fab_deploy.nginx.nginx_setup(*args, **kwargs)[source]¶

Updates nginx config and restarts nginx.

Preparations¶

django-fab-deploy requires latest fabtest package for running tests and (optionally) coverage.py for test coverage reports:

pip install -U fabtest
pip install coverage

Please follow instructions for fabtest package in order to prepare OS image. django-fab-deploy tests have 1 additional requirement: root user should have ‘123’ password (fabtest example VM images are configured this way).

Running tests¶

Pass VM name (e.g. Lenny) to runtests.py script:

cd fab_deploy_tests
./runtests.py <VM name or uid> <what to run>

<what to run> can be misc, deploy, all, prepare or any value acceptable by unittest.main() (e.g. a list of test cases).

Some tests require additional prepared snapshots in order to greatly speedup test execution. But there is a chicken or the egg dilemma: these snapshots can be only taken if software works fine for the VM (at least tests are passed). So there is a very slow prepare test suite that ensures preparing will work.

1. make sure slow tests are passing:

   ./runtests.py "VM_NAME" prepare

2. prepare snapshots:

   ./preparevm "VM_NAME"

3. tests can be run now:

   ./runtests.py "VM_NAME" all

chmod 0600 fab_deploy_tests/keys/id_rsa

Coverage reports¶

In order to get coverage reports run:

cd fab_deploy_tests
./runcoverage.sh <VM name or uid> <what to run>

html reports will be placed in htmlcov folder.

0.7.5 (2012-03-02)¶

• root_password argument for mysql_create_db (thanks Michael Brown).

0.7.4 (2012-03-01)¶

• django-fab-deploy now is compatible with fabric 1.4 (and require fabric 1.4);
• nginx and wsgi scripts are now compatible with upcoming django 1.4; example of django 1.4 project configuration is added to guide;
• shortcut for passing env defaults in define_host decorator;
• Ubuntu 10.04 apache restarting fix;
• config_templates/hgrc is removed;
• tests are updated for fabtest >= 0.1;
• apache_is_running function.

In order to upgrade install fabric >= 1.4 and make sure your custom scripts work.

0.7.3 (2011-10-13)¶

• permanent redirect from www.domain.com to domain.com is added to the default nginx config. Previously they were both available and this leads to e.g. authorization issues (user logged in at www.domain.com was not logged in at domain.com with default django settings regarding cookie domain).

0.7.2 (2011-06-14)¶

• Ubuntu 10.04 (lucid) initial support (this needs more testing);
• backports for Ubuntu 10.04 and 10.10;
• docs are now using default theme;
• remote django management command errors are no longer silinced;
• invoking create_linux_account with non-default username is fixed;
• define_host decorator for easier host definition;
• default DB_USER value (‘root’) is deprecated;
• default nginx config uses INSTANCE_NAME for logs.

In order to upgrade please set DB_USER to ‘root’ explicitly in env.conf if it was omitted.

0.7.1 (2011-04-21)¶

• DB_ROOT_PASSWORD handling is fixed

0.7 (2011-04-21)¶

• requirement for root ssh access is removed: django-fab-deploy is now using sudo internally (thanks Vladimir Mihailenco);
• better support for non-root mysql users, mysql_create_user and mysql_grant_permissions commands were added (thanks Vladimir Mihailenco);
• hgrc is no more required;
• ‘synccompress’ management command is no longer called during fab up;
• coverage command is disabled;
• nginx_setup and nginx_install are now available in command line by default;
• mysqldump no longer requires project dir to be created;
• home dir for root user is corrected;
• utils.detect_os is now failing loudly if detection fails;
• numerous test running improvements.

In order to upgrade from previous verions of django-fab-deploy, install sudo on server if it was not installed:

fab install_sudo

0.6.1 (2011-03-16)¶

• verify_exists argument of utils.upload_config_template function was renamed to skip_unexistent;
• utils.upload_config_template now passes all extra kwargs directly to fabric’s upload_template (thanks Vladimir Mihailenco);
• virtualenv.pip_setup_conf command for uploading pip.conf (thanks Vladimir Mihailenco);
• deploy.push no longer calls ‘synccompress’ management command;
• deploy.push accepts ‘before_restart’ keyword argument - that’s a callable that will be executed just before code reload;
• fixed regression in deploy.push command: ‘notest’ argument was incorrectly renamed to ‘test’;
• customization docs are added.

0.6 (2011-03-11)¶

• custom project layouts support (thanks Vladimir Mihailenco): standard project layout is no longer required; if the project has pip requirements file(s) and a folder with web server config templates it should be possible to use django-fab-deploy for deployment;
• git uploads support (thanks Vladimir Mihailenco);
• lxml installation is fixed;
• sqlite deployments are supported (for testing purposes).

If you are planning to migrate to non-default project layout, update the config templates:

• in apache.config and nginx.config: replace {{ SRC_DIR }} with {{ PROJECT_DIR }}

• in django_wsgi.py: replace {{ SRC_DIR }} with {{ PROJECT_DIR }} and make sure DJANGO_SETTINGS_MODULE doesn’t contain INSTANCE_NAME:

  os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
  

0.5.1 (2011-02-25)¶

• Python 2.5 support for local machine (it was always supported on servers). Thanks Den Ivanov.

0.5 (2011-02-23)¶

• OS is now auto-detected;
• Ubuntu 10.10 maverick initial support (needs better testing?);
• fabtest package is extracted from the test suite;
• improved tests;
• fab_deploy.system.ssh_add_key can now add ssh key even if it is the first key for user;
• ‘print’ calls are replaced with ‘puts’ calls in fabfile commands;
• django management commands are not executed if they are not available.

You’ll probably want to remove env.conf.OS option from your fabfile.

If you’re planning to deploy existing project to Ubuntu, add NameVirtualHost 127.0.0.1:{{ APACHE_PORT }} line to the top of your config_templates/apache.conf or delete the templates and run django-fab-deploy config_templates again.

0.4.2 (2011-02-16)¶

• tests are included in source distribution

0.4.1 (2011-02-14)¶

• don’t trigger mysql 5.1 installation on Lenny

0.4 (2011-02-13)¶

• env.conf.VCS: mercurial is no longer required;
• undeploy command now removes virtualenv.

0.3 (2011-02-12)¶

• Debian Squeeze support;
• the usage of env.user is discouraged;
• fab_deploy.utils.print_env command;
• fab_deploy.deploy.undeploy command;
• better run_as implementation.

In order to upgrade from 0.2 please remove any usages of env.user from the code, e.g. before upgrade:

def my_site():
    env.hosts = ['example.com']
    env.user = 'foo'
    #...

After upgrade:

def my_site():
    env.hosts = ['foo@example.com']
    #...

0.2 (2011-02-09)¶

• Apache ports are now managed automatically;
• default threads count is on par with mod_wsgi’s default value;
• env.conf is converted to _AttributeDict by fab_deploy.utils.update_env.

This release is backwards-incompatible with 0.1.x because of apache port handling changes. In order to upgrade,

• remove the first line (‘Listen ...’) from project’s config_templates/apache.config;
• remove APACHE_PORT settings from project’s fabfile.py;
• run fab setup_web_server from the command line.

0.1.2 (2011-02-07)¶

• manual config copying is no longer needed: there is django-fab-deploy script for that

0.1.1 (2011-02-06)¶

• cleaner internals;
• less constrains on project structure, easier installation;
• default web server config improvements;
• linux user creation;
• non-interactive mysql installation (thanks Andrey Rahmatullin);
• new documentation.

0.0.11 (2010-01-27)¶

• fab_deploy.crontab module;
• cleaner virtualenv management;
• inside_project decorator.

this is the last release in 0.0.x branch.

0.0.8 (2010-12-27)¶

Bugs with multiple host support, backports URL and stray ‘pyc’ files are fixed.

0.0.6 (2010-08-29)¶

A few bugfixes and docs improvements.

0.0.2 (2010-08-04)¶

Initial release.