> > 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:218460 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=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
