Provisioning Servers & Deploying Your Project¶
Provisioning are the steps required to prepare a server for a RapidSMS project installation. Deployment is the process of continually syncing code to a production environment as changes are made and tested in a development environment.
- RapidSMS projects can easily be installed in many ways.
Provisioning & Deployment are a large topics, contain many right answers and are largely dependent on your application requirements. Our goal is not to provide the best solution or a configuration that will work on any project. We only want to provide you with the proper resources to make the best decisions.
- Document sane defaults.
While there are many installation methods, there’s a common denominator of best practices that all production RapidSMS sites should follow (don’t use DEBUG = True). We will document a concise list of best practices.
- Example templates.
There are many options to consider: a bare metal server, cloud VM, platform as a service (PaaS). We don’t want to bless any single particular method, but we believe that linking to sample configurations for a small subset of these will provide a solid foundation and starting point for deploying your own application.
We can look at the overall production installation process in four parts:
Deciding where to run your application - Planning for a Provisioning & Deployment.
Preparing the server(s) to run your application - Provisioning.
Deployiong and updating your application to the server(s) - Deploying your Application.
Scaling up when your server can’t handle the traffic anymore - Scaling.
When deploying RapidSMS, you might also need to consider Gateways and Telecom Operators.
Note
Even if you don’t read anything else, the main things are:
Stop using runserver and switch over to Apache or your real server of choice.
Use a real database (not SQLite)
Turn off
DEBUG
!Follow the guidelines in What to Provision.
You can find community-contributed examples on the GitHub wiki.