LAS VEGAS -- Adopting continuous integration is an excellent way to keep development teams working smoothly and...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
avoid defects, according to Agile coach and speaker Jared Richardson.
Among the many teams Richardson has observed, "CI was the one common thread among teams that consistently hit their deadlines," he said at last week's Better Software conference. "Teams that had CI and ignored it were always in this crisis mode."
Richardson, who works for the 6th Sense Analytics company, gradually introduces CI to development teams, he told the audience during his session, "Continuous Integration: The Cornerstone of a Great Shop."
Continuous integration adds transparency
The main features of CI, explained Richardson, are that CI watches builds and tests and notifies.
"CI watches everything you do," he said. "CI watches your code, watches the builds, and watches the tests."
Notifications are another important attribute of CI. "If you put CI in place, you'll get an email five minutes later telling you what went wrong," he told the audience. "Night builds won't break anymore."
When builds do break, though, Richardson finds that these can be useful lessons for the programmers, especially when the breaks are made public. "[Developers] have big egos," he said. "What we can do is take the build failures and mail them out to the whole team and harness that ego for good."
Email and LCD monitors that clearly display build fails can be used to essentially embarrass developers into fixing their mistakes. "How long do you have to wait to fix the build before we start teasing you?" he asked.
CI is like good coffee, said Richardson. In the same way that a person who gets used to drinking good coffee cannot go back to drinking regular coffee, a developer who is used to CI and its benefits cannot go back to a process without CI. "Transfer to a team without CI and it's going to kill you," Richardson warned.
CI is an entire system, Richardson said, and is not "homegrown." Those interested should look to available systems, which are tested and fully featured, rather than trying to "grow" their own, he cautioned. CI systems are available for free or commercially.
Features and requirements of CI
Among CI's features are its ability to handle multiple supply chain management (SCM) processes, to run build systems such as Maven, Rake, and Ant; to understand frameworks such as JUnit and NUnit; and to publish to email, the Web, and instant messaging tools.
The requirements of CI are beneficial to projects, explained Richardson. For one, CI forces code management, "which less than 5% of shops actually do," he said. CI requires automated builds. "Start with manual, then automate it," advised Richardson. He recommended using Ant, Rake, or Maven for this process. Additionally, integrated development environments should be avoided. "If you require an IDE, you have hobbled yourself," cautioned Richardson.
A clean machine is necessary to practice CI. Strive for a production environment, and don't use a machine that's a development box, a test box, or a workstation. Richardson recommended practitioners "get a Dell or a Mac Mini" to use as a clean machine.
Test automation is another requirement of CI, according to Richardson. Practitioners can use BAR (binary, automate, and rebuild) tests to achieve automation. "The test needs to run when you're at home in bed," he told the audience. The tests must also be repeatable and consistent. Besides being a requirement, test automation is a benefit of CI, explained Richardson. He stressed how convenient and freeing test automation is for a team.
"Do you like living in the debugger? Test automation is how you get out of that," he said.
Working in a known state, receiving group change notifications, sharing a public log, using statistics, and obtaining fast feedback are a few of the other benefits CI offers, said Richardson. Fast feedback is particularly helpful, as it allows programmers to correct their own mistakes while the code is still fresh in their minds, he added.
"In a CI system, the person who writes the bug gets to fix the bug," explained Richardson.
A slow approach is often best when it comes to CI adoption, Richardson said. He favors a "grassroots" method whereby team members become acclimated to CI and its benefits, much as a person becomes acclimated to good coffee.
"Pick one project," he advised, "and run [CI] for a week. Just fix things and start sharing."