Developing, Testing and Releasing

2 Views

How do you develop, test and deploy-to-live your WordPress sites?

Its always a bit of a faff I find, especially where databases are concerned – mainly due to the fact that having a testing site needs a whole new database to be deployed which can sometimes be EXACTLY the same, except all the links are changed to the testing site url, instead of the live site.

Read More

Similarly any uploads that users have uploaded since the last time you needed to fix a bug or develop something new will have to be copied across to the testing site.

How do others do it? Do you just put up with the faff? Do you use clever version control systems which help?

Thanks

Post Views: 2

Related posts

Leave a Reply

1 comment

  1. There is a bit of personal philosophy that goes into a deployment workflow. It’s not an easy question to answer outright without knowing your experience with servers and version control, your operating system, hosting, client’s experience and tech culture, etc…

    1. Here’s a similar question that has a lot of explanation.
    2. For content deployment, you can check out Crowd Favorite’s RAMP plugin.
    3. WP Hackers is a great thread to find good information about deployments.

    Personally, I make sure that I never hard code absolute URLs in my themes. Use bloginfo() or code relative URLs. I use a lot of conditionals in my wp-config.php file. Here’s a vanilla version of my wp-config edits.

    switch($_SERVER['SERVER_NAME']){
    case 'dev.yourdomain.com':
        $db_host = '';
        $db_pass = '';
        //define debugging
        break;
    case 'stage.yourdomain.com':
        $db_host = '';
        $db_pass = '';
        break;
    default: //Live
        $db_host = '';
        $db_pass = '';
}
define('DB_PASSWORD', $db_pass);
define('DB_HOST', $db_host);

//You could also set this as a variable above
define('WP_HOME', 'http://'.$_SERVER['SERVER_NAME']));
define('WP_SITEURL', 'http://'.$_SERVER['SERVER_NAME']));

    I work on a lot of sites that follow the

    • local (personal hacking 🙂 on my laptop web server) >
    • dev (testing on client server) >
    • stage (stable source for QA – content editing) >
    • production (live site)

    Lastly, I would suggest you use a versioning tool to aid in your deployments such as GIT or SVN. It eases the process significantly and maintains source integrity between environments. Committing to your local is easily updated via command line on stage and production. It’s best during discovery to define what version control you and the client are going to be using from the outset if they have developers working on the project. I personally use GIT for my version control. However, if a client uses SVN, I do a mix of the two on my local so I maintain a repo for myself while also committing to their repo.

    We rarely have issues migrating from one environment to another. We do a find/replace in the DB to change the URL accordingly for embedded media, etc…