On 8 Nov 2008, at 02:30, David Chelimsky wrote:
On Fri, Nov 7, 2008 at 8:53 PM, Josh Knowles <[EMAIL PROTECTED]>
wrote:
Next step ....
Write a post commit hook to fire a message off to your build machine
and have it run all the scenarios and email you the results. Sometimes
everything will just pass. Sometimes you'll know you have new work to
do.
Any takers?
And if you can train the business folk to make changes to their own
branch (or maybe give them all their own forks - might be simpler) ...
man - this opens up a ton of opportunity.
I've been thinking about this a lot.
Assuming you have a stakeholder who can check changes to feature
files, you're going to get a borked build sooner or later - it's
unlikely they'll change requirements and the code will magically
adjust itself! (not for a few years anyway!)
I guess like you say (and I hadn't thought of this) the right idea is
to get the stakeholder to check in their changes in a different branch
to the one in which the developers are hacking on the actual changes.
That way you can have a build on the stakeholder branch which is often
broken, but the breakages are like a 'todo list' for the developers -
it's basically your WIP. And you can have another build on the
developers' branch which is sacred and people get the usual
punishments for breaking.
I think there's a nice synergy to be had here between cucumber, git
and cruisecontrol.rb that will help you have a really lean workflow.
Very interesting.
cheers,
Matt
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
