Forum OpenACS Development: Best way to setup dev env for many developers?

Each will need different modules, permissions, data, etc to use.
What's the best setup?

We have the current setup for our existing Java development
environment, and we want to past ACS on alongside it as best as
possible until we can make the final switch to ACS.

| DEV  |  TST  |  STG |  PRD |

DEV (ALL) = e450 with 3 CPU's and 4GB ram. It has Oracle 8.1.7,
Apache, Tomcat, CVS, compiler, developer shell accounts etc.

TST (WEB) = 2x 2 CPU VA Linux Boxes with VA Linux 6.2 = WEB.

TST (APP) = 2x 2 CPU " " " = APP.

TST (DB)  = that same e450 as DEV, just a separate DB. = DB

STG (WEB) = 2x 2CPU VA Linux Boxes with VA Linux 6.2 = WEB

STG (APP) = 2x " " " " "  = APP

DB  (DB)  = e220r 2 CPU 2 GB RAM, Solaris 7, Oracle 8.1.7 (with hot
swap clone e220r for fail over) = STG

PRD = Identical to STG.

DEV = Development, developing and compiling and dev testing before
pushing to QA.

TST = Test, development QA.

STG = Stage, final (sanity check) QA, binary exact duplicateof
Production, good for load testing too.

PRD = Production, eveything live.

We also currently have a temporary test box setup to try to figure
out the best configuration before messing with our main environments.

ACSTEMP = Ultra 10 1 CPU, 1 GB ram, Oracle 8.1.7, ACS 4.2 TCL AOL
Server all on one. Everyone is just doing the basic tutorials and
problems sets on this until we have our Dev environment setup.

On ACSTemp we just set everyone up with a subsite, and full admin
priveleges for their subsite, to load/unload modules, etc.

This is an easy setup, but I'm worrried about code and/or data "cross
polination".

We've considered separate virtual IPs for each developer, and
separate DB instances of ACS, but of course this will be a huge load
on the DEV box that way.

What setup have you all worked with? And/or what would be the ideal
setup in such an environment?

Thanks,

On a single ACS Tcl project, you can get away with 4 or 5 developers all working with the same Dev database, and in fact working in a single shared CVS checkout. This was our standard practice at aD. It's simplicity is a major selling point.

I don't know what happens if you try to run multiple AOLservers from multiple CVS checkouts, all pointing the same database instance and username. I've never tried that, but I suspect it would cause problems. I suspect that if you go with separate Dev CVS checkouts and AOLservers, you'll probably want a separate database username to go with each one.

As far as code/data cross-polination, well, I guess that depends on what it is exactly you have everybody working on. Do have several completely independent projects, that just happen to all be using OpenACS? Or one really big web site, that all those developers are going to be hacking on?

I don't remember how the aD toolkit team did things back in the ACS Tcl days - maybe one of them will chime in. :)

At aD, once they went to ACS Java, both the toolkit team and all the client project developers pretty much had to go to C-style one devloper, one CVS checkout, one database username, because of the need to compile and deploy code - but you're probably already plenty familiar with that. In fact, lots of folks installed Oracle on their laptops, etc., to get their own private and portable development sandbox. This isn't that hard, but it probably means you want to give somebody the job of maintaining some sort of canonical test data set (either an Oracle export or perhaps better, scripts to generate the test data) that developers can easily re-load into their private databases at will, to make it really easy for them to always be writing SQL against realistic data.

One side benefit of having everybody run Oracle, AOLserver, ACS, etc. on their own PCs is everybody learns how to run all that stuff, by necessity. Of course, the disadvantage is that everybody spends time learning to run all that stuff, by necessity... :)

I've never fooled with ACS subsites so I can't say much about how they're useful for development. But I'm pretty sure all the Tcl libraries for each package are sourced on a package level, not package instance (subsite) level, so in practice, you're going to have to give all the developer's site-wide-admin to this single shared ACS Dev instance, let them install and un-install packages, etc.

Also, keep in mind that while it's hugely useful, the nifty "reload all my Tcl library files for this pacakge" link you can click from /acs-admin/apm/ is not 100% equivalent to simply restarting AOLserver. In particular, if you spawn off a detached thread it gets a copy of the Tcl libraries as they existed at the time AOLserver started up, not as they've since been modified. (This is generally a trivial problem as long as you know about it, as explicitly spawning off new threads is not a common thing to want to do, and even with the vast amount of ACS 4.2 Tcl code to source, restarting AOLserver only takes 5 seconds or so.)