Nope, no ant anywhere in that process. No need for it. Aside from the 'svn' commands for merging and stuff, the most complicated command is the sync operation, which takes an optional "-n" flag for doing a dry run to preview what is actually going to be updated.
And really, no one works on the stage branch, about the only thing that ever gets fixed on the stage branch (not the stage working directory, mind you) is typos. Pretty much everything else is done on a branch (often developer-specific), and then merged back in when complete. Lot easier that way. It also has the effect of making the stage branch pretty much exclusively for integration testing, and having the configuration being tested automatically updating itself (necessitating a restart of the test procedure) would be a huge headache. I'm a big advocate of using all the neat tools out there to make your job easier, but I'm an even bigger advocate of NOT using superfluous tools when they're not going to help. I think that's one of the major problems people face these days. Not just developers, but people in general. There are so many tools out there, it takes real discipline to research, select, and understand the tools you need, but it takes just as much discipline to not use the tools you don't need. That being said, I use ant in abundance for all kinds of tasks, but I don't think I build a single software package with it. It's all for server administration and stuff like that. And yes, where appropriate, testing is automated. Still have to test stuff manually though, no matter how good your test framework is, particularly with HTML stuff. cheers, barneyb On 9/14/05, John Paul Ashenfelter <[EMAIL PROTECTED]> wrote: > On 9/14/05, Barney Boisvert <[EMAIL PROTECTED]> wrote: > > My method of choice is typically to have a 'staging' working directory > > checked out on the central dev server, in addition to personal working > > directories for each developer. That staging directory is then > > rsynced up to the production cluster when changes are made. This > > ensures two things: > > > > 1) since no one directly edits the stage working directory, it's > > impossible to push anything live that isn't checked into the > > repository (since that's the only way to get it to staging). > > This is key -- no "just a quick change" on the staging server which > gets missed in source control. Pushing through a process is a great > idea > > > 2) pushes to the production cluster are always from a consistent > > source; no way to push a partial version and get version conflicts. > > > > Basic routine looks like this: > > > > 1) developer makes changes and tests > > 2) developer commits > > 3) I update staging server > > 4) testing on staging server > > 5) tag release > > 6) push to production > > > > Obviously steps 1-4 happen a lot more frequently than 5-6, and 1-2 > > happen a lot more than 3-4 as well. > > I'd suggest giving CruiseControl a shot to remove the manual step 3, > especially since you're already using Ant (right?). Then your staging > server is always current and problems get noticed soon. > > Of course this raises the whole issue of automating the *testing* in > steps 1 and 4 :) > > > cheers, > > barneyb > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:218374 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
