When starting a new project we often outline our development process with our clients. The explanation helps our clients understand how important each aspect is to the immediate- and long-term success of their projects. This also illustrates the environment scheme needed. Luckily there are several Drupal-centric hosting option currently available. Our team chooses each project’s hosts based on the specific needs of the project. This means we've worked with nearly all of the major Drupal hosting platforms, and we're quite familiar with their strengths and weaknesses.
Git a Hold of Yourself
First and foremost, all Drupal development (and generally all development, ever) should be Git-enabled. Git is a version-control system developed to support distributed, non-linear workflows. Basically, Git will protect your project from human blunders and any developer-overstepping. It also provides a detailed history of the work performed. Git is an easy win.
Use Git for version-control to solve development headaches and keep your work backed-up.
Home Sweet Home
In the good ol’ days of the web, it was common for a “Webmaster” to edit files directly on the web-server using an FTP program. Today we know much, much better. A developer should first develop on their computer in a “local environment”: software operating on their workstation to emulate a server environment. Locally, a developer is able to produce verbose and incomplete code without worry of affecting the server’s versions where it might be viewed by the client or colleague (likely causing communication issues). Not to mention, it’s the fastest way to develop.
Develop locally for speed, to develop with an easy mind, and to reduce the chance of server-errors.
Three Musketeers: Dev, Stage, Live
It’s imperative for nearly every project to have three separate server environments for publishing development. Typically development work (code) is pushed-up to the other environments, and content is pulled-down.
1 – Development Environment
The Development Environment (“Dev”) is the first of the three - all work should be published to Dev first. This serves as a “scratch” environment, meaning that experimental or rough-draft code can be published with very few ramifications. Typically this environment is not available for client viewing, and it's intended for testing developmental work against a literal host. This also means that the Dev environment’s content is often overwritten with content from Stage or Live.
2 – Stage Environment
The Staging Environment (“Stage” or “Test”) is where approved work from Dev is published next. Stage is used to test the developmental work with content from the Live environment without affecting the live site. Most of the time the content on Stage closely resembles Live, or is updated to reflect Live's content for the purpose of testing.
3 – Live Environment
The Live Environment is (literally) where the production site is housed. It's the final destination of any developmental work completed that passes all tests and review from Dev and Stage. Very rarely is the content from Live overwritten by the other environments.
Leverage three separate server environments to ensure your work is ready for production.
Wrapping it All Up
Development can be a treacherous journey - you need a tried and true development process. Ensuring your project and team adheres to the principles above will save time, save effort and save your collective butts several times over.
