Established workflows are the key to maintaining a sustainable development practice. When developers agree on how to work together, the workflow is sustainable, which ultimately makes our business more sustainable.

As a company that creates and maintains complex, enterprise-level websites, our developers have to meet some basic criteria in order for us to work together effectively. We need to know how to create an environment where we can work without interrupting the work of our peers. We must know how to share and merge our work with other developers. We have to know how to migrate our work to staging and production environments. If we can’t meet these basic criteria, we end up with unsatisfied customers, flummoxed project managers, and frustrated, confused developers.

Without an agreement on how we work together, our development workflow becomes a mish-mash of differing processes for different clients. When our developers agree on how we work together, our workflow is sustainable, which ultimately makes our business more sustainable (for more information on building a sustainable business check out or sustainable web design cornerstone post.)

First, you need an environment to work where you won’t be interfering with the work of your fellow developers. While an account on a shared hosting provider or a VPS can work as a development environment, there are benefits to setting up your development environment on your local machine. You won’t need to be connected to the internet to access the development environment. You have control over the versions of software and libraries installed on your local machine, whereas a hosting company may not be able to accommodate specific needs due to their own processes. Here at Mightybytes, we are fond of MAMP for local environments, but are moving more toward using VirtualBox and Vagrant to standardize the creation and management of local development environments.

Secondly, we have to play well with our other developers. That means making an agreement about how we contribute and merge our work on the project. This is what source code management tools like Git and Subversion are made for. They allow users to contribute work safely to the same repository and provide tools to intelligently merge the work of multiple developers. At Mightybytes, our projects each have their own Git repository and each repository has a standard set of branches:

• master
• staging
• production
• [developer-1]
• [developer-2]
• [developer-3]
• … 
• [developer-n]

At Mightybytes, each developer has their own branch they commit to. When their work is ready to go to staging, they merge their branch into the staging branch. Once the work on the staging branch successfully completes our QA processes, the staging branch gets merged into the production branch. Using Git in the manner that we do also helps solve the issue of migrating our work to the correct environment. Our Git provider, Beanstalk, can automatically push any work committed to a specific branch to a server. After someone commits their work to the staging branch, that code is automatically pushed to the staging server for that project. If your Git provider doesn’t support automatically pushing to a server, you can use a tool like Capistrano to perform a pull of the most recent updates from the staging server.

Just getting your code to a server is only half the battle. Several of the software packages we use to build sites hold configuration settings about the project in the database. Git manages differences in code, but cannot do the same for entries in a database. If configuration changes cannot be represented in code, Git cannot migrate those changes from environment to environment. Rails handles this elegantly by the use of migrations. For Drupal projects, we’ve had great success with the Features module for encapsulating configuration in code. WordPress has a few options for migrating database changes between environments, but none of them are particularly robust.

Any sustainable development and deployment workflow is incomplete if you don’t take the time to document how it works. Perhaps its a bit morbid, but we test our development and deployment methodologies against a “hit-by-a-bus” contingency plan. Basically, we consider what would happen if the lead developer on any of our projects were to be hit by a bus and unable to continue working on the project. How long would it take another developer to step in and continue development? How long would it take for the new developer to create a development environment? How quickly could a new developer be deploying completed work to staging and production environments? Without documentation, the time to recover from the absence of a developer is increased. Having a documented, standardized way of creating environments and deploying work makes your workflow sustainable and better positions your company for recovery in the event of the catastrophic.

The bottom line is in order for your workflow to be sustainable, you should evaluate and choose a set of development and deployment tools that your team can understand and use with as little effort as possible. The less you have to change in your development and deployment processes from client to client, the less time you will need to spend with the details of managing a development project and the more time you can spend actually building something functional and beautiful.