• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

WP Realm

WordPress news, community news, reviews and more from all over the world

  • News
  • Reviews
  • Tutorials
  • eCommerce
  • About
  • Contact

WordPress and DTAP

11 April 2013 by Floris Lof 10 Comments

Many companies I know use DTAP in their website development process. DTAP is an acronym for “Development, Testing, Acceptance and Production” and is used as a release management cycle in software development. If you are building complex websites – or rebuilding them – the use of a so called “DTAP street” is very useful. Over the past few years I’ve been working a lot with DTAP and WordPress, of course. Here’s my experiences and the choices I made.

A DTAP street

Using a DTAP street is all about managing the development and release of entirely new software or just for a newer release of the software already in production. When using a DTAP street in web development you are in fact using at least four environments and versions/copies of your website:

  • Development — (for example, http://projectname.development.companyname.com)
    This is a true developers’ environment and the place where the actual code is written. Are more developers working simultaneously on the same project? If so, you can have several simultaneous development environments. Just use SVN of Git for version control and for merging code. The main purpose of this environment is to implement the code which can be tested by the developer himself.
  • Testing — (for example, http://projectname.testing.companyname.com)
    The test environment is the next station for new code. Here, a tester (an interaction designer, for instance), tests the product and checks whether it works according to specifications; for this reason, this person should preferably not be the same person who wrote the code.
  • Acceptance — (for example, http://projectname.acceptance.companyname.com)
    It should be fully identical to the production environment, and even run on the same server. All integrations with back end systems, third party systems and cache systems (and settings) should match the live website. This environment is often used to perform tests prior to taking the software into production. This too, is the station where your customer ‘accepts’ the changes; in other words, it serves as the customer’s test environment as well.
  • Production — (for example, http://projectname.com)
    The production environment is your actual live website, to be used by your customer and his visitors. The main difference with acceptance is that there is no room for error here, and there should be no downtime.

One codebase to rule them all

Working with WordPress under DTAP means that you will have to run four separate installs of WordPress for every project and also running four databases. I’ve tried using fewer databases than four, for example using one database for development and testing; it really does not work well, since WordPress uses absolute URIs for your assets like Javascripts and CSS, and user generated content, such as images inside posts, will be scattered all over the place. Hence, I strongly recommend that you use a separate database for each install.

I want to keep my code completely portable between these environments; I hate deploying a site to another environment and have to fill out new database credentials in the wp-config.php or in any other setting. Since you are bound to forget it at some point, I use this simple code fragment in my wp-config.php for my (database) settings.

<?php
if ( stristr( $_SERVER['SERVER_NAME'], 'development' ) ) {
// ** MySQL settings DEVELOPMENT ** //
define( 'DB_NAME', 'projectname_dev' ); // The name of the database
define( 'DB_USER', 'projectname_dev_user' ); // Your MySQL username
define( 'DB_PASSWORD', '12345' ); // ...and a password an idiot would have on his luggage
define( 'DB_HOST', 'localhost' ); // 99% chance you won't need to change this value
define( 'WP_HOME', 'http://projectname.development.companyname.com' ); // home url
define( 'WP_SITEURL', WP_HOME ); // site url
define( 'WP_DEBUG', true ); // Debugging is always set to true on development!!!
define( 'WP_CACHE', false ); // You don't want caching while you are developing
} elseif ( stristr( $_SERVER['SERVER_NAME'], 'testing' ) ) {
// ** MySQL settings TESTING ** //
define( 'DB_NAME', 'projectname_tst' ); // The name of the database
define( 'DB_USER', 'projectname_tst_user' ); // Your MySQL username
define( 'DB_PASSWORD', '12345' ); // ...and a password an idiot would have on his luggage
define( 'DB_HOST', 'localhost' ); // 99% chance you won't need to change this value
define( 'WP_HOME', 'http://projectname.testing.companyname.com' ); // home url
define( 'WP_SITEURL', WP_HOME ); // site url
define( 'WP_DEBUG', true ); //Use the setting you want over here, could be true or false
define( 'WP_CACHE', false ); //Use the setting you want over here, could be true or false
} elseif ( stristr( $_SERVER['SERVER_NAME'], 'acceptance' ) ) {
// ** MySQL settings ACCEPTANCE ** //
define( 'DB_NAME', 'projectname_acc' ); // The name of the database
define( 'DB_USER', 'projectname_acc_user' ); // Your MySQL username
define( 'DB_PASSWORD', '12345' ); // ...and a password an idiot would have on his luggage
define( 'DB_HOST', 'localhost' ); // 99% chance you won't need to change this value
define( 'WP_HOME', 'http://projectname.acceptance.companyname.com' ); // home url
define( 'WP_SITEURL', WP_HOME ); // site url
define( 'WP_DEBUG', false ); //keep these settings identical to the production settings
define( 'WP_CACHE', true ); //keep these settings identical to the production settings
} else {
// ** MySQL settings PRODUCTION ** //
define( 'DB_NAME', 'projectname_prod' ); // The name of the database
define( 'DB_USER', 'projectname_prod_user' ); // Your MySQL username
define( 'DB_PASSWORD', '12345' ); // ...and a password an idiot would have on his luggage
define( 'DB_HOST', 'localhost' ); // 99% chance you won't need to change this value
define( 'WP_HOME', 'http://projectname.com' ); // home url
define( 'WP_SITEURL', WP_HOME ); // site url
define( 'WP_DEBUG', false ); //Debugging is always off on production sites
define( 'WP_CACHE', true ); //We want to cache our production site
}
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
view raw fpl_database_config.php hosted with ❤ by GitHub

Migrating WordPress

Now that you have your program code portable between the environments, you will only need to concern yourself with the database. It’s not often that you will have to deploy an entire site to another environment – usually only at the first deploy, but since you are bound to run into this at least once, let me try to explain this a little further.

wp-config is now set up in such a way that WP_HOME and WP_SITEURL are already defined for you. This means that WordPress will use these values instead of any values taken from the wp_options table. The result is that after having deployed to another environment and after having executed a database import, WordPress should already be able to run. However, as mentioned before, WordPress uses absolute URLs inside posts and these must be changed too.

There are several ways to migrate WordPress, such as the Backup Buddy plugin. I like to use a database search and replace script (Daniël van de Giessen wrote a real nice one with a lot of options, that you can download from Github). Whatever you choose, at the very least, you should read the WordPress Codex on changing your sites’s URL and on moving WordPress to another server.

As to the URIs inside posts, there are ways to let WordPress work with them; read this article on how it can be done manually. I, however, tend to agree with Joost de Valk who argues that relative URIs might not be a good idea.

More goodies

DTAP can also be used for your content workflow; there is a commercial plugin called RAMP which allows you to deploy content between you DTAP-environments.

Back to you

What are your experiences with DTAP and WordPress? Do you even use it? What obstacles did you encounter and how did you tackle them?

ShareTweet

Filed Under: Practical Tagged With: DTAP

Reader Interactions

Comments

  1. Daan Kortenbach says

    11 April 2013 at 11:49

    Using DTAP daily 🙂 Very powerfull in combination with version control.

    We do use a different method to define the wp-config.php constants by using a variant on Mark Jaquith’s local dev tips. With this method we can keep the database logins out of the repository by ignoring local-config.php. Just a preference but kind of handy if you outsource some work and don’t want to share critical information.

    Thanks for sharing.

    Reply
    • Floris P. Lof says

      15 April 2013 at 08:31

      Ah that is a nice tip! Thnx!

      Reply
  2. Peter Knight (@peterrknight) says

    12 April 2013 at 23:12

    Nice touch to this post with the graphic!

    I find DesktopServer coming in really handy setting up test and development sites.

    Reply
    • Remkus de Vries says

      17 April 2013 at 13:49

      I’m a big fan of DesktopServer too. Only wish I had was an easier way to change PHP modules + the ability to set custom domain names instead of being forced to use the .dev extension.

      Reply
      • Daan Kortenbach says

        20 April 2013 at 16:47

        Forced .dev is a no go for me.

        Reply
  3. Ruben Woudsma says

    15 April 2013 at 11:38

    Nice wrap-up regarding the DTAP-street for WordPress. What I was missing the the above article is the usage of a local development (sandbox) when working in large teams. And how to handle Quick fixes after go-live. Will you in this case use the acceptance environment or can’t this best be done with a quick fix environment?

    Situation: Tasks will be assigned to the developers. They change the code local and check this in into the development environment.

    Will this best be solved with the suggestion/article from Mark? Furthermore I found a nice article on WordPress Answers regarding the migration of the different versions (from test to acceptance, from development to test, etc), see the following answer: http://wordpress.stackexchange.com/a/182/31501

    Reply
    • Daan Kortenbach says

      20 April 2013 at 16:50

      This excellent Git branching model provides a workflow that incorporates hotfixes: http://nvie.com/posts/a-successful-git-branching-model/
      We use Tower.app to manage repositories on Github, Bitbucket, etc.

      Reply
    • Floris P. Lof says

      25 April 2013 at 09:00

      Indeed Ruben, when working in large teams it is very usefull to either have multiple development environments on a networkdrive or on your localhosts.

      A while ago we (at TriMM) were all working on a development-network drive, but that just became too slow. So we started working on our localhosts. Mark’s tips will indeed add some value here!

      Quickfixes after a go-live (or a phase 2) will be developed in the same manner. Develop on your Localhost/Development. Commit to SVN/GiT and update to testing/acceptance. After everything is tested and your customer is okay with it: update your production environment

      Really like the last link you supplied! Thnx!

      Reply

Trackbacks

  1. The WordPress Weekend Roundup - WP Daily says:
    13 April 2013 at 17:04

    […] 20. Development, Testing, Acceptance, Production […]

    Reply
  2. L’Hebdo WordPress n°182 : Attaques – Android – 10 ans | WordPress Francophone says:
    16 April 2013 at 07:46

    […] du cycle de développement depuis le développement jusqu’à la mise en production. Voici une application à WordPress […]

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

SUBSCRIBE

Our posts to your inbox. It's a wonderful thing.

Recent Comments

  • Remkus de Vries on Building a Multilingual Website? These are the Questions to Ask.
  • Tuba on Building a Multilingual Website? These are the Questions to Ask.
  • WPML, qTranslate eller Polylang: hvilken du skal velge og hvorfor? (2020) - My Blog on Building a Multilingual Website? These are the Questions to Ask.
  • Marian Malahin on Building a Multilingual Website? These are the Questions to Ask.
  • WPML,qTranslate X或Polylang – 三种最流行的多语言WordPress插件比较(2019) – wordpress on Building a Multilingual Website? These are the Questions to Ask.
Copyright © 2012 – 2023 WP Realm
Have you seen how fast Servebolt serves this site?