Continuous integration (CI) in application development has been software pro Manfred Moser’s specialty since 2000. During that time, he’s seen CI usage increase significantly as software organizations see its benefits in enabling continuous deployment, speeding up application releases, keeping a code base maintainable and fostering better communication in software development and management teams.
Moser described continuous integration challenges and benefits in enterprise, mobile, cloud, Android and more in this interview with TheServerSide’s editors.
Moser is founder and owner of the software consulting firm, Simpligility Technologies Inc. At the Oct. 2-6 2011JavaOne Conference, Moser is speaking on “Using Hudson for a lot more than just Continuous Integration.” He will be discussing the Hudson CI server and its uses outside of continuous integration.
[Editorial note: Manfred Moser is unable to make it to JavaOne for personal reasons, but Tim O'Brien will be presenting the session and covering all planned topics.]
TSS: How has the need for continuous integration changed since your entry into it in 2000?
Moser: I think the need is the same; but more people are aware of the need, because they are trying to get releases out quicker. They are also more aware of the importance of communication in the team, so that everybody knows what’s going on. When team members use CI practices, integrating their work frequently, it helps keep your build green and going forward.
TSS: The movement towards continuous deployment has brought attention to continuous integration, too. Why has continuous deployment caught on?
Moser: It’s time to market, the competitive side of things; but continuous deployment also helps a lot with keeping a code base maintainable. If you continuously deploy, each changeset that goes into production is much smaller; therefore, the interruption to production becomes less.
In continuous deployment, you end up with a more stable chain all the way from the development to production. You don’t have that crazy panic mode that some companies get when it is release time; when there’s all this documentation, preparation and all that sort of stuff happening that really interrupts a lot of the process.
With continuous deployment, your information about things is up to date all the time. You have the tooling in place because you do it all the time.
In continuous deployment, it becomes more and more critical that there’s no such thing as a broken build that stays broken for weeks. Gone is the attitude of, “Oh we’ll fix it when the release comes around in a year's time.”
TSS: Are you seeing a difference in approaches to continuous integration with Android developers or micro-device or embedded-device developers versus your traditional group of enterprise developers?
Moser: With Android and iPhone and device development being so prevalent, a lot of people come into development that don’t have an enterprise-level background for development. They don’t even know that something like continuous integration exists. They come from like a static HTML page Web background. They have a huge learning curve ahead just looking at Java or Objective-C and all the stacks to build tools all the way up to a continuous integration server.
[At conferences], I see a lot of people want to do testing and want to go towards continuous integration; but they are totally overwhelmed because they don’t have the background. It is just not there.
Still, CI is slowly getting out there. It’s just going to take time, I think.
TSS: What’s the learning curve for handling the complexities involved with CI in mobile development?
Moser: Things are a bit more complicated in some cases. A lot of the stuff has to happen on devices; emulators have performance issues; and you have to start a lot of things in virtual machines. But it’s nothing that can’t be overcome.
TSS: What technologies and best practices do you use to test your continuous integration work?
Moser: A minimum would be using JUnit of TestNG for normal unit testing, and then moving up the stack into more and more complex testing using mocking frameworks too; sort of like abstractions or dependencies of the network and things like that. You have to run full integration tests that emulate what a user is doing on the user interface.
On a website stack, you would be using Selenium, for example, which allows you to programmatically act as a user. On the Android side, there’s a framework called Robotium that allows you to do [something similar].
You have to find tools that get you really good coverage on the testing side. Then, definitely automate those tests.
Beyond that, you can do other things like static code analysis for common bugs, where you would catch things like the typical NullPointerException that would happen if you don’t look at the various corner cases.
So your best practices are to build a stack of test tools and automate, and then integrate all that stuff into a continuous integration server.
TSS: What are some tips for getting new development team members up to speed on continuous integration testing?
Moser: Let’s say a newbie comes on the team and doesn’t know the coding guidelines and standards. You could set up custom rules and various checking engines, like Checkstyle or PMD, which would automate to some extent the whole code review process. Then you could concentrate on mentoring that new person on the higher level stuff.
TSS: What problems happen in the build queue in cloud environments?
Moser: If you have it configured to save every old build and every old artifact, you quickly have big storage [build up], and you might not need that [many artifacts in storage]. You might just need the last artifact and then maybe some for the releases, so you want to make sure you keep an eye on the space usage and stuff like that. That’s a general thing you want to do but on the cloud it becomes more urgent because you are paying for it directly rather than upfront for hard disc. You’re paying for it regularly.
TSS: What’s your advice to organizations that haven’t gotten into continuous integration yet?
Moser: Try CI, because it has tremendous benefits. Even if only two or three developers use it, it’s worth it. I can’t imagine doing any software development beyond one developer without CI anymore because it makes such a big difference in quality and speed. The barrier to entry is so low that you really should just go and do it.