Ok, it sounds like you got a few additional extensions to the parameters functionality we are adding.
If you are interested in committing these changes to the trunk, there are two ways we can go about it: 1) You can generate a patch of your current changes and send it to us. However since this is from a fairly old release (1.4.2, we're up to 1.4.4 at the moment, with 1.5.0 in the works) it might take us a while to get around to. 2) You could get the latest code from the trunk, merge in your changes and then send us an updated patch. Since you'd already done the hard work for us, we'd be able to merge it faster. We'll still check the code, just to make sure it doesn't break anything else :-) Craig -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of MKCline Sent: Saturday, 9 May 2009 12:00 p.m. To: ccnet-user Subject: [ccnet-user] Re: Corporate Environment - Deploying to various environments That definitely sounds like something that would have made my customizations a bit less. From my understanding there are still a few key differences in the approach I took (although no reason why the trunk build couldn't be extended to accomodate it). 1) A couple of the 'static' configuration parameters (like environment 'DEV', 'TST', 'UAT', 'PRD') are actually sourced from the ProjectGrid.vm template and then stored in the database for that specific run. This was mainly done because the out of the box communication didn't support any sort of parameter passing, which sounds like is available now in 1.5 2) Whenever a 'tag' is created, this builds a new 'deployable version'. 'Deployable Versions' are another propertyset that I allow choosing from. So since my store is the database, it is easy for me to store these and then retrieve them from there. In a ccnet.config storage scenario I would be trying to update values as part of a build. Probably could be accomplished with the xml includes, I'd have to play around with it. The fact that parameter passing also works from CCTray is great and something that because the back-end process didn't support parameter passing, I didn't bother to try to extend the CCTray as well. I don't actually store the parameters in the trunk, but the version # parameters are specific to each build and updated anytime that a 'tag' build is run. My build files for deployment expect a source binary deploy tag and then the environment. Then an entire parameter value set is what is stored in the trunk in source (connection strings, deployment folder, etc)
