This post originated from an RSS feed registered with Agile Buzz
by Jared Richardson.
Original Post: Continuous Integration question
Feed Title: Jared's Weblog
Feed URL: http://www.jaredrichardson.net/blog/index.rss
Feed Description: Jared's weblog.
The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers.
We recieved a question from Jerome about how Continuous Integration works in the real world.
Regarding 'Continuous Integration' : building our application takes about than half an hour. Your book mention that after each commit, the Continuous integration system should start a build to make sure the commit didn't break it. I wished your book would mention if this would be a problem : starting a long build after each commit. What would happen if several commits occur during a build ?
No problem at all Jerome! In fact, all the CI systems I've every used plan on this happening. The system will store up the changes that are committed during the current build. Then all those changes are bundled into the next build.
For instance, if there are three developers, Joe, Fred and Mary, and Joe pushes code, a CI build will start. While the build is running, both Fred and Mary commit code. When Joe's build is done then Fred and Mary's changes will trigger a CI build.
Regarding the suggested Issue Trackers (Appendix E) : as you are suggesting Subversion as a source control system and emphasis the fact that the issue tracker should interface nicely with the source control system, why don't you suggest Trac as it natively interfaces with Subversion ?
I wasn't familiar with Trac. I've added it to the online resource page. Thanks for the suggestion Jerome! btw, I also added RT at the suggestion of another reader!
Previous Topic
