Apparently GreenPepper’s Accept launched at Agile 2006 as an acceptance testing framework built into a wiki. The idea is much like Fit/Fitnesse, with at least a few differences given that it’s based upon running in Confluence, and it has an open source version and a pay version. You can get a quick look at it in their demo sandbox.
Right now they promise that:
After using FIT for a while, we began to have ideas on how to extend its vision and reach. We looked at the code and we felt that doing a cleanroom implementation would be better.
I’m not sure what those ideas are right now, but it probably doesn’t hurt to have some more options in the acceptance testing tools space.
Sitting in my cube at work at 8:30pm on a Saturday it hit me. I really need to work on my delegating skills.
After catching up on a bunch of todo items, notes, and emails from the past week I delved into an existing problem with one of our projects builds. It involves cruisecontrol and maven 2 and all sorts of problems getting maven to do the checkout from cvs or using the
Anyway the point is I haven’t really delegated out the build box successfully. I’ve talked to at least two of my developers about it, but I haven’t really handed over the reins to anyone. I really like build tools and I don’t want to give them up. Thus I’m at work late on a Saturday trying to do too much.
James Shore posted on the idea that you should favor synchronous integration:
- Run the build on your local workstation and make sure everything builds and passes tests. (This step is optional but helpful.)
- Check that the integration token is available. If it isn’t, wait until it is, then get the latest changes from the repository. The revision control system should automatically integrate (or merge) most changes. If you have any merge conflicts, investigate and fix them manually.
- Run the build. If it doesn’t succeed, you have an integration problem. Consider asking the last people who checked in for help. Start the integration process over when you solve it. (This step is also optional but helpful.)
- Assuming the build passed, get the integration token. This will prevent anybody from getting your code before you’ve proven that your check-in worked.
- Check your code in to the repository. At this point, the build in revision control is unproven. You have to prove that it works before releasing the integration token and letting others get your changes.
- Walk over to the integration machine, get the changes from the repository, and run the build. If it fails, you have a configuration problem: the build only works on your machine. Roll back your changes (revert your checkin), verify that the build works again, and put the integration token back. Fix the problem on your local machine and start the integration process over when you solve it.
- Assuming the build worked, you win! Put the integration token back and celebrate by ringing the bell. You don’t have to, but it adds a little fun and it lets others know that something has changed. I like to channel Monty Python when others do this.
A syncronous build seems to clash with Agile where you’re trying to avoid waste and a lot of waiting around for a syncronization token. Moving into serial mode while you checkin and build appears counter intuitive.
James explains the advantages as:
It is slightly wasteful, because integration is a serial operation and you have to wait for it to complete. On the other hand, with a fast build (ten_minute_build) and a policy of rolling back integrations that don’t succeed, the wait should never be too long.
In practice, synchronous integration is less wasteful than the task-switching and broken builds that tend to occur with asynchronous integration. It’s a much bigger pain to have to lose my flow and switch contexts in order to help somebody else debug a broken build.
I just can’t see the advantage based on my limited experiences on builds with Cruisecontrol. Our teams are not working on really large codebases in general. We’re probably a fairly typical medium size development shop. A larger project might have four developers on it so maybe this would show up in those cases.
Typically developers check in a few times a day and we rarely have merging issues. We do have broken builds every few days, but they’re generally resolved by the developer within a few minutes to an hour. Going to a synchronous build would be wasteful for us.
At a recent team meeting four out of eleven developers missed the meeting. None of them planned ahead of time to miss the meeting, and all of them were a little surprised when I mentioned it to them.
Three of the four who missed the meeting are not collocated anywhere near the bulk of the team. They are on other floors or in other buildings. The one developer who was located with everyone else was simply heads down coding. I’m willing to bet that if all of the developers were located together chances are all but maybe one would have made the meeting. A host of developers walking by your cube is a good reminder.
So colocation is even helpful for team meetings. After I realized we were missing quite a few people I dismissed the idea of trying to round people up and assumed things had probably come up. Running around to another building and another floor for a 30 minute meeting just isn’t worth it. The distance barrier makes it difficult to take action to resolve a simple problem.
Anyway not really that big of a deal, but another little lesson on the value of sitting near your neighbors.