Skip to main content

Implement staging in Fabric and recipes for pelican to [local, s3] and Django to Heroku.

Project description


.. image::

.. image::

.. image::
:alt: Documentation Status

.. image::
:alt: Updates

Code to implement staging in Fabric and recipes for using that staging for pelican deployments and Django to Heroku.
It supports a local .env file importing for storing secrets that you don't want to store in git.

Stages are the different stages of development of an application.
So they might go from:

test -> uat -> production -> old production

There are all different versions of the same application and may be active at the same time.

I have create a which does the heavy lifting. In the root fabfile create a dictionary like this which
documents how to deploy each stage:

.. code-block::

from fabric.api import env

# Definition of different environments to deploy to
env['stages'] = {
'localsite': {
'comment': 'stage: For serving locally on this computer via mongoose. ',
'config_file': '',
'destination': 'C:/Sites/',
'copy_method': copy_file,
'SITEURL': 'http://localhost:8042',
'production': {
'comment': 'stage: For serving on local file server',
'destination': '//',
'config_file': '',
'copy_method': copy_file,
'SITEURL': '',

Then the deployment by Pelican is pretty standardised eg build deploy and you have commands such as:

`fab localsite deploy`

I think it was inspired by BreytenErnsting_. This is then reiplmeneted using the standard env environment
and support in Fabric.

.. _BreytenErnsting:

* Free software: MIT license
* Documentation:

Django configuration

The Django configuration includes the following features:
- deployment to Heroku
- Celery support with aqmp
- Log trapping support with Papertrail

These are the variables that are set in the .env and are carried through to the development environments

Django settings

====================== ============= ===============================================================
Name Default Comments
====================== ============= ===============================================================
DJANGO_SETTINGS_MODULE {{app_name}} Two sccopes config.settings.test or config.settings.production,
====================== ============= ===============================================================

# Heroku

======================== ======================== ===============================================================
Name Default Comments
======================== ======================== ===============================================================
HEROKU_APP_NAME fab-support-test-app Name must start with a letter and can only contain lowercase letters, numbers, and dashes. The production name should end in `prod` for additional protection.
HEROKU_PROD_APP_NAME fab-support-app-prod Used to identify where to copy the production data from
HEROKU_OLD_PROD_APP_NAME fab-support-app-old_prod Name of production when promote uat to prod
HEROKU_POSTGRES_TYPE hobby-dev free to 10K rows, hobby-basic allows to 10M rows but costs $9 a month
PRODUCTION_URL *''* This is where the production URL should be hosted. empty string if no remote URL
======================== ======================== ===============================================================

Runs on Windows. If it is getting to complex then it should probably be ported to Ansible or Salt.

Clean up importing

Levels of fabfile in this module
In this module I use three levels of

- At the project root
- at the /tests root
- at a test/demo level

This can get confusing , howevery they operate at different levels. The project is about project operations eg
releasing to pypi.

The tests level is then about managing the tests. Some of these tests use fab support and a fab file which gives you
the third level.

Project level fabfile
This is used to do work on the distribution:

- Make deocumentation
- build wheels
- deploy wheels to the package manager

At the tests level
This is used to run local commands. Often the commands will be run from the test fab file level and then `lcd` to the
demo level.

At the tests/demo level
This is a model fabric file- however it is not like a normal one in that fab_support is not installed in the environment
and in fact is located at `../../fab_support`.


This package was created with Cookiecutter_ and the `audreyr/cookiecutter-pypackage`_ project template. Thanks Audrey

.. _Cookiecutter:
.. _`audreyr/cookiecutter-pypackage`:


0.1.0 (2018-02-04)

* First release on PyPI.

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

fab-support-0.1.9.tar.gz (57.9 kB view hashes)

Uploaded source

Built Distribution

fab_support-0.1.9-py2.py3-none-any.whl (17.2 kB view hashes)

Uploaded 3 6

Supported by

AWS AWS Cloud computing Datadog Datadog Monitoring Facebook / Instagram Facebook / Instagram PSF Sponsor Fastly Fastly CDN Google Google Object Storage and Download Analytics Huawei Huawei PSF Sponsor Microsoft Microsoft PSF Sponsor NVIDIA NVIDIA PSF Sponsor Pingdom Pingdom Monitoring Salesforce Salesforce PSF Sponsor Sentry Sentry Error logging StatusPage StatusPage Status page