Vendor Management Strategies for the CIOSoftware 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.
Requires Membership to View
To gain access to this and all member only content, please provide the following information:
By submitting your registration information to SearchSystemsChannel.com you agree to receive email communications from the TechTarget network of sites, and/or third party content providers that have relationships with TechTarget, based on your topic interests and activity, including updates on new content, event notifications, new site launches and market research surveys. Please verify all information and selections above. You may unsubscribe at any time from one or more of the services you have selected by editing your profile, unsubscribing via email or by contacting us here
- Your use of SearchSystemsChannel.com is governed by our Terms of Use
- We designed our Privacy Policy to provide you with important disclosures about how we collect and use your registration and other information. We encourage you to read the Privacy Policy, and to use it to help make informed decisions.
- If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States.
 |
||||
|
|
|||
|
||||
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 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.
This was first published in February 2008