fab-support 0.3.5

Stages

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

test → dev → uat → production → old production

I have create a fab-support.py which does the heavy lifting of creating, updating and destroying each environment. The aim is that this should be hardly any more than the use of fabric and much simpler than the use of a full featured build Salt or Ansible. This is really only if you fit one of the use cases. Like Ansible this is a simple single master deployment system, unlike Ansible this is an opinated deployment of Django applications.

Suitable use cases:

• Simple Django to Heroku where you have at a minimum two stages eg UAT and Production.

  • Copes with Postgres database

  • Static data in AWS

• Deployment of Pelican static website

  • Deployment to local file system for use with a file server

  • Deployment to local for a file based browser

  • Deployment to S3

In the root fabfile create a dictionary like this which documents how to deploy each stage:

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': 'local_conf.py',
        'destination': 'C:/Sites/local.drummond.info',
        'copy_method': copy_file,
        'SITEURL': 'http://localhost:8042',
    },
    'production': {
        'comment': 'stage: For serving on local file server',
        'destination': '//10.0.0.1/web/www.drummond.info',
        'config_file': 'local_conf.py',
        'copy_method': copy_file,
        'SITEURL': 'http://www.drummond.info',
},
}

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 reimplemented using the standard env environment and support in Fabric.

• Free software: MIT license

• Documentation: https://fab-support.readthedocs.io.

Features

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

Credits

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

0.3.0 (2019-11-12)

This is actually a series of major breaking changes.

• Changing from requirements.txt to pipenv for managing dependencies

• Changing from predefined tasks to methods which can be used. The destination eg heroku or dokku is abstracted into the definition of the stage.

• Implementation of dokku alongside Heroku as a deployment platform

0.2.1 (2018-05-11)

• Updating pelican commands to the parameter method of passing stage.

Note tests were failing to a non obvious cause. This was Heroku CLI needed updating to the latest version. I manually upgraded.

0.2.0 (2018-04-20)

• Change the way environment variables are passed through.

In version 0.1 only the following variables were considered env variables:

‘DJANGO_SECRET_KEY’, ‘DJANGO_ADMIN_URL’, ‘DJANGO_AWS_ACCESS_KEY_ID’, ‘DJANGO_AWS_SECRET_ACCESS_KEY’, ‘DJANGO_AWS_STORAGE_BUCKET_NAME’, ‘DJANGO_MAILGUN_API_KEY’, ‘DJANGO_SERVER_EMAIL’, ‘MAILGUN_SENDER_DOMAIN’, ‘DJANGO_ACCOUNT_ALLOW_REGISTRATION’, ‘DJANGO_SENTRY_DSN’, ‘XERO_CONSUMER_SECRET’, ‘XERO_CONSUMER_KEY’

Now there is an ‘ENV’ list of variables that allows any variables to be passed through and also for them to renamed on the way from the file .env

0.1.0 (2018-02-04)

• First release on PyPI.