Like most web professionals, I have a workflow that I continuously re-visit as new technologies become available. The goal is to find the most efficient way of producing work for a client that I can, in order to give the client a better price on the finished product. I’m generally not overly opinionated about workflows. I know what works well for me, but that might not be what works well for other developers. Everyone has to be efficient, and everyone has their own ways of being so.
To that end, there are certain aspects of a workflow that are considered best practice, and are considered that for a reason. Whatever your process, for example, some form of version control really needs to be a part of it. So, I’m opinionated about the fact that one should be using version control. Whether you prefer Subversion over Git, however, is something about which we can have conversations and agree to disagree.
Best Practices and Unicorns
Different platforms have different sets of best practices. Developing a site in Drupal indicates a slightly different set of best practices, for example, than developing a site in WordPress would indicate. Every platform has its own idiosyncrasies, and thus its own requirements in a good workflow.
I’ll give you an example. WordPress features automatic background updates for non-breaking releases (such as security patches). I think that this is one of its more valuable features, because I don’t (and neither do many clients) have the time to test and update every incremental core release prior to putting it in place on their sites. This feature ensures that security updates, at least, are in place automatically. All of my WordPress sites keep this feature enabled…I’m usually too busy doing client work to run every incremental update on my own.
My workflow for my own sites doesn’t involve SFTP at all. I work locally first, using Git for version control over the entire site, push everything to my remote repo and then pull changes down to my production environment. When automatic updates occur, this means pushing downstream…committing the changes in my production environment, and merging them in my local environment. While this is isolated to background updates in WordPress, many developers (especially many Drupal developers I’ve worked with) would consider this bad practice, and I think that it would be bad practice for Drupal. However, for a client who uses Git exclusively for deployment, this workflow makes sense to take advantage of this feature in WordPress.
I have other clients with managed hosting arrangements that won’t permit Git installation at all. These are cases in which I keep my local development on their sites in Git, and deploy changes via SFTP.
My point here is that a complete set of best practices that fits every project, or every platform, is a unicorn, and we probably shouldn’t get too hung up on our opinions.
A Workflow, Backward
I recently began working with a client who practices an “inverted workflow” in their projects. That is, they like the skeleton of the site with functionality built first, then have a design built around that, and implement the front-end aesthetics last. This struck me as being odd, and was honestly a difficult hurdle to overcome in my first projects with this client. I’ve learned to adapt, however, and the process has become effective in these projects.
There are drawbacks to this workflow, just as there are with any other process, but it works for this client and I’ve adapted my process to fit on these projects. Would I recommend it for every project, or even for every client? No, because there is no such thing as a “one size fits all” workflow. What I’ve learned, though, is to be even less opinionated that I have been about workflow and processes, because I’ve seen things of which I was extremely skeptical function well.
Do you use any workflows that seemed odd at first but turned out very functional? Do your clients? Let me know in the comments.