At NEWMEDIA we have spent a great deal of time perfecting our site development process. Through many trials and errors we have converged on a SDP that works for us.
When working in a team or in an environment where your code and systems are going to be used by people other than yourself, it is especially important that your site development process is clear, simple, and easy to understand. This, of course, is easier said than done when developing a complex Drupal site. However, when our developers, site-builders and themers are all on the “same page” with code organization and philosophy we are a more effective and efficient team.
After speaking with members of the Drupal community, we believe it is time to start a discussion on how to have a process in place so as to minimize the friction when developing in a team/cooperative environment. In an effort to deep dive into our process this article will be the first in a series of articles discussing our SDP.
A lot of our SDP revolves around how to organize your code so that a developer or site-builder can quickly on-board to a project and larger teams can work together with minimal down-time. The broad pieces of our SDP are:
- Everything is in code.
- Sites are built using install profiles and the install profiles have a specific directory structure.
- Install profiles use Drush Make to capture dependencies on external modules, themes, and libraries.
- Drupal migrate is used to populate test content during the development phase. (optional)
- Features are used to capture site configuration. (optional)
- While a site is in development all functionality must be present after a fresh site install.
- After a site goes live update hooks can be used to enable new functionality on the production site.
- Use a virtualized environment which mirrors production. (recommended)