Herb v/d Dool Always a work in progress

New Processes I've Been Working On

Notable development tools and processes I've been working on

I've been working on a number of Drupal 6 to Drupal 7 upgrades. When it comes down to it, many of them take just as much work as an entirely new site. But I've been putting a lot of work into getting the firm I'm working for to adopt more efficient and resiliant deployment processes.

Migrating content

Using the migrate and migrate_d2d modules to script the mapping of fields from a Drupal 6 site to a fresh Drupal 7 site. This has been invaluable in the upgrade process even though there still ends up being lots of work with menus, dealing with translated content, blocks and views.

Using better deployment tools

I've had the chance to start using Pantheon for one of our clients and it's pretty awesome. It makes deployment and development much easier. You get three environments in the basic package: dev, testing and live. And Pantheon provides an easy UI for managing the deployment process between each stage. For example, when pulling in code changes to testing Pantheon easily allows you to pull in the live database to see how the new code would work on the live site without exposing any issues to the public.

We've also started using Beanstalk to help with deployment on projects where we can't put them on something like Pantheon. This is the only way we've been able to use version control across all projects. There has been some resistance to this at work.

Using Features and Configuration Management

A key part of improving deployment is putting all configuration changes into code instead of storing it all in the database, which is a big failing of Drupal. For this we've been using features and have started using configuration management. Features is widely used so I don't feel the need to talk about it. The latter is a Drupal 7 module that borrows heavily from the new Drupal 8 Configuration Management Initiative, which is much better at helping with the deployment process than Features. The Drupal 7 module works fairly well but it suffers from a resource-intensive UI and from being a contributed module which can result in poor support from more obscure modules. Still it has drush commands which help quite a bit.

All of these together have really helped improve my development.

Why this site. Why here

Yes, that's a rainbow shooting out of my head


There's a good reason this site is barebones. I'm busy and I can't always conjure up rainbows and unicorns. But I like it that way too. I aim to keep this very basic since other projects always take up most of my time.

Lately, I've been interested in simplifying the process of meeting the needs of our clients. Instead of offering a full-package solution that includes Drupal and CiviCRM, we should be thinking of providing the minimum amount of functionality that meets their needs. I've been quite interested in reading how Development Seed, which was a firm heavily involved in Drupal until a couple years ago, ditched Drupal altogether and dived into Github pages and Jekyll. They even started their own user-friendly markdown editor prose.io that connects with your github account (I'm using it right now). This was a major missing piece in moving to a "CMS-free" setup.

For my own work I don't need anything complex. Flat HTML is fine. I can edit my own images locally. That is partly why I'm now trying out Github pages for my own personal information. I've been using markdown for awhile on my other blog, which is run on Drupal.

My previous personal site was little more than a brochure site with a portfolio. The code was getting horribly out of date; security updates piled up. I just don't need that all. I could have moved it to Drupal Gardens or Wordpress.com but the chance to play with Github pages is too inviting.

Drupal can be quite powerful and we still end up using it for most projects, but clients seldom need everything that it has to offer and it is hard to resist the urge to turn on many features just because it's possible. When completing user stories we should be open to exploring new ways of completing the functionality with something that doesn't require a complete technology stack.