This Bamboo customer story is the final of an 8-part blog series about why so many developers adopt continuous integration written by our guest blogger, John Ferguson Smart.
John is a consultant and trainer specialising in Build Automation, Enterprise Java, Web Development, and Open Source technologies, currently based in Wellington, New Zealand.
Continuous Integration for Ruby
Jeremy works in a large company specialized in Linux security and backup applications. This company is a Ruby shop – their applications are written in Ruby on Rails, with the source code is stored in Subversion. These applications include Linux software packages that automatically back up the system to a tape drive. This sort of low-level software is hard to test, as the software package needs to be deployed and installed onto a remote machine before comprehensive testing can be done. However, as with any other software product, automated testing is nevertheless essential for the overall quality of the software.
Jeremy uses Bamboo to automate the build and testing process. His Continuous Integration environment involves both running Ruby builds and tests on Bamboo, and also automated deployment and installation on a remote test machine. To maximize responsiveness and minimize network load, Bamboo builds are triggered by a Subversion hook script set up in the source code repository.
Easy configuration
Bamboo integrates well with languages other than Java, including Ruby on Rails. With a little Bamboo customization, Ruby on Rails can be treated as first-class citizens in the world of Bamboo build jobs. Bamboo does not recognize Ruby out of the box, however. The first thing Jeremy had to do was to add a new “Command” build capability, to let Bamboo know where to find the ruby executable:
Once Bamboo is configured, it is easy to create new Ruby on Rails build plans. Ruby-based build plans differ very little from ordinary ones. The main obvious difference is the use of the new Ruby capability in the Builder tab when you create the build plan:
Testing practices are valued in Ruby circles just as much as amongst Agile proponents in the Java world, and there are is good support for testing in Ruby. Like many other Ruby projects, Jeremy uses Test::Unit and RSpec for unit testing and Behaviour-Driven-Development style functional testing. Both these tools produce HTML reports which the Bamboo build plan stores as artifacts, allowing Jeremy to browse them afterwards.
Integrated reports for Ruby
Jeremy also uses the ci_reporter tool to convert the test results from these tools into a JUnit-compatible XML format, which can be easily understood by Bamboo, providing integrated reporting on test results and durations. The rails_rcov Rails plugins provides code coverage data, and can be integrated into Bamboo via the RCov plugin for Bamboo.
Automated tests are executed from Bamboo in three phases. First of all, unit tests are run on the Bamboo build server, directly on the code checked out of the version control system. The second phase, involving functional testing, is more complicated. The built application needs to be deployed to a test machine, and installed and tested there. This is done using SSH – the software is deployed and the test machine rebooted. Bamboo waits for the test machine to reboot, and then runs a series of functional tests on this machine remotely from the build server. Finally, a series of tests is run directly on the test machine.
Last time we talked about clever tools to optimize Continuous Integration; we hope you enjoyed reading all of the Bamboo customer stories.
What’s your adoption story? Tweet Atlassian or leave a comment below about how and why you adopted CI.