Configuration settings in a database is a no-go. It's gotta be a simple text file, either XML or in INI format.
On Apr 22, 11:40 am, Fernando Lopez <[email protected]> wrote: > Interesting question > we are working on a project where we found the same issue. > > We use ANT to deploy things to Dev Test and Prod, we are brand new to the > whole process so we didn't want to get too fancy with ANT. > We didn't want to change CS or any XML file for Dev/Test or prod either. The > deploy script we have is not very smart, check things out from CVS and then > move them to Dev/test or prod. It doesn't even reload the app if we change > something on CS, again I said we are new to ANT. > > So we ended up with a nice solution, created a CONFIG table in the > application. > > The table has two columns Config_name and Config_value > Some of the values we have there for config_name are > > applicationPath > BizServicesEmail > ConsumerAffairsEmail > FailedRecipient > systemErrorRecipient > xmlErrorRecipient > > then we created a small service that only gets us the values from the table > and we can use the values on the application without changing the code or > changing config files in the different environments > > a call to get the recipients for an email would look like this > > <cfset emailRecipients > =variables.appConfigService.getappConfigValue("FailedRecipient") /> > > From there you can use the value on your code as you please. > > Just this morning I got a ticket asking to add a new person to the > notification list when a transaction fails. > > Just went to the database and updated the record for "FailedRecipient", > didn't have to change XML files, didn't have to deploy anything back to > prod, didn't have to worry about initializing the application again, it just > worked. > > I'm not saying this is the final answer to your problems but just another > idea that we found very simple and easy to implement and support. > > Fernando > > > > On Wed, Apr 22, 2009 at 10:10 AM, Doug Hughes <[email protected]> wrote: > > Al - > > > I think you're headed in the right direction. Essentially, what you're > > saying is that your configuration settings need to change in your ColdSpring > > XML as you deploy from development to staging and production. > > > The way we tend to handle that at Alagad is to keep the development version > > of ColdSpring.xml in our SVN repo. So, the developers would always use the > > development version of the ColdSpring config. (There are gradiations on > > this, but they're not really relevant to your question.) > > > We then automate the deployment process to staging and production using > > Ant. As a part of the deployment process we modify the ColdSpring > > configuration to use our production settings. > > > So, for example, if we had a component for sending email we might have two > > objects configured in coldspring, an EmailSender and a MockEmailSender. In > > development anything that needed to send email would use the EmailSender. > > When we deploy to staging or production we might replace instances of the > > MockEmailSender with EmailSender. Actually, in all honesty, I simply don't > > configure the mail server in development and look in the undeliverable mail > > folder to make sure messages are getting created correctly. However, there > > are other instances where settings need to change between development and > > staging or production and we use Ant to make those settings. > > > In particular, we tend to use CFAnt as a part of our Ant deployment process > > so we can make settings changes to the ColdFusion server as well. For > > example, we can configure datasources, turn on trusted caching, clear the > > template cache, configure event gateways, start them, etc, all from one > > script. And, because it's Ant, running it from Eclipse is really, really, > > easy. > > > I hope that helps! > > > Doug Hughes, President > > Alagad Inc. > > [email protected] > > 888 Alagad4 (x300) > > Office: 919-550-0755 > > Fax: 888-248-7836 > > > On Wed, Apr 22, 2009 at 9:46 AM, Al <[email protected]> wrote: > > >> I'm wondering how people manage differing configuration settings for > >> the same app in different environments. > > >> Let me expand on what I mean. > > >> We have three tiers of servers: DEVELOPMENT, TEST, and PRODUCTION > >> (hereafter D, T, P). For each of our applications we will have > >> settings that vary based on environment. For instance, we may have a > >> "test e-mail" to trap any outgoing e-mail and re-route it to the > >> address in the setting rather than letting it go to the actual > >> recipient. (Helps prevent messages being sent to live people from an > >> app being tested.) In D that would probably be set to the development > >> team, in T it would be set to the test team, and in P it would be > >> NULL. Every app has a couple or half-dozen such settings. > > >> In the past, MG1.1, I'd create three separate ModelGlue.xml files and > >> they'd each have differences in their CONFIG blocks, but everything > >> else would be the same. (They would be renamed to ModelGlue.xml on > >> each server during deployment.) That worked okay, but it meant that > >> whenever an event-handler or message-listener got changed, I'd have to > >> change three files. Not the end of the world, but we did have cases > >> where people with less attention to detail forgot to change the > >> production version, for instance. > > >> I then started using GetModelGlue().GetConfigBean() and having only > >> one version of ModelGlue.xml and a config.xml for each of my three > >> environments. A little more work, but I only had to change all three > >> if I was adding a configuration setting; the application plumbing was > >> just the one file. That works much better. > > >> However, I'm now forging ahead with developing using MG2. > >> Configuration settings are in Coldspring.xml. That's fine, but I'm > >> also looking to leverage Coldspring's power to define my components. > >> Obviously, they'll be the same no matter what environment the > >> application is in, but the config blocks will have to differ. This > >> puts me back to the same basic problem I had with the versions of > >> ModelGlue.xml for each environment. > > >> So, before I go too far down the rabbit hole, what do other people do > >> to manage multiple configurations of a single application?- Hide quoted > >> text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en For more about Model-Glue, check http://www.model-glue.com . -~----------~----~----~----~------~----~------~--~---
