Drupal Deploy Strategy
Have been worked on many Drupal projects these years. Even though, most of the projects have version control system. But everyone has different ways. Today, I want to share one of them that I think is great. Because of it, there was no accident in the over 5 deployments during a half year period.
The biggest headache for Drupal deployment is the conflict between the configuration and the content. Content is moving downward from product to staging to development. But the configuration is moving upward from development to staging to production. Both of configuration and content are existing in a same database and same tables sometimes. So, we can not separate them and move the configuration only upward to production. We used features module and packed most of the configurations into several features. But there was some manual configuration we had to do. The CTO did not want developers to have administrator access to the production server. I agree that it is a good idea, since it helps stabilize the production environment. But they had to have someone know Drupal to configure the production site. So, they appoint me as configuration manager position to do that job. Well, the good news is Drupal 8 have moved configuration into code. Hopefully, that will solve the problem gracefully.
It was a typical Drupal website for a small content publisher. We had 5 Drupal developers, 2 QAs, a project manager and a business analyst. We had a group of in-house editors who would be very upset if our system had something wrong during deployment. We needed a good strategy to make sure successful deployment within the maintenance window. Usually, the downtime was 2 hours.
We used Jira for the issue queue. There was a Jira expert helped us set up the process. Issue went through various stakeholders according the designed process. Project manager would decide whether to approve each ticket for next release. Developers would see all the approved tickets in a working pool. After solve the problem, developers marked the ticket as done. It would then in the queue of the configuration manager. In the end, configuration manager would make a quick snapshot of the dev branch and mark all the related tickets as QA ready. He then worked with system admin to push the code to staging and did any necessary manual configurations. We were using features module extensively. It kept the manual configuration at minimal. We also put all the necessary manual configuration steps in Jira tickets. QA then got onto the staging server and verified and approved each ticket. Ticket had failed to pass QA will be disapproved, and dev team had to deal with it again. The whole process was reiterated until every ticket passed QA. Then QA marked all the tickets as passed.
At last, configuration manager used the latest release tag and merged the Git dev branch into the production branch. Make a release version tag on production. Also after that, merge back all the hotfix branch back into the dev branch. There is a great article about Git branching model. I think it worthy of time to read it for every developer.