DTAP Best practice, database copy tool

Wiki
1

Development, testing, acceptance and production (DTAP) is a phased approach to software testing and deployment. The four letters in DTAP denote the following common steps: (Wikipedia)

  1. Development: The program or component is developed on a development system.
  2. Testing: Once the software developer thinks it is ready, the product is copied to a test environment, to verify it works as expected. This test environment is supposedly standardized and in close alignment with the target environment.
  3. Acceptance: If the test is successful, the product is copied to an acceptance test environment. During the acceptance test, the customer will test the product in this environment to verify whether it meets their expectations.
  4. Production: If the customer accepts the product, it is deployed to a production environment, making it available to all users of the system.

The set of environments used for a DTAP cycle is often called a DTAP street.

The set of environments can be smaller or larger, depending on the demands of the project. Examples of other steps used within Novulo are:

  1. Configuration: This environment is used to create new configuration, like Activity templates or REST endpoints, to act as a repository for configuration
  2. Pre-live: This environment can be used to dry-run a production release, not interfering with the Acceptance environment
  3. Training: to use for training, not interfering with Acceptance or Production

In Novulo Deployment, it’s possible to set-up a DTAP-street with corresponding behaviour.

Typical setup, growth path and best practices

We recommend a minimum of three environments. For small projects, with few developers and testers, often 3 environments suffice.

  1. Development (with Test & Conf): This environment is used for Development, Testing and to develop and maintain configuration.
  2. Acceptance: this environment is used for User acceptance as well as dry-run for production. It is not used to store any information that must be kept. This also means that you shall not use the Acceptance environment as a configuration environment;
  3. Production
Dev Dev Acc Acc Dev->Acc Prod Prod Acc->Prod

When development is getting more extensive, and the team is growing, further separation is needed to maintain a structured process.

  1. Splitting Development to its own environment allows for developers to develop new functionality, while not disturbing the Test team working on the test environment. You will also use the Development environment to develop and maintain configuration.
Dev Dev Test Test Dev->Test Acc Acc Test->Acc Prod Prod Acc->Prod
  1. Splitting Configuration to its own environment allows for people who configure complex configuration, like Export definitions, REST endpoints or workflow configurations, to develop and store their configuration, while not being disturbed by component developers, and not interfering with a test team.
Dev Dev Conf Conf Dev->Conf Test Test Conf->Test Acc Acc Test->Acc Prod Prod Acc->Prod

Restore database and Database copy tool

To validate an acceptance release, the best practice is to accept on a live-like environment. By doing so, users will accept in an environment with data they recognize: they know the products, settings, they recognize prices, stock levels, etc. This gives better acceptance sessions compared to validating on an environment with years-old data.

Furthermore, you will be able to test performance based on a realistic database size.

To facilitate this, Novulo has developed the Novulo Database copy tool. This makes it possible to

  1. Create a backup from the production environment
  2. Restore it on acceptance
  3. Run a series of predefined scripts, for example to change configuration from Production to Acceptance

This allows you to restore a database to make Acceptance like Production. The database restore procedure restores a full database, so all information that existed, is lost.

Test Test Acc Acc Test->Acc App + config Prod Prod Acc->Prod App + config Prod->Acc Database

If configured so, it can also be used to restore to other environments.

After you ran a database restore, the version of your application will not match with the database.

Example:

  1. Production is on revision 5
  2. Acceptance is on revision 10
  3. The production database is on revision 5
  4. After restore the database to Acceptance, you’ll have an application on revision 10 with a data model for revision 5
  5. To solve this, run an Installation in Deployment to re-install version 10, triggering the update scripts. This is only an Installation, there is no need to Integrate or Generate. (It’s the same step as between other DTAP environments). This also works as a dry-run for your Production Installation. It allows you to check the data conversion on actual data and to measure the time it takes to install, helping your downtime planning for the production release.

Advanced DTAP with headless CMS and front-ends

When you are using an advanced DTAP set-up with headless CMS and independent release cycles, you might want a Prelive environment between Acc and Prod. See DTAP Advanced for multi DTAP environemnts for more information.

2 Likes