As a sole developer or even as part of a small team (2-5 developers), setting up a development workflow seems on the face of it like a waste of time. Every minute that you're configuring version control, writing backup scripts, manicuring new environments, or simply tagging and pushing code around seems less fun than if those minutes were spent coding.
What happens though, when:
-A change is made on a production website that causes an irreversible database change
-You want to see which change made in the last two weeks caused a performance regression
-Management want to QA your work prior to release
-You want to dig deep into an issue that requires debug code out of your eyeballs
-Someone asks about your deployment strategy
As someone who has progressed from not knowing what HTML is to someone who pretends to know a little about Drupal, I most certainly fell victim to the trap of coding on production for a while. I had no version control, no backup strategy and if the worst had happened, I would have lost ALL of my content.
Since I've started working at Acquia, I've become intimately familiar with developmental workflow employed by enterprise level sites, where QA is mandatory and releases have to be signed off. These are sites with their own development teams and internal issue trackers to fill. The tools on the Acquia Cloud are, to put it simply, fantastic. Although as a solo developer myself, I'm aware that they're also beyond the needs of a lot of experimentalists and hackers.
This is where a personal developmental workflow strategy comes into play, and where good habits may be picked up.
Drush
Standing for DRUpal SHell, Drush is a command line tool for managing Drupal sites. Most of the useful commands may be found by visiting the online man pages so I'll only touch a little on the commands and more on the configuration of Drush such that it may become a tool for locally managing remote sites.
Git
With Drush managing the Drupal site we'll also need something to manage the code that runs the site; this is where version control comes in. Version control provides the ability to ensure complete accountability at every step in the development cycle with the handy benefit of backing up your code! Whilst there is a light hearted rivalry between proponents of git and SVN, I feel that git comes more naturally to me. With this in mind I'll be focusing on git as a VCS over the course of this guide with SVN being, unfortunately, out of scope.
Workflow
The simplest way to explain good workflow for a solo/small team is with the following:
1. Use a local environment to make changes pertinent to a single issue;
2. Once the issue is thought to be solved, thoroughly test in an interim environment;
3. With testing complete, move the changes into production.
This isolation of environments ensures that there is no pollution of bad code into a place that could affect visitors to the site, which in turn could affect business. It also allows for a production site to stay stable whilst a myriad of changes can occur locally which is conducive to an agile development environment.
Expanding on the above bullets we can see why this may have caused consternation in a traditional non drush/git system due to each step being a time sink. Since I'm such an automation advocate, it's my opinion that a workflow must be efficient if people are to be expected to use it.
