Forum OpenACS Q&A: Development/Production setup - what's yours look like?

I've finally finished getting the initial install of my site up and working with a cvs repository at www.physworx.com on port 80. Thinking ahead, I'll want to have that as the production site and also have another development site.

To do that, I checked out the same code from the repository to a second site dev.physworx.com:8000 (physdev), served by a second aolserver instance and db.

Next, I did a backup of the physworx db and restored that data to physdev db.

Next, I visited dev.physworx.com:8000 for the first time. Interestingly - the page served was the initial install page that said my datamodel was installed and now the tokens needed to be registered, etc. (is that normal? will that happen with every db dump and recover or just because it was the initial install?) I hit next and ended up on the page where all the contacts for the site are defined. Interestingly again, all the contacts were for Seamus! So I changed them all to the site admin and the server was restarted. Now I have an exact replica of the production site to work on (and the correct user has admin privileges - not sure why the installer thought it should be Seamus...)

My plans are to do development work on dev, commit to cvs and then update prod from cvs. Is that a fairly standard course of action? As far as I can tell, the site map and installed packages info are stored in the db. How does one typically handle this scenario:

Production site is humming along with users registering and making use of the site. Dev is doing some interesting work, adding packages, modifying them, changing the site map perhaps. How to get those changes back to prod? Can't dump the dev db and load into prod as the new users and postings and whatnot will be lost. Reproduce all the package installs and sitemap work on prod, then cvs update the files to reflect the work on dev? I guess that ideally, once the prod site is up and being used, the packages and sitemap should remain pretty stable. But then a cool new openACS feature comes out...

How are others handling this? Once I get some feedback, I think I've got everything to come up with some additions for the installation guide for setting up a server to serve over adsl using dyn dns, secure it reasonably, a 'least you need to know' cvs guide explaining how to use a prod/dev environment, and how to set up separate dev/prod environments for a site.

Collapse
Posted by Dave Bauer on
Brad,

Projects I have worked on relied on keeping SQL upgrade scripts. So if you make changes to the data model on development, write a script that will update production to the same state.

Or at least keep a log of steps if you are making changes from the admin web UI.

Collapse
Posted by Jade Rubick on
Also, you can often copy the actual data from production to development. That way, you're using actual, useful data.

The big problem with this, of course, is email alerts. :)

You don't want duplicate or outdated email alerts being sent out.

Collapse
Posted by Don Baccus on
e-mail alerts are no longer a problem - check out the rollout-procs.tcl file in acs-tcl/tcl that Andrew Grumet wrote for Sloan.

It lets you configure what to do with e-mail in your config Tcl file, options which include logging, forwarding to another address, etc.

<blockquote> e-mail alerts are no longer a problem - check out the
rollout-procs.tcl file in acs-tcl/tcl that Andrew Grumet
wrote for Sloan.
</blockquote>

Small aside, but this is slicker than... well, I dunno.  But it's pretty slick.  Thank you Andrew for sharing this.  We've sent spam to real-world email addresses from dev/staging servers during testing one too many times.  It's embarrassing.

Basically, it works by renaming the sendmail command on startup.  Here's the comments:

####################
Rollout support email procs.  These procs help manage differing email behavior on dev/staging/production.

Parameter settings summary:

ns_section ns/server/${server}/acs/acs-rollout-support

EmailDeliveryMode can be:
  default:  Email messages are sent in the usual manner.
  log:      Email messages are written to the server's error log.
  redirect: Email messages are redirected to the addresses specified by the EmailRedirectTo parameter.  If this list is absent or empty, email messages are written to the server's error log.
  filter:  Email messages are sent to in the usual manner if the recipient appears in the EmailAllow parameter, otherwise they are logged.
    ns_param EmailDeliveryMode redirect
    ns_param EmailRedirectTo mailto:somenerd@yourdomain.com,mailto:othernerd@yourdomain.com
    ns_param EmailAllow mailto:somenerd@yourdomain.com,mailto:othernerd@yourdomain.com
####################

Collapse
Posted by Jade Rubick on
Putting this in the default config.tcl file is

https://openacs.org/bugtracker/openacs/bug?bug%5fnumber=692

Bug 692