This is a guest post written and contributed by Josh Koenig, co-founder and evangelist for Pantheon, an all-in-one Drupal platform and a Rackspace partner.
If you’re a site owner or manager of a development team — someone who helps web developers stay productive and on-task — you face an interesting challenge. You need to support, motivate and coordinate a group of people who are basically doing magic. Even though the web is completely mainstream, the knowledge of how it all actually works is classic “sufficiently advanced technology.”
What do developers need to succeed? As someone who’s been on both sides of the table (and peeked behind the curtain), I have some general tips to share:
This might be tricky if your developers don’t want to use it, but in this modern era there’s really no excuse not to learn, love and religiously use version control. It’s the engineer’s “undo” and the best way to collaborate with others on projects.
While there are some niche tools that still have appeal, the undisputed leader in this space is Git. If you’re developing your website without a git-based workflow at the foundation, consider stopping until you can get that in place.
Nothing is faster than local development — where a developer sets up the “full stack” on their desktop or laptop, using their personal computer as client, server and development environment. You cut all network latency out of the picture completely, and let a high-powered modern CPU focus on delivering pages for one user only. You can also work without an Internet connection, which can come in handy.
In order to get this going, you’ll need ways to easily sync with the rest of the development team. Version control handles that for code, but you’ll need an efficient method to quickly grab database and files snapshots.
This sounds contrary to local development, and it is, but it’s no less important. If you don’t have an online workspace that will enable you to easily share your project with other team members, it’s going to make your process a nightmare of bureaucracy and slowdowns. You’ll need both online and local development if you want to move fast.
One thing that makes projects chaotic is when unexpected bugs crop up. The whole “it worked on my machine” conversation is everyone’s least favorite. For the sake of developer sanity and the project’s velocity, you need to ensure that developers are working against the latest code and up-to-date content, and that several different developers’ changes are tested together frequently.
Going along with the Continuous Integration point, there’s nothing — nothing — more frustrating than a bug that manifests in production. These can be absolute killers, and it’s crucial that you have places to develop and test your code that are running all the same things as production: same versions of service, same filesystem, same architecture, same everything.
If you are trying to figure out a bug, and it works locally but not in the deployment pipeline, you’ve got to get direct access to start hunting it down. Speculatively making git commits and pushing them up to see if they fix the issue (or at least give you some useful debugging output) makes everyone die inside. It’s also cumbersome and slow.
Drupal developers love Drush, the “Drupal shell” (or alternatively, “Drupal in a rush,” which is how it’s pronounced). Drush is a command-line utility for performing several common tasks on a Drupal site without having to log in or use a web browser. It’s awesome for automation or batch jobs. In order to make use of it in an online context, you need to provide SSH access to each of your environments, and then configure an “alias” file so developers can run drush commands from their laptops in the online environments.
The modern website performance stack goes well beyond LAMP. You need to make sure your developers have access to Redis, Solr and can test their work with a reverse-proxy cache like Varnish. Otherwise, they’ll be missing out on great features, and setting themselves up for bugs in deployment.
If you’re ever stuck trying to think up a conversation-starter with a group of developers, ask them what text editor they use. Everyone has their own favorite tools, from command-line to full IDEs. There’s no one solution that will solve all your development needs, and outside of the few general points I’ve made above, it’s generally not productive to force developers to standardize.
Instead, you get everyone aligned on the major points — using version control, developing and testing against the same stack, frequently integrating changes, using a solid deployment pipeline to go live — and then let them do whatever makes them the most productive.
Tools that allow developers to collaborate and integrate (like Github for version control) add value beyond their direct features. As more and more collaboration on site building and operation goes online, having shared real-time workspaces provides more and more value.
These kinds of tools and techniques are a part of every pro developer’s playbook.