Many software engineering organizations are implementing continuous integration as part of a move to agile development techniques. Organizations commonly start by using one of the open source continuous integration tools, such as CruiseControl, but quickly find that they require a lot of extension to meet the needs of a large enterprise.
This whitepaper explores the challenges of continuous integration in the enterprise and looks at the characteristics of an Enterprise CI tool.
Challenges and Characteristics of
Enterprise Continuous Integration Challenges and Characteristics of Enterprise
Continuous Integration Many software engineering organizations are implementing continuous integration as part of a move to agile development techniques. Organizations commonly start by using one of the open source continuous integration tools, such as CruiseControl, but quickly find that they require a lot of extension to meet the needs of a large enterprise. This whitepaper explores the challenges of continuous integration in the enterprise and looks at the characteristics of an Enterprise CI tool. Introduction Many companies build their software at most nightly and frequently only when a release is imminent without realizing that they are putting themselves at risk of broken builds seriously impacting release dates and software quality. Thanks to books like "Continuous Integration: Improving Software Quality and Reducing Risk" development managers have begun taking action to make their departments more build efficient. Nightly or weekly builds are no longer good enough. Developers have thrown down the gauntlet forcing build engineers to produce reliable builds as soon as changes are made. Before describing the challenging environment in which build engineers work, we'll take a look at the foundations of the continuous integration movement. How did it start? Where did it come from? And what happens when companies start treating their builds as a precious commodity? What's all the hub-bub? It was common for teams to spend weeks, months, or even longer, verifying that their applications worked just prior to releasing them. That time spent "integrating" was frequently torturous. Developers would have to track down bugs introduced months in the past. An enormous amount of time was wasted trying to merge incompatible changes from different developers leading to integration storms of constantly broken builds and software. A good version control management system might shed some light on the nature of bugs encountered during integration, but frequently fixing these integration incompatibilities was a wild goose chase. The search was made more difficult because not everyone provided good commit comments. Often developers had simply forgotten what they were working on months before. The answer to this painful period in the software development lifecycle is continuous integration.
Challenges and Characteristics of Enterprise Continuous Integration Page 2 Continuous Integration (CI) dictates that as soon as changes to an application are available, they are integrated with everyone else's changes and run through a rigorous build and test system. The types of changes being considered include modifications to code, environment reconfigurations, database schema migrations, updated versions of third party dependencies, operating system patches: just about anything that might impact a running application. Any changes to any part of a software product might mean that the application no longer works as expected, so it needs to be tested immediately. Forward thinking build engineers began downloading the various continuous integration implementations, such as CruiseControl, well before their managers were clued into the advantages. Typically, a covert installation on a spare machine tucked under a developer desk started making their lives easier. A grassroots push for continuous integration began to spring from one person knowing almost instantly when another team member had neglected to commit a new file. Once the enlightened build engineer revealed their secret CI machine to the rest of the team, it usually spread like wildfire. Now team members could monitor a simple web site to determine if they had made a mistake. Instead of test suites being pushed to the side and forgotten, their tests were being run continuously to verify the build. Developers started to feel good again about "builds". As teams and applications grow over time, many enterprises find themselves with CI servers spread across the company - in labs, under desks, etc. And often, conflicts arise over who owns what - does IT own the servers or are they the sole do... [download for more]
