Executive Summary. This is a short, no-nonsense explanation directed to nontechnical website owners on what release control is all about and what problems it addresses.

Here's you:

  • You manage a business, a nonprofit, a governmental department.
  • You think about budgets, quotas, deadlines.
  • You need a website to achieve your objectives, make sales, connect with your clientele.

Here's what you don't (really) care about:

  • html, css, any other website acronym
  • Drupal 6, Drupal 7, Drupal 8
  • Other stuff that Drupal developers talk about... like release control

You just want your website to support whatever you need to do. You want the website to be reliable. You don't want to see or even think about code!

Fair enough. However, release control is something that you should know about and insist upon. Give me 5 minutes and I'll tell you why.

What if???

  • Your web site goes down because you applied fixes directly to your production site?
  • Your IT staff applied a fix to your production website, but it doesn't work correctly and you want to revert the site to the way it was.
  • You have a big change to your website and you're trying to test it on your live website.
  • A web developer created a test version of your website and you want to apply all of the changes to your production site.
  • You have several people working on your website at the same time and one programmer overwrites the changes made by the other programmer.

These are not just technical minutia that you, as a general manager, don't need to worry about. These disasterous scenarios are real and could easily happen to you. "Release control" is a practice you can use to mitigate the fallout from scenarios like these.

What is release control?

Release control creates a "repository" of your website's code. To me, "repository" sounds like "depository" or bank. In some ways, the repository is the "safe" for your website code. Here at Monarch Digital (and throughout most of the Drupal community) we use a system called "git", but there are other solutions out there.

Like your bank account, you can make deposits and withdrawals to your code repository. Your bank keeps track of every deposit and withdrawal and can report on your balance at any point in time.

  • Using your code repository, a web developer can pull the current production version of your website to work on it.
  • If something goes wrong, you can revert to a previous version of the website code.

This is where my banking analogy falls short:

  • If two developers are working on the site, the release control system can act as a traffic cop, preventing conflicting code from being checked in.
  • One developer can create their own version, or branch, of your production website to develop a long-term feature, while other developers are applying immediate changes to the production website.

How can release control prevent these problems?

With release control, you can always revert your code to a previous release. You are much less likely to have website outages due to coding conflicts. If you also have your developers test locally or on a staging site, changes to your production website are much more stable.

Now, it needs to be mentioned that there are sometimes reasons we wouldn't implement release control. Simply, because you can get your site updated without it. It's an extra step. It adds overhead. However, you'll need to ask yourself if you can stomach any of the potential website problems, perhaps disasters, that this best practice is engineered to solve.

Need help? We work on small and large websites. It is often easier to implement release control on large, mission-critical websites. However, even with small websites, we have found that the same rigor saves small websites from outages and errors. If you have ever experienced one of the these problems, you don't have to be sold much to implement release control on your site. This is one of a number of best practices that Monarch Digital implements on our sites. Reach out to us to for help on this topic!