Lately at Freelock, we've been improving our Drupal site assessment. For years we've analyzed Drupal sites built by others to identify how well they are built, what pitfalls/minefields lurk there, and where we need to be extremely careful with budget recommendations when extending functionality.
In the past couple months, we've overhauled it to include a snapshot rating of the site, to let our clients know what we think of their site in 7 crucial areas.
One of them that's often overlooked is Maintainability.
After receiving a site rating, a customer asked:
Can you also clarify whether the "Maintainability" is from Freelock's perspective or from my prospective?
... the answer is really from Freelock's perspective... as a provider of maintenance services.
What does "maintenance" mean, when it comes to web sites? For our customers, it may mean being able to keep their own content up to date. From our perspective, it's really a question risk management, balancing the need to keep the code running the site up-to-date and secure, with the need to not break the site while doing so.
We hear all the time about how "easy" it is to update a WordPress site -- log in and click a button. We also hear about a lot of people being burned by that "easy" update -- they press the button, their site blows up, and then they have to scramble to find a developer to fix it.
Drupal 7 ships with a very similar auto-update mechanism, and we don't use it for the same reason we think it's a bad idea in general -- it's far too easy to break functionality without having an adequate safety net to allow you to recover.
So... easy to maintain for us means several things:
- The code is in source code management, and all code updates can be easily rolled back
- The database is automatically backed up, and easy to restore to a previous point (or possible to extract previous configurations that can be applied on a broken site)
- There is a development/staging/production deployment workflow set up, and at least partially automated
- If there are any customizations, they don't get clobbered by upgrades -- it is clear to site maintainers what has been patched, how to re-apply patches if necessary, and how to avoid breaking customizations.
In short, a maintainable site is one that can be quickly, reliably updated with minimal (if any) downtime, with lots of fallback protection if something goes wrong.
Geeky Drupal stuff to follow
How do we do that in sites we maintain? Drupal 8 changes things, but in our Drupal 6 and 7 sites, we've developed some specific update processes and patterns.
First, we update our "freelock core" modules. We maintain these all as a set, and have them in a modules/freelock directory in each site. Each development copy of each site we maintain can pull directly from our upstream and merge in Drupal core updates and all the updates of the contrib modules we use regularly.
After those "core" modules are updated, we update all the remaining normal contrib modules in sites/all/modules. If there are any patches we've applied, we drop a patch file (with a Drupal.org issue id in the filename) into sites/all/patches, so we can quickly review whether any of the updated modules were previously patched, and if they were, we can see if the patch has been applied or the issue otherwise addressed in the new module release.
If a module has been customized substantially, or is entirely specific to this site, it goes in sites/default/modules, which our site maintainers ignore entirely. If a security issue is flagged in one of these, then it will take custom attention.
So this allows us to reliably and very quickly apply all module updates to a development copy of the site.
Testing deployments
Once the dev site is updated, we create a new release tag and push it into our central git repository, where Jenkins takes over. Jenkins automates our deployment to a stage server. It gets a fresh copy of the production database, checks out the new tagged release, clears the cache, runs all the database updates, and reverts all the features (applying configuration stored in code).
Once Jenkins has notified us in our chat room that the deployment is complete, we run a screen shot testing tool that takes a site-specific list of URLs and compares the copy on Stage with Production, stitching them side-by-side into a single image. After that's complete, we have a good idea of whether anything substantial broke on the public side of the web site. From there, we can run any other site-specific tests.
Releasing to production
On the production side of things, we manage quite a few servers, and we make sure that these have all the protections in place from the start -- regular backups of the database, entire server image backups, regular backups of the files. We do a final snapshot/tag of the production code base, then pull down the new release, apply database updates, and apply any feature changes.
The update report
There's quite a bit more to our maintenance plan than that... we take a look at the site report, the amount of content and rate of new content getting added, whether we see spam on the site or not, how effective we gauge the web site to be meeting its goals. So keeping the code up-to-date is just part of our regular service.
The rating
Ultimately, we rate the maintainability of a Drupal site to be related to how well it is built, and how much time it takes us to apply regular updates. It typically takes a few minutes to actually apply the updates on a site we've optimized for our process -- and once that has been done we can generally score the site a 4 or a 5. Unless the prior developers hacked contrib modules like crazy to get what they needed done -- this leads to sites that you can't update without breaking. So the higher the maintainability rating, the less time it takes to update, and the easier it is to keep secure.
Add new comment