Drupal: simple OTAP workflow

This post describes a simple DTAP workflow used in the company I work for. We work according to the methodology DTAP (Development, testing, acceptance and production). Five drupal parts are subject to change between the different phases:
Assets (uploads / downloads)

  1. Assets (uploads / downloads)
  2. Content (database)
  3. Configuration (database: content types, views, module settings, etc)
  4. Settings (. php used database etc)
  5. Codebase (HTML / PHP templates, css etc)

Git will be used for version control. The following will be managed via Git:

  • Configuratie (using Features)
  • Codebase

Features is a drupal module that can be used to deploy Configuration between different environments. Think of content types, views, etc. The idea is to create a feature once via the GUI. Changes to a feature will be made by using drush.


Each developer has its own development. Any content which exists in the development environment will be ignored between stages. We often get content delivered to the customer’s at an early stage. Therefore a test environment is created at an early stage. The content manager will prefill the test environment with ‘live’ content. From that moment, the database of test environment is leading. Each developer creates Features from parts of the website which are done. Best is to make a Feature for each separate part of the website, like a blog, news etc.


In the test environment, all functionality is tested and integrated from the development environment. We distinguish internal and external testing. Changes in the content can be made directly in the test environment. Non content related changes and / or errors must be made / resolved in the development environment. These are then migrated into the test environment where they will be tested. At the time a developer wants to develop on the basis of the content from the test environment, a copy of the database from the test environment will be made. This would require the following steps:

  1. Make a backup of the database of his or her development environment
  2. New functionality should be exported via Features
  3. These features are imported on the test environment (migrated)
  4. A copy of the database of the test environment is placed on the development environment


If both internal and external tests have been completed the acceptance environment can be created. This is actually a copy of the test environment. The database of the acceptance environment will become leading. In the acceptance environment, the customer can make some last “small” changes and insert content.


After the customer has completed the acceptance the project can be put on the production environment. Again, from that moment the database production environment is leading. At the time the project is placed on the production environment all development, test and acceptance environments should be removed. At the time of new features, fixing errors a new development, test and acceptance environment need to be created. This means that the production environment is copied to a new development environment.

DTAP workflow schema
H = manual export of configuration that can not be exported by Features
K = after going live the development environment is replaced with the production environment

Leave a Reply