nice discussion folks. danke. planning to use ANT here for sure. Getting my hands durty in it lately. We are going with tagging the trunk with each release, bug fix or major. major releases would get a branch, but get merged back to trunk before release as bug fixes get added to the main trunk eh? Mergin a branch can suck though.
I have been reluctant to just check out and run updates to get the changes in a staging area so far, guess I can create a special staging suer in CVS for this, we have two folks managing the code. DK On 9/15/05, John Paul Ashenfelter <[EMAIL PROTECTED]> wrote: > > > I don't understand how that's fewer steps. If you're developing (in FB > > > for this example) and you have <cfset application.fusebox.mode = > > > "production" /> somewhere in your code, you have developers pull that > > > down and change it to "development" while they're working. Someone > > > inadvertently checks that back in with other changes and it rolls > > > out... Or you have to add a step to verify the setting is correct. > > > What am I missing? > > > > You missed the "we maintain our different config stuff in-code ... the > > app itself takes care of pulling the right config stuff out based on > > where it's at" part. Probably wasn't too clear, but like how with ant > > you can specify a specific properties file to read based on where you > > generate the code from (dev.properties, production.properties, etc.), > > we do the same thing, but it's all in-code. So the app intelligently > > switches the config parameters it needs based on where it's installed, > > rather than having to ensure that the install location matches the > > build location. > > > > In particular, this lets us sync from staging to production, rather > > than having to use some (potentially troubling) build process, and > > then upload code into production that has NEVER BEEN TESTED. > > Theoretically, the only thing that will be different from the staging > > code is whatever properties, but it's still different code. By making > > config selection changes (rather than rewriting) I have a lot more > > confidence that the code is identical. Stupid distinction, and I've > > never had ant do anything untoward as part of it's filtering process, > > but you remove the potential problem spots wherever you can. > > Potato, potatoe :) > > You've checked that the code pulls the value from whereever it lives, > but you're just trusting that you've got the right configuration where > you deploy it since it's never run w/ those value. I agree, pretty > minor distinction > > Testing can make people crazy -- if your code was something like > (conceptually) > > if thisMachine(production) > myDb=proddb > else > myDb=testdb > > and you test it on your dev machine, you'd have failed to cover one of > the two possibilities from a code-coverage perspective. But if you > move it to a single piece of code > > myDb=getDb(thisMachine) > > you've achieved testing coverage of that line of code. Now it's a > configuration issue, not a code issue if something breaks. > > > > > cheers, > > barneyb > > > > -- > > Barney Boisvert > > [EMAIL PROTECTED] > > 360.319.6145 > > http://www.barneyb.com/ > > > > Got Gmail? I have 100 invites. > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:218465 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
