ANT is, unfortunately, not currently an option. (I'm trying to get us there, but there's only so fast I can turn this ocean liner, and I'm not the only one at the wheel.)
Is there a way to import information into Coldspring.xml? On Apr 22, 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 . -~----------~----~----~----~------~----~------~--~---
