The “Dev Seed Stack” consists of a set of modules originally built by Development Seed, which are responsible for much of the reason that Drupal is capable of being maintainable at an enterprise level. The fundamental principle behind the stack is mitigating risk through increased code-level control over a Drupal site. It is intended to address the following concerns related to building, maintaining, and editing content in an enterprise Drupal site:
- Exposing the site to less risk by moving all development out of the production tier
- Simplifying and making the process of migrating functionality from development to production more manageable
- Securing and isolating protected production information (e.g. Passwords) by eliminating need for updating development databases from prod snapshots
- Ensuring that all tiers of development are actually in sync
- Expanding what we can allow content administrators to do, by moving their work to a development tier
- Simplifying editor work, by reducing necessity for editors to know html
Many of these concerns are not relevant to a small personal site, given that exploratory builders are not likely to have multiple tiers. Content administrators may want the ability to treat an enterprise site in the same manner that one might treat a personal site, by directly creating structure through the admin ui in a Block (as provided in core). Obviously, this creates a significant amount of risk, ranging from a lack of reliability across all tiers to the extreme end of opening attack vectors, depending on what is created in the block. However, in an enterprise situation with multiple tiers, production security, stability, and being able to rely on development tiers to accurately represent the production tier are key. Additionally, depending on what is being built in the block, this often represents a limited understanding of how site structures work and serves as a way to get around use of appropriate functionality (e.g. putting a navigation menu in a block as a list of links, rather than using a menu). This is a very quick path into the Land of Unmaintainable Sites.
The “Dev Seed Stack” mitigates these risks by providing a manageable solution for exporting database-level changes to code, enabling version control to eliminate potential pitfalls. The stack typically consists of the following set of modules (which have been maintained by Phase2 since 2010):
The features module enables the capture and management of features in Drupal. A feature is a collection of Drupal entities, which, taken together, satisfy a certain use-case.
Strongarm gives site builders a way to override the default variable values that Drupal core and contributed modules ship with. It is not an end user tool, but a developer and site builder tool which provides an API and a limited UI.
Context allows you to manage contextual conditions and reactions for different portions of your site. You can think of each context as representing a “section” of the site. For each context, you can choose the conditions that trigger this context to be active and choose different aspects of Drupal that should react to this active context. Think of conditions as a set of rules that are checked during page load to see what context is active. Any reactions that are associated with active contexts are then fired.
Spaces is an API module intended to make configuration options generally available only at the sitewide level to be configurable and overridden by individual “spaces” on a Drupal site. It’s something like a more configurable version of Organic Groups.
This module assumes that custom blocks are configuration, and not content. It makes blocks fieldable, so they can be treated more like D7 core entities. Boxes provides an inline interface for editing blocks, allowing you to change the contents of blocks without going to an admin page, even including the ability to enable WYSIWYG formatters.
From a workflow standpoint, enterprise content administrators can still be allowed to actively create structural content through the admin ui, in the form of blocks (though we’ll come back to this one and talk about Boxes), views displays, and context layouts, even expanding that capability and allowing them to include PHP and JS/jQuery, treating them quite effectively as part of the development team. However, this work is done entirely in a development tier. Once the content administrator has created the structure, it can either be exported directly to code as a Feature or moved to an appropriate code-level structure, and pushed out to production via Git by a developer with primary repo and production server access (or automated process with server management utilities).
One thing this accomplishes is an alteration in how deployments work. Rather than viewing these types of changes as releases of note, it would be very easy to deploy most of these immediately or via automated nightly pull (thanks server tools!), as most Features changes require nothing more than a general cache clear after deployment, using drush. One could potentially reduce turn around on small requests to a few hours, including going through a full suite of automated tests.