A continuation of our ongoing 'Completely Redoing a Website' series. Check out the other posts in this series, VoIP Phone Reviews Overhaul and The New OnSIP Site.
Hi there! You may be wondering who this stranger writing a blog post is. Well, allow me to introduce myself. I'm Will Mitchell, newest member of the OnSIP engineering team. I enjoy bad puns, card games, and black raspberry ice cream. But I'm not here to talk about that, so let me bridge to a more suitable topic before your patience melts away.
When I started here in January, I jumped right in with the rebranding of the OnSIP website. We're using Drupal 7 as a content management system (CMS) for the new site. While most of our engineering team had a hand in getting the redesign completed, very few of us had any experience with Drupal at the start of the process. That wasn't the case for long, and soon we were using Drupal to do some pretty complex things. For example, our Phone Reviews section uses two views with contextual filters to generate the two pages and eight blocks controlling the tabbed pages for each firmware version of each phone model we review. As another example, OnSIP users can log in with their My.OnSIP credentials to write customer phone reviews or post comments on the blog without admin approval, thanks to a custom Drupal module that hooks in with our web service API. Pretty cool, huh? Go ahead and try it! (Note that this does not work in reverse. Creating a website account does not automatically create a SIP account. For a free SIP account, visit our signup page.)
Like any project with more than a couple developers, managing changes from multiple sources was very important for the rebrand. Here at OnSIP, we primarily use Git for source control, which allows each developer to have their own local version of the website that they can modify without affecting other members of the team. While this works great for managing files, Drupal actually uses a combination of files on the system as well as content stored in a MySQL database. This means that a lot of the actual changes developers make never appear where Git can pick them up. This poses the question, how do you manage that database content alongside the filesystem? Should individual developers each have a local database or should there be one shared database for all developers to use?
Individual databases allow for each developer to have an independent Drupal instance running completely separate from all of the others. With my own database, I could make changes to my version of www.OnSIP.com with no fear of messing up other people. But if I want to check in those changes, anything I added to my database wouldn't propagate to other developers.
A single, shared database makes the propagation of content to other developers automatic. When I make a content change and Drupal puts it into the shared database, all other developers would see it more or less immediately (caching can cause a slight delay). With just one database, we would lose the safety of isolating problems if something goes wrong, but at least content updates could be shared.
In an attempt to get the best of both worlds, we used a combination of the two. We primarily shared one main database. However, if I wanted to try something that I was afraid would mess up that shared database, I would dump a copy to my local dev box and experiment with that. Once I had worked out the kinks of what I was doing, I could go back and make the changes to the shared database. And if I managed to irreversibly damage my database, I wouldn't cause any trouble to other developers. This worked really well most of the time, but there was still one particularly nasty issue with the shared database.
Warning: This example will assume some knowledge of Drupal. Proceed at own risk.
Let's say Alice wants to create a banner across the top of every page, so she creates a new block region. This is a filesystem change which she commits with Git. Then she adds a block to the region, maybe containing a contact link for website feedback. Drupal stores the new block in the shared database. Now Bob, another developer, comes along and accesses the block management site on his own instance of Drupal using the same shared database. He hasn't yet pulled in Alice's new block region from Git, but Drupal sees the new contact block in the database. Drupal marks it as being in an invalid region and disables it. In the shared database. When Alice refreshes the page on her version of the site, the block has disappeared, and she is very confused.
This was happening constantly in the early days of the project, when block regions were being added fairly often. Our workaround is effective, but admittedly not very subtle. We looked into the Drupal block module, found the line of code that disabled the incorrectly marked 'invalid' block, and removed it. Alice gets to keep her banner, and Bob doesn't notice it because he doesn't have the region anyway.
Once we had navigated the pitfalls of managing several Drupal instances together, development moved pretty smoothly. As for www.onsip.com, you've seen the end result, and I think all of us here are really happy with how it turned out. Has anybody else used Drupal, or any other CMS, for a project with many developers? Share your experience in the comments!