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? > > > --~--~---------~--~----~------------~-------~--~----~ 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 . -~----------~----~----~----~------~----~------~--~---
