Developing the Promet Way: Part III
Part I highlighted the challenges of deployments, defined good deployments, and introduced the tools for developing the Promet way. If you haven’t already, you should probably read Part I now.
Part II covered the tools used to set up the framework for developing a Drupal site. These tools download modules, themes, libraries, place all the pieces in the correct Drupal structure, and create a settings file based on the environment. Check out Part II if you haven’t already.
Part III covers Drupal Drop Ship - a tool for deployment.
Drupal Drop Ship
What is it?
Drupal Drop Ship “uses (a fork of) kw_manifests to provide a reusable deployment composed of manifests” (from the project README). Under the hood, it runs updates, ensures that only the proper modules are enabled, and reverts all features to match the state which was defined in code.
Kraftwagen Manifests. “Kraftwagen Manifests is a Drupal module that provides the means to register and execute idempotent migrations” (from the project README). This means that a set of actions (called Manifests in Kraftwagen) should have the same results every time.
Environment variables. Drupal Drop Ship uses environment variables to define behaviors and configuration based on the operating environment (for example, enabling modules that aid development on development environments only). Keeping environment-specific configuration out of code potentially increases security by reducing the amount of sensitive information transferred. Environment variables are also more reliable than using Features to manage environment specific configuration.
Greater standardization. Drupal Drop Ship centrally defines a deployment and prevents developers from using varying deployments across projects. This makes it easier for other developers (or even sysadmins) to jump in and deploy a project they have not worked on before.
Forces smaller, more manageable releases. Drupal Drop Ship performs updates once. This prevents the case where there are so many version changes that performing updates has to happen multiple times. Only running updates once also encourages more frequent updating, which can increase application security and stability. Likewise, feature reversion only happens once and forces a changeset that is small enough for full feature reversion. Smaller, more manageable releases decrease the time necessary to test and actually deploy; smaller releases also reduce the chance of errors - allowing for a more rapid, “sane” release cycle.
Dependency definition. Since Drupal Drop Ship builds a dependency tree based on the project’s top-level module, feature dependencies must be thought through and clearly defined. Rather than a list of modules to enable (whether programmatically or manually), each feature defines the packages it requires. This makes it easier to identify and uninstall unused modules. In fact, Drupal Drop Ship disables and uninstalls modules that are not in the dependency tree.
For example, take a feature called Events Calendar that requires Views, Calendar, and the Event content type and is defined as a dependency of the Foo project. If Calendar and the Event content type are only used by Events Calendar and Events Calendar is removed from the Foo dependency list, Calendar and the Event content type will be also be uninstalled without requiring any additional actions.
The Promet Drupal 7 Framework pulls together tools open source tools created and/or used by the Drupal development team at Promet Source. Together, the tools set up the framework for developing a Drupal site and provide a reusable deployment.
You’ve now learned how to develop the “Promet way!” Let nail biting, hair pulling, and obscenity screaming be no more!