Service provider takeaway: Service providers looking to help customers through development projects -- from large-scale enterprise implementations of an ERP system down to small-scale departmental projects -- should consider continuous integration practices, part of the overarching methodology of release management, as a means to save time and money.
Software development projects are notoriously complex undertakings, with many areas of uncertainty and opportunities for things to go awry -- and I don't just mean defects to the software. Integration can be painful, and the more complex a project is, the more expensive and time-consuming it becomes to bring additional people into the loop. The end result is often missed deadlines and exploding budgets for your customers. It's your job as a service provider to mitigate these risks and rein in the project delivery time for your customers.
One emerging practice, continuous integration (CI), can go a long way toward reducing the cost and unknowns of a project. With CI, which is a facet of the release management methodology, team members are forced to commit and test code changes frequently, which translates into fewer implementation unknowns, the ability to quickly fix bugs, forced version control and a consistent working system. Here are the four guiding principles of continuous integration.
Principle 1: Management
To put continuous integration into practice, you'll need to implement a source code management (SCM) system. SCM systems manage the versions or revisions of all pieces of work within your application, constantly tracking changes. With SCM, developers check out different units of work, make their changes and, finally, commit their changes back into the project's "mainline" or current working version.
As part of this process, you'll reach...
To continue reading for free, register below or login
To read more you must become a member of SearchSystemsChannel.com
certain milestones in the project cycle. At these points it is best to tag the code as a specific release. At any point the release manager may request that the project be rolled back to any previous version. This becomes a nonissue if you're using an SCM system.
One of the misconceptions of SCM is that you check only actual code into the SCM system. A proper SCM system should include all necessary files for the project: configuration files for your integrated development environment, third-party libraries, database build scripts and test scripts. A new contributor to the project should be able to check out the latest version of the project and have everything they need to run the system successfully. Two commonly used open source SCM tools are Concurrent Versions System and Subversion.
Principle 2: Automated testing
Automated self-testing of the application is also a critical piece of continuous integration that can be achieved using a tool like xUnit, a family of testing frameworks used in self-testing. A unit test should be created to check the functionality of each new use case. For these tests to work in the automated build, they must be startable from a simple command. Properly defined tests will greatly reduce the introduction of bugs by ensuring that the inputs and outputs of the use case remain the same for all changes introduced to the system.
Principle 3: Automated build
Alongside automated testing, another part of the CI process is to make sure that the system can easily be transformed into a working application. It's essential to automate the build of the system because it's a very complicated process. Building should be as easy as running one command so that all team members can build the system without a problem. When the build is completed, you should have a fully functional system. This includes running any database alterations and all test cases. The failure of any of these pieces should result in a build failure. Automated builds have been done for years using "make," commonly used for C/C++ applications running on the Unix platform. More recently, this build process has been simplified by Apache Ant or Apache Maven, which can read through XML configuration files to build the system.
Principle 4: Reporting server
Once those three issues have been addressed, the project can be considered compliant with continuous integration principles. Frequent builds can be scheduled or developers can manually check out the project and perform the build themselves. However, there are substantial benefits to taking the CI practice one step further. This involves implementing a CI server such as CruiseControl or Apache Continuum to automate the build and report on the results. These servers can monitor the SCM system and upon any changes trigger a build of the system. If any part of the build fails, developers will be notified, prompting for the code to be fixed and recommitted into the repository. These servers can also send notifications to team members that detail who made a recent change and what the change consists of.
By moving to a CI practice, your customers will instantly see savings. Systems integration unknowns won't affect the time to market or bottom line of the project. Integration can occur multiple times a day, reducing the risk of defect introduction and cutting down the time a project spends in quality assurance. New team members can be productive right away, since they will have a working system with the click of a button. Finally, if any release doesn't work out as expected, it can easily be backed out, resulting in a greater user experience.
About the author
Steve Karlovitz is an enterprise architect with more than 10 years of experience in business process implementation, information systems development, instructional design and team leadership. Steve is also co-founder of Synegen Inc., a premier provider of enterprise information technology and business strategy services.
