Deploying your Application¶
RapidSMS can easily be deployed in many ways. Deployment is a large topic, contains many right answers and is largely dependent on your application requirements. Our goal is not to provide the best solution or a configuration that will work on any application. We only want to provide you with the proper resources to make the best decisions.
Typical Deployment Steps¶
In order to deploy, you need to accomplish a number of things.
Initially:
Establish a virtual environment
Install Python dependencies
Install project code
Establish settings specific for that server (secret keys, passwords, location of database, etc.)
Sync database
Collect static files
Start processes (web server, workers, etc)
On each deploy:
Update Python dependencies
Update project code
Apply migrations to database
Collect static files
Restart processes
You might also want to:
Backup or download the database
Restore or upload the database
Backup/restore user-uploaded files
Different environments¶
The options for accomplishing these things depend in part on the server environment.
Non-PaaS¶
The Django documentation provides some advice about how to run a Django application like RapidSMS in production.
One approach you’ll often see when deploying to your own hardware or
to a virtual machine is using Fabric to implement deploy
commands that a developer can use. A developer might type
fab staging deploy to update the code on the staging server, or
fab production setup_server to provision the production server.
To help you write these commands, Fabric provides a library of methods
for running commands on your remote server, uploading files, etc.
PaaS¶
If you’re using a PaaS, your provider takes care of setting up your application on their servers, and will provide tools and documentation about how to deploy your application.
Examples¶
The RapidSMS wiki has a page with links to examples of how people provision and deploy RapidSMS applications.
