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

[ken zarque]

Thank you for giving us the run down of the Boston U WP infrastructure.  I
enjoyed the read.

The idea of having production and staging sharing the same database and base
code didn't cross my mind. that would make "deployment" a lot easier.  I'm
using WP 3.0+ , so what you described is essentially a single MS
installation which houses both staging and production?

for production debugging purposes, let's say a bug that's taking a while to
fix, do you always clone it back to the test environment?  or do you simply
clone a copy in stage (same DB same, code base )?

As far as production sharing the same code base and DB. If major changes are
happening in staging, doesn't that expose production sites to dangers of
breaking because of what someone did in stage?

You probably have all this figured out, but wanted to see what measures you
took to maintain production stability.

Regards,

Ken

On Wed, Sep 1, 2010 at 3:37 PM, Cornelius, Gregory <gcorne at bu.edu> wrote:

> 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.
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>