[support] Staging
Ari Davidow
aridavidow at gmail.com
Thu Aug 7 23:15:04 UTC 2008
Your development company is correct. There is no professional way to push
changes to a live site directly. It is absolutely dangerous, a recipe for
bringing down your site and/or for destroying live material. Or, as you
complain, things will simply be breaking constantly.
There are many ways to separate the content (e.g., new posts to a blog) from
the database code behind that content.
Any professional development company will do development as you describe it
(sometimes there will be reasons for additional stages). "Dev" is where
structural changes are done; "Test" or "QA" is where new editorial content
is checked (out of the way of development), and where dev is finally tested
before being pushed live. By using virtual servers, one can ensure that each
environment is identical to the live environment (except for dev, which will
often differ radically)
This is tricky, because many database-backed websites don't have good ways
to promote just code changes (and drupal doesn't make it so easy), but it is
critical that, at a minimum, those three functions are kept separate. In the
case of static sites, we often used scripts based on rsync to move changes
from test to production, never allowing humans to log into production. This
is trickier when you have to update/change some, but not all database tables
(which also require more than rsync to stay in sync).
(It is often the case and test and qa are also separate--one used to test
code changes before production; the other for content changes. And, of
course, if there are conflicting dev projects, there may be more dev
instances, or sandboxes, to deal with that variety--but for most of us, that
would be rare.
ari
On Thu, Aug 7, 2008 at 3:22 PM, Christopher M. Jones <cjones at partialflow.com
> wrote:
> I'm looking for a decent approach to staging a drupal site. The
> production site will be a collaborative authoring project, with forums,
> blogs, and lots of media. The client will have access to this site, and
> will be maintaining some of the content. Other content will be
> maintained by us.
>
> The development company that hosts this project prefers to make all of
> their changes, both to content and templates, in a testing environment.
> Once their client has approved the changes, they like to 'push' them to
> production.
>
> However, while these changes are taking place, the client may be
> administering forums and writing blog posts in the -production- version.
>
> To further complicate things, my company wants a three-stage cycle. They
> want a dev site, where they make changes for in-house review, which they
> then push to testing for client review before everything is pushed to
> production.
>
> I'm unsure how to approach this. The site in question has always been
> static html created in Dreamweaver. At some point they started adding
> other things, so now there are two wordpress blogs, and two phpbb
> forums. The forums and blogs presently are excepted from the development
> cycle. They simply appear to be part of the site, because their
> templates have been designed so. But that means that we've got to
> propagate template changes across five templates. Things are breaking
> constantly, and this is why I piped up to them about drupal.
>
> I've seen a lot of discussion about this topic, but I really need some
> hard answers. What should I do?
>
> I've seen the Staging module for 6.x. Is it safe to use? If so, then we
> could use that for the database. Templates could be pushed with rsync or
> svn... whatever. But would this work two ways? Could we sync the dev /
> testing sites to the production site, then sync the other way? Would we
> need to?
>
> Also, I envision using a multisite environment so that all sites share
> the same modules, media, etc, but use different templates.
>
> I desperately need the detailed advice of someone with experience, here.
> --
> [ Drupal support list | http://lists.drupal.org/ ]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20080807/d6be5d34/attachment.htm
More information about the support
mailing list