This post originated from an RSS feed registered with Java Buzz
by Alex Tkachman.
Original Post: Introducing the Build Server
Feed Title: Dmitry Jemerov's Weblog
Feed URL: http://www.jetbrains.com/rss.xml
Feed Description: IntelliJ IDEA Developer, JetBrains
One of the major new directions for IntelliJ IDEA 6.0 “Demetra” is teamwork support, and the build server is one of the key components for that. The build server is designed to replace tools like CruiseControl, and to provide continuous integration and automated build services for teams.
Sounds boring? So it does to me… I’ll leave the detailed description of the features and competitive advantages of our build server to our marketing guys (and girls), and provide instead the things that are more interesting for developers – project background and pretty pictures. For now, the Demetra roadmap should give you an idea of the features we plan to implement.
As it usually happens at JetBrains, one of our main motivations for starting the build server project was the desire to ease our own pain. As the Demetra development was beginning, we found ourselves with three branches of parallel development (IDEA 5.0.2, IDEA 5.1 and Demetra) and three sets of unit tests that we needed to run on each build. And this does not include the nightly release build that also needs to be run for three branches. With the system we were using previously (a separate machine running CruiseControl for every set of tests), we would have needed nine or ten machines to run the continuous integration and builds. Obviously, this is quite a pain to maintain, and we quickly became interested in a solution that would allow us to distribute all these builds between a smaller number of machines.
The new build server allows to install build agents on any number of available machines, and automatically distributes the builds between the agents. Builds can be triggered by different events, for example, by source control checkins or by timer. If many agents are available, it’s often possible to start running tests for a new set of changes while tests for previous changes are still running, and thus to get faster failure notifications.
The picture above is a screenshot of the Web interface of our build server. We’re using AJAX extensively to provide a constantly up-to-date view of the build status. The progress bar actually moves to reflect the build progress, and failed tests are immediately displayed on the page.
Another big motivation was the desire to reduce the clutter caused by build notifications. Previously, the CruiseControl build notifications were sent by e-mail to every user on the team. The e-mails quickly filled up mailboxes, and it was quite hard to understand quickly from a failed build e-mail who was responsible for the failure and what exactly was the problem (some new failure or an old problem still not fixed).
The new server allows sending notifications by Jabber messages, and tracks the difference in test status between consecutive builds (which tests started to fail in the last build, and which were and still are failing). The plugin for IntelliJ IDEA also makes it very easy to see the details of the tests failing on the build server, and navigate to the failure locations. (Notice that the test tree is also updated live – on the screenshot below, the last test is still running.)
Of course, the IDEA plugin also provides a summary view of the build status, so that you don’t need to switch to your Web browser to see the current state of the builds.
We’ve been using the build server exclusively for our continuous integration for a few weeks now, and the release builds were also recently switched to the build server. Of course, the switch did not require us to rewrite our build scripts – we’re still using the same Ant build files partially generated from the IDEA .ipr file, and we only needed to make a few tweaks to enable running the builds in a distributed environment. But only during the past week enough work was put into the user interface to allow me to write this post, with all the pretty pictures in it.
This is just a brief introduction, and it doesn’t even cover all features already implemented in the build server (like changes browsing, artefact management or build number management). If you’re curious to learn more, stay tuned to this blog. Or better yet – come to JavaPolis next week, and watch the live demo of the build server and other IDEA features given by Max Shafirov and Mike Aizatsky, the project managers of IntelliJ IDEA.
Previous Topic
