Drupal deployment strategy
18 Feb
- Development
- Staging
- Live
Code updates
That is a fairly simple task, you should use a versioning system, I personally prefer GIT. Define separate branches in your project, one for each environment and push to the specific branch when you wish to make a deployment.
You can extend this process, for more granular version control to using Git Tags to deploy a specific version to a specific environment.
Database structure
As you know, Drupal keeps awful a lot of configuration and structure in it's database. When it comes to deployment plans, this is a real problem, there is no real solution to version a MySQL databse.
Although it hasn't been developed for this purpose, your solution here is the use of the Features module. It can export any exportable structure from the Drupal database. You can easily use this, but not limited to, export Views, Content-Types, Commerce product definitions, User profiles.
Please keep in mind this can only export the structure, not the data.
Database data
This section is the most delicate, it realy depends on how your application consumes data and how it updates the data.
Usually the scenario covers, developers implement on dev where the database information is not important. The customer does the testing and acceptance on Staging, and End-users navigate the live environment.
On a regular basis you need to PULL data from Live to Staging and Development. It's possible that you also need to PUSH data from Staging to Live environment.
A good start point for this is to make smart use of this modules:
- Services
- Allows the systems to communicate using REST / JSON API both for pulling and pushing information.
- Node export
- Allows one server to pull data from another server using Feeds
- Universally Unique IDentifier
- Easy to treat duplicate entity_id's across servers / databases. It creates a Unique identifier for all entities that can be referenced in imports and exports.
