[wp-hackers] Deployment process (was Exporting Menus)

[Cornelius, Gregory]

Since Ken Zarque asked a while back, I thought it would provide some context and share a little about the process used at Boston U.    Our CMS, which hosts about 400 websites runs on top of WPMU 2.9.2.   Sometime in the next six months or so, we will upgrade to 3.x, which will take a bit of work due to the number of customizations that we have made, especially if we choose to move to the new menu system from our custom solution.  The CMS has about 25 themes and a number of customizations to make WordPress more page-centric.  Two plugins that play a role in workflows are our versions of wp-supercache and multi-site manager.

There are approximately 3 devs, 15 designers, and 5 technical support staff that handle the day-to-day logistics.   There are probably around 1,000 -2,000 content editors/producers.

Our main environments include:

* production
* staging (used for content development and front-end server configuration)
* development (used for qa and static site migration testing
* theme development (supercache disabled)
* qa
* developer sandboxes

Production and staging share a single codebase deployed to multiple servers and both connect to the same  database server / database.  The other development environments share a separate server / database server.   Depending on the project, they may or may not share the same development database.  In most cases, the switching of database connection info is automatic based on the server hostname in wp-config.php.  All code is managed using subversion following a typical repository structure (trunk, tags, vendor, branches).

All content work/review occurs in production/staging.  Content producers/editors make complete overhauls in the staging environment while day-to-day changes are made directly to the live site.   

* To launch a site (blog), we use the reassignment capability of multi-site manager coupled with a script for modifying the domain, moving static content, and invalidating the cache across servers.   This works fairly well.

* To clone a site (blog) from production back to test, we use another script that dump all the database tables, creates a new blog, modifies dump to change ids to match the id of the new blog, loads the tables in, copies static content, and modifies the database to match the new hostname / blog_id.

In both cases, the scripts actually simulate a request to wordpress to load up the API.  Requesting a launch is handled by our CRM via a link in WP admin. The handing of serialized data is the main gotcha.

The second script is also used to flow content into a development area or sandbox for testing, styling etc...  Since the database is different for the development areas, it is possible for user_id data in a production blog to point to a different user in the sandbox.   For most development work, this can be ignored, but it is less than ideal.

When a site exists in both production and staging, there also is the potential for production and staging data to get out of sync since there is not direct connection between the two.  Handling this is mostly a communication issue, but explaining the situation is not always easy when communicating with people that don't spend all day staring at WordPress.

There are other subtleties to the procedures and policies, but this overview should give other developers a sense.