All Drupal developers have experienced this nightmare. You have been creating a great project, now it’s time to deploy it. No one wants to deal with it. No one wants to be the responsible of doing it.
If you are building a simple site, and there’s only a one time deployment, it’s not a big deal. You just have to follow the largely discussed and know simple rules.
The Rules:
- Use SVN (or CVS) to keep your code updated among the developers
- Deploy to production by backing up/restoring the database
- Create scripts to make the deployment process automatic
That’s all, the unique problem you could have is maybe that you will have to delete the test content/users and change some settings before going live, but in summary, it’s pretty easy.
When it’s about deploying code, it’s still easy to do if you followed the simple rules. You will have only to update your SVN branch and you are done.
When the nightmare begins?
The problem is deploying changes made in the CMS, but without wiping all the existing data. In other words, merging the database changes, the settings and content stored in the database.
Scenario 1: Big (or huge) Drupal projects
You have to deploy a project in multiple phases. So while the first phase is deployed and working in production, you have a bunch of developers working on the next phase (this means, implementing new code, creating new nodes, creating new views, editing existing ones, changing settings, users, permissions, etc.)
Read more of Cesar Salazar's take on: Enterprise Drupal: Project Configuration Management and Release Management.
