Continuous Integration and Deployment with Flask & Travis CI
Build environment for Flask development with Grunt for frontend development.
Testing and integration handled by Travis CI. Zero-downtime deployment stack with Nginx and Gunicorn, configured easily with Fabric locally or from Travis CI. Build flow based off of Batista Harahap's configuration
- Install the following:
npm install -g bower -g less to install bower & lessc
bower install to install browser packages from bower.json into /static/bower_components/
- Install virtualenv using
pip install virtualenv (Note: see flask virtualenv install docs for more info)
- Setup virtualenv:
- On Windows:
env\scripts\activate; On Linux:
- Install python packages with
pip install -r requirements.txt (NOTE: Make sure you have activated the python virtualenv prior.)
flask_site/config/config.yml and DO NOT ADD IT TO GIT (do not delete
config_sample.yml, it is used for testing)
- New Flask routes are added to
routes.yml with associated controllers in the
- Install JS and CSS plugin resources with bower:
bower search PACKAGE to find a package.
bower install PACKAGE --save to install and remember package in
bower install animate.css --save)
- Add resources to bundles in
bundles.yml so they are compiled by Flask-Assets
- If you install a new python package with pip, run:
pip freeze > requirements.txt
- See Testing Flask Applications for useful info on how to make tests comprehensive.
- If you make any changes to
flask_site/config/config.yml, the file must be manually uploaded to
python start.py development to start Flask locally at 127.0.0.1:5000.
python start.py to test the production configuration.
nosetests --with-xunit --with-xcoverage --cover-package=flask_site --cover-erase tests
Fabric is used to easily setup and push code to deployment servers. Deployment configuration is based off of the 0-downtime blue-green deployment style.
Tested on Debian wheezy, but with minor alterations to
fabfile.py it should work with other distros.
Several variables are referenced in this section. Following is their descriptions:
$DEPLOY_HOSTS - the hosts you will deploy to (comma separated - I've only tested with one host)
$DEPLOY_PASS - the ssh password you will set for your deployment user (default:
admin) - NOT THE ROOT PASSWORD
$LIVE_SERVER_URL - the URL people will use to access your server (i.e. example.com)
$NEXT_SERVER_URL - the URL you can use to test changes before going live (i.e. dev.example.com)
This only has to be done once. If you'd like to use a different user besides
admin, change env.user in
From your remote machine as root:
apt-get install -y sudo (this is only necessary if it's not already installed)
adduser admin, and set the password to something feisty.
adduser admin sudo
From your local machine:
pip install fabric gitric
fab -H $DEPLOY_HOSTS -p $DEPLOY_PASS --set LIVE_SERVER_URL=$LIVE_SERVER_URL,NEXT_SERVER_URL=$NEXT_SERVER_URL prod setup_machine
Deploy automatically using Travis CI
.travis.yml if you're interested in exactly what's going on.
If you'd like to automatically deploy but manually switch from the new version to live, remove
.travis.yml and skip step 1 of the "Deploy Manually" section.
- Navigate to Travis CI and enable this repository to be built (login with your Github credentials).
- In settings, add the following environment variables (make sure they are all set to not display in log):
- Commit or push some changes to
fab -H $DEPLOY_HOSTS -p $DEPLOY_PASS prod deploy, enter
$DEPLOY_PASS again when prompted
- Alternatively, you can:
- add your local public key to
~/.ssh/authorized_keys on your production servers, or
--set SSH_PUB_KEY_FILE=$YOUR_PUB_KEY_LOCATION to automatically add and remove the key during deployment.
- (optional) test from
fab -H $DEPLOY_HOSTS -p $DEPLOY_PASS prod cutover
If you don't intend to test the server before going live, you can run the commands at the same time:
fab -H $DEPLOY_HOSTS -p $DEPLOY_PASS prod deploy cutover
- To skip Travis builds, include [ci skip] in the commit message.
- For a nice git branching model: http://nvie.com/posts/a-successful-git-branching-model/
- Because of Flask-Assets, the first user to visit your newly-deployed site will take a long time to load (while resources compile). Circumvent this by visiting
$NEXT_SERVER_URL before running