Steven has posted 36 posts at DZone. View Full User Profile

Disable the automatic mails and get a token

01.31.2008
| 2917 views |
  • submit to reddit

Some time ago our project was slowly but surely getting into trouble. At that time we had already spent the two previous weeks on fixing our tests. That weeks promised to be more of the same. We realized that if we would continue like that, we would miss all our deadlines and would be unable to implement and test new features.

What happened? I guess it's a classic problem. Developer A commits changes that break the build. Developer B commits some time later. By the time somebody looks at the problem to many changes have been committed to easily spot the problem. This is not true for all errors, but it is true for some.

Sure, we're using Subversion and continuous integration but these didn't help us very much. Not because they're somehow broken. Our way of working was broken.

So we decided to get a dog to solve our problems. Enter Murphy. Murphy is a cute little dog that we use as our token. Whenever someone wants to commit he or she has to get hold of the token. After committing the token can be passed to another developer.

If Murphy's new owner detects that the last build in CI has failed Murphy is returned to his previous owner, and all commits are off. When the developer corrects the problem and CI is green again we just continue as if nothing happened.

It may seem that this way of working is troublesome. First, you introduce a lock. Other developers have to wait until they get hold of the token before they can commit their changes. We have seven developers so its OK for us. And the concurrent commits is exactly what we wanted to avoid. I've seen a similar token being used on a project with 30 developers.

But they were all in the same room, so are we. We haven't tried our token system with a remote team. And obviously it wouldn't work. Then again, since Murphy started to help us out we've become much more productive. The build has been broken on several occasions since we use our token but was also immediately fixed.

We've turned off our automatic CI mails. Instead we're using a system tray icon that indicates the status of the latest build. Every developer in our team now gets a fair chance to fix the problems he or she creates. All developers share responsibility to keep the build working. And our progress is as we want it to be.

Thank you Murphy.

Published at DZone with permission of its author, Steven Devijver.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Bodo Tasche replied on Thu, 2008/01/31 - 7:15am

That's not a very intelligent solution for huge teams.

 Try Teamcity. The commit gets into the SVN only after Teamcity verified that the changes will work and all tests are ok.

Simple, easy and better that a stupid dog on your desk :)

Steven Devijver replied on Thu, 2008/01/31 - 7:30am in response to: Bodo Tasche

Troggan, your comment doesn't add any value or insight and is passive aggressive.

I clearly said that the "stupid dog" works for our small team and that it's not proven for remote teams.

And since I assume you haven't tried "the stupid dog" you're in no position to make any judgment on how it compares to Teamcity.

Frankly, your comment is lame and I'd appreciate it if you defer from ever making such comments on DZone again.

Bodo Tasche replied on Thu, 2008/01/31 - 7:48am in response to: Steven Devijver

We tried something similar to that a few years ago (we used a blackboard). It didn't work.

Please try teamcity and look for yourself. It's much easier to work with it. If you make a commit that breaks the project, you will get to notice it very soon because teamcity will tell this directly after you tried to commit it. The SVN is never broken again because your code will only be commited if the code is okay. 

Steven Devijver replied on Thu, 2008/01/31 - 7:53am in response to: Bodo Tasche

The SVN is never broken again because your code will only be commited if the code is okay.

So? That doesn't add any value for us. Sometimes we have to commit changes that knowingly break the build, like important changes to our domain model or other changes. And it's free.

Don't get me wrong, I like Teamcity and IDEA product in general. But Teamcity is not nec plus ultra, at least not for small teams. Besides, if you have a big team you have other problems like the reasons you have a big team.

Bodo Tasche replied on Thu, 2008/01/31 - 8:13am in response to: Steven Devijver

Teamcity is free, too :).

 Our rule here (100+ Developers) : never ever commit stuff that breaks the build. If you want to do that, make a branch, make it build and than put it back to the trunk.

Steven Devijver replied on Thu, 2008/01/31 - 8:53am in response to: Bodo Tasche

Our rule here (100+ Developers) : never ever commit stuff that breaks the build. If you want to do that, make a branch, make it build and than put it back to the trunk.
You obviously don't do that very often.

Navneet Karnani replied on Thu, 2008/01/31 - 8:58am

The moving token essentially means each user locks the tree and does not release it until he is done. This can be done by doing exactly that using svn admin.

The whole idea behind using svn, cvs, etc is to do simultaneous development. And CI is a good way of doing it.

The problem is essentially related to the process and not a tool thing. For some setups, CI works as designed, for some it does not.

We use ClearCase at work and the strategy is as follows:

- every developer works only on a private branch. 

- daily merges from the trunk to the private branch are the developers responsibility.

- developer continues to checkin stuff to the private branch for the life cycle of the development of the module/feature/deliverable

- when ready for delivery, developer does a final merge from the trunk to the private branch, does a build and some sanity tests.

- when done, the developer merges code from the private branch to the trunk

 - the key here are: since everyone is continuously working with a private branch, the chances of breaking are small. Since the merges to the trunk are not a very continous activity, generally a conflict situation does not happen.

Hope this helps.

Bodo Tasche replied on Thu, 2008/01/31 - 9:02am in response to: Steven Devijver

[quote=sdevijver]
Our rule here (100+ Developers) : never ever commit stuff that breaks the build. If you want to do that, make a branch, make it build and than put it back to the trunk.

No, i do that on a weekly basis. It doesn't take long.

See http://svnbook.red-bean.com/en/1.1/re07.html for details on how to create a copy with only one single svn command.

Steven Devijver replied on Thu, 2008/01/31 - 9:06am in response to: Bodo Tasche

Our rule here (100+ Developers) : never ever commit stuff that breaks the build. If you want to do that, make a branch, make it build and than put it back to the trunk.
No, i do that on a weekly basis. It doesn't take long. See http://svnbook.red-bean.com/en/1.1/re07.html for details on how to create a copy with only one single svn command.

For me, strategies that are based on merging are broken. Maybe this is different for big teams that work on products. For small teams, when dealing with big chances merging makes you loose far more time than you would gain with working on the same trunk.

Branching is an option if porting back changes is done prudently. And sometimes branching and merging can't be avoided.

Bodo Tasche replied on Thu, 2008/01/31 - 12:25pm in response to: Steven Devijver

[quote=sdevijver]

For me, strategies that are based on merging are broken. Maybe this is different for big teams that work on products. For small teams, when dealing with big chances merging makes you loose far more time than you would gain with working on the same trunk.[/quote]

But that is an industrie standard. Go out and beginn to talk with other developers. If you get used to branch and merge, you will see that it doesn't take time. You will need more time to figure out what is wrong and who made the mistake, go to his desk and put the dog on his desk than to merge your changes with the trunk.

I do that even in a 3 developer team. It makes live easier. We don't have a token. We don't have to talk about who does what when. We simply work and merge. At no time the SVN is broken. Never.

Jeroen Wenting replied on Wed, 2008/02/06 - 5:36am

if you'd not turned off those CI emails you'd have been notified by the CI system whenever a build fails, complete with where it fails.

And most such systems will happily display the commit information for the batch the CI run was triggered by, thus show who's responsible for the failure...

Seeing your name flashed in red across the screens of all team members a few times is usually enough to stop people from committing broken sources (though just making sure things build isn't always guaranteed to make them build under CI, system settings can mess things up still).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.