Blogs

Executive Summary

A complex Drupal 7 project was undertaken involving 2 distributed dev teams and a content team working in parallel. The scenario is pre-go-live and The environments are on the Acquia Cloud and involves Development and Staging instances. The workflows across the instances were complicated by one dev team working with the content team and providing urgent 'hot fixes' on staging directly, with the second dev team was continuously working a weekly sprints and updating on live. The Infographic below gives an overview of the daily workflow followed to help development teams keep dev and stagin in sync on a daily basis

The Problem

The project was a web-portal with effectively 3 distributed teams. Client was keen that content updates, some key features be implemented in parallel with ongoing development. So, while one team was working on the final sprint, issues were being raised by client which was being handled by a different dev team; some hot fixes were being pushed directly on stage so the customer could see fixes yesterday, while the content team was merrily beefing up the content on the staging site.

Long story short, we were going through a situation where both dev & stage instances was being updated simultaneously, with both code, content and of course, code-in-the-database (content types, views, etc). We had gone through the exact same situation in a previous project and going live was, to put it mildly, a living nightmare. There were incompatible types, views changes, a dev inadvertently overwrote the staging DB and some crucial content was lost, and later retrieved after a lot of heartburn just before going live. What we learnt from that project was that it was imperative that we keep dev and staging in sync, preferably every day.

One early decision we made was that staging DB is *sacred* because losing content wasn't an option; devs could always work together and get lost code/view/CT back, but going back to the client content team for lost content wasn't an option.

The problem statement was thus reduced to the following:

1. The staging site would be the golden site and we would keep dev in sync with staging.

2. Staging database *had* to be kept intact, so we were guaranteed that content would not be lost. So step #1 was an invariant: Start the process by copying staging database to dev. Since all code-in-database dev tasks were on features, this wasn't a huge risk.

3. While dev had to be continuously in sync with staging, the stage site will fall behind dev, definitely mid-sprint so that content team would not be exposed to dev issues, but also possibly through completed sprints, in case it was too early to expose to client.

The final plan that we came up with is as shown the block diagram. As mentioned earlier, the first step was to copy the stage database directly to dev DB using the Acquia drag-and-drop so that the stage DB is guaranteed to be pristine.

We then did a quick test between local and acquia Dev to see if there are any changes in DB that we need to either create a feature of or leave as is. Another quick check was to ensure that our ongoing development isn't messing with the new content in any way.

The remaining steps are pretty clear in the diagram below. We merged the staging code with dev in our local and did another test between local and Acquia dev environment. Since we were doing this on a daily basis, code conflicts was easily resolved with the dev team; we probably had one call in the 4+ weeks that we had to do this exercise to sync code changes in staging to dev, rest of the merges were painless git merges.

Since the code and DB of dev were now guaranteed in sync with staging, we did not require to touch Acquia staging environment even for testing, since there would potentially be some intrusive tests required during sprints. Finally, we just pushed the local code to Acquia dev, updated features in dev so that it was fully in sync with staging.

Summary

The process, while simple and straight-forward worked really well and *should* work in most parallel development plus content update scenarios, which is quite often the case just before go-live in any project. Key takeaways:

1. Create a well defined process and follow in religiously. In the case of dev-staging sync daily sync is a great idea.

2. As always, "Content is King" take care of content and the client is always happy.

3. While code-in-database is a real issue, safe and consistent practices using features, views import/export, careful and detailed git comments works really well. Interestingly this works even if there are errant devs in the group, as long as at least one person/team takes up the task of keeping things honest and clean!