On 9/15/05, Barney Boisvert <[EMAIL PROTECTED]> wrote: > > That's a surprise -- though it of course depends on what you're doing. > > I don't have many CF projects that don't have at least *some* java in > > them (usually the credit card API) so using Ant seems pretty natural. > > Credit cards? Ick. That stuff sucks. ;) No unhappiness from me that > I have touched CC processing in like 4 years. But anyway. We build > the Java pieces separately. So Java piece X gets built into a JAR, > and then that JAR is included in the CF apps as needed. Keeps the > dependancies flowing downward, and isolates the CF apps from any > changes to the Java apps until they're ready to deal with them.
I'd actually like to hear a little more about how you do that -- if I had to rewrite the JAR for credit card processing for you, it sounds like I'd do that in a branch, approve it, and merge it back into the trunk. Then everyone just pulls down the JAR into their working directory? \yourapp\trunk\java \yourapp\trunk\cfcode or similar in the repository? I'm actually curious :) > > I do a lot with using filter expansion to properly configure > > differences between deployments (e.g. changing the fusebox <mode> > > parameter from development to production as appropriate on the > > specific server). > > We don't use FB4 either. And we maintain our different config stuff > in-code, rather than in external ant properties files, so the app > itself takes care of pulling the right config stuff out based on where > it's at. Most of the reason is so that we can go right from staging > to production with a minimum of steps. More steps == more room for > error, especially if you're CHANGING THE CODE!!!. ;) If we did use > FB4, we'd switch the mode the same way, in-code. <cfset > application.fusebox.mode = "production" /> is just as effective as > changing the XML file, as long as it happens while no request is > actively executing the loader. 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? I tend to prefer abstracting deployment information (dev/stage/prod settings) into external files (source controlled of course) and relying on the deployment script (aka Ant) to handling everything. Of course then you have to add your deployment script to the testing process. It always comes down to deciding where to spend the time/resources :) I find it pretty interesting to see how folks really *do* their development! > > > Wouldn't you have to start the testing process again after any change > > in the branch being tested? A change in the staging branch during > > integration testing *should* restart the unit tests for sure, > > functional if they are automated and reasonable in length. > Yes, expected, and intentionally prevented from interfering. ;) By > doing it this way, developer X can merge his private branch into > stage, switch his working copy to the stage branch, and then make sure > there aren't any issues now that he's back with everyone else. And he > can do it during a testing period, without interfering with the test. > You can make an argument that that's a stupid way to do it for sure, > but having that central point of control sure makes my life easier. Not a stupid way to do it at all -- defintely not the argument I'm making :) I think the key thing you've done is come up with a process that works for your team that involves good practices (SCM, testing, etc). I tend to subscribe strongly to AGILE principles personally, but even there, there are a wide constellation of techniques and practices that are implemented in teams of various sizes and personalities. > > I'm thrilled we're (the CF community) at the point where more of the > > discussions are about how to implement the tools to improve process > > than "why it's important to use source control". > > Amen to that. It's amazing the change that's happened in the past > couple years. Not that that question never comes up, but there's so > much more behind it now. Agreed. I mean, not only this -- but a *frameworks* conference instead of just Fusebox? And *choices* in the CF framework. Wow! Seems to me it coincides pretty strongly with your activity on this list increasing..... :) :) :) > > 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:218446 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
