I would probably have reversed the order of those directories, i.e. environment/product rather than product/environment ... and of course, if you use variables which can be easily parsed in some dynamic fashion (i.e. a-name records using ListFirst(cgi.http_host) ) this should make setting datasources and insulating your cross-application includes from the environment, since you should never have includes which are cross-environment. But for instance, something like this in your application.cfm will work with minimal migration issues when moving code from development to live:
<cfset request.product = listfirst(cgi.http_host,".")> <cfset request.environment = listgetat(cgi.http_host,2,".")> <cfset request.relpath = "#request.environment#/#request.product#"> <cfset request.dsn = Replace(request.relpath,"/","_","ALL")> This enforces certain naming conventions, for intance, your test environment now requires a url like [product].test.[ourdomain.org] and your datasources must all be patterned as [environment]_[product] however, once these naming conventions are in place, it's easy to see what belongs to which product / environment, and once your live db's have any required new structural changes, you can simply copy your test environment files directly over your live files without too much concern about naming conflicts or other migrational issues. hth S. Isaac Dealey Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 > I have a question regarding development in general. First, a little > background: > We are a small unit of a Library (1 manager, 2 programmers, 2 technical > support staff) and we only use CF (a bit of Javascript). We develop and > manage the entire Library Web site, much of which is dynamic. Our > servers are maintained by a separate campus department (outside of > Library control), but we have a friendly relationship with this > department. If judged against a standard, our development has typically > been at CM Level 2. And our coding is modular...we use <CFINCLUDE> to > reuse code both within a product and between products. > Development Environment Question: > We have separate production and development environments, but it's not > clearly separated. Because we have access to only one server (and that > is shared with other campus departments), we structure our files by > product and then by production (aka "live") and development (aka > "test"). Here's an example: > /cfdocs/library/ejournals/ - Production side of our Ejournals system > /cfdocs/library/ejournals/test/ - Development side of Ejournals > This is obviously inadequate and undesireable. We'd also like to add a > third level - "backup" which mirrors the production side. We wanted to > get a completely different segment of the server for our development, > but that may not be possible (well, we actually wanted a completely > different server, but that's been rejected out-right). What other > arrangements would be preferable, given our constraints? Should we add > that third level? > Thanks. > Karen R. Harker, MLS > UT Southwestern Medical Library > 5323 Harry Hines Blvd. > Dallas, TX 75390-9049 > 214-648-1698 > http://www.swmed.edu/library/ ------------------------------------------------------------------------- This email server is running an evaluation copy of the MailShield anti- spam software. Please contact your email administrator if you have any questions about this message. MailShield product info: www.mailshield.com ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org
