The practice of continuous integration (CI) can serve as a catalyst for change in development organizations --...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
and not just those that have already adopted an agile methodology, according to Kirk Knoernschild, an analyst at Burton Group and author of the recent report "Continuous Integration: The Project Heartbeat."
While continuous integration -- an automated, repeatable build process that produces functional software on a frequent and regular basis -- is associated with extreme programming (XP), Knoernschild said it can be applicable to any methodology. "Ideally, the agile method is preferred, because you write code earlier in the lifecycle and you get all the advantages surrounding it," he said. However, he paraphrased an old industry saying in adding that "software projects don't really start until the first line of code is written anyway."
"Even in a waterfall methodology where you might spend three months gathering requirements and a couple of months designing, with continuous integration you don't change the upfront process much," he explained. "But the minute you write the first line of code, you send it through the automated build process and you've got a system that can be tested."
This enables testing to move up earlier in the lifecycle, and "that can catalyze a transition to increase agility," he said, "I often look at CI as one of those agile practices that can serve as a foundation for a grassroots effort to increase agility in an organization or development team."
James Shore, consultant, co-author of The Art of Agile Development and signatory number 10 to the Agile Manifesto, said one of the biggest advantages of adopting CI is that it "exposes the difficulty of integration," which is "a much bigger piece than people realize." By integrating continuously, he said, development teams better understand what the costs are and can spread them out over the project rather than facing a large unknown cost at the end. Teams can also better predict when a project will be done.
Knoernschild considers CI a mature practice, and his report cites that adopting continuous integration helps reduce software development risk, reduce costs, improve quality and speed delivery. Also, he wrote, "teams that allow continuous integration to feed other software development activities are able to realize additional rewards."
Continuous integration adoption slow to catch on
Despite these benefits, continuous integration has still not caught on widely, he said. "I believe there are some teams and some pockets in organizations that practice continuous integration, but even today I don't believe there has been a widespread adoption of the practice."
There are two primary reasons for this. First, Knoernschild said, "it involves a commitment to create that type of environment where you have an automated and repeatable build, and because of the investment required I'm not sure all organizations believe in its value to the lifecycle." Second, he said, there are cases where teams adopt continuous integration but then don't leverage the strategy behind it -- software that works, or a software system that's always in a functional state -- to help increase and drive collaboration with the users.
He acknowledged that adopting the practice of CI takes work, and some investment in time and resources, so there are some hurdles to get over.
One is getting the necessary infrastructure components in place, such as tools for software configuration management (SCM), version control, a repository and so on. "Initially, as teams go through setting up an automated environment, the time it takes will possibly detract from the short-term gain in terms of implementing features in the product," Knoernschild said. The long-term investment of using CI, he said, is that teams can ensure they're moving along the right path as they move through the software development lifecycle (SDLC).
Other obstacles to adopting continuous integration are the frustration factor and the perception that velocity is being dragged down. "Failed builds can be frustrating for the development team; it requires a change for how people work," he said. "Continuously integrating code might give the notion that you're not moving as fast, but with CI, issues tend to arise as soon as they manifest in the application, so they arise earlier. The appearance may be that you're slowing down, but in reality you're bringing more significant issues forward earlier. You're mitigating risk earlier."
And once an issue with a build surfaces, developers should follow the "golden rule" of continuous integration, Knoernschild said: fixing the problem must be the developers' top priority. The golden rule is "there to support the prime directive [of CI], which is to ensure the system is always in a functional state." Adhering to the rule ensures that "you don't allow problems to fester in the system for a prolonged period."
Knoernschild said he's seen developers who violate the rule once or twice, and the consequences are relatively minor. But over time, if a team continues to put off fixing issues, "the problems surrounding not adhering to the rule exacerbate, and what happens is teams will abandon the continuous integration strategy because it's not providing the advantages they hoped," he said.
Shore said the problem can be that teams take a tools focus rather than embracing the underlying philosophy of CI, which is "having software be potentially shippable at all times from a technology perspective."
"You can use tools to accomplish this, but it's only the tip of the iceberg. You really want to make sure integration succeeds before you move on to the next task," Shore said.
Developers can be tempted to move on and let someone else deal with an issue if the build takes too long, Shore said. He recommended minimizing the use of system tests and utilizing unit and focused integration tests to keep the builds fast.
While adoption of CI requires some effort, Knoernschild said it's an "important and proven practice." He added, "It would be wise for software development teams to invest some time and energy into building their practice internally."