Q
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

How to select the right build tool for continuous integration

How important is the build tool when maximizing the benefits of continuous integration? In this expert response, Kevin Parker recommends considering how well a tool can be integrated into the development process through automation.

Can any tool that does builds be used to do continuous integration, or are there special features that need to...

be present in the tool to accommodate continuous integration?

Continuous integration is the flywheel of Agile development methods. It maintains the cadence of the team. It drives behaviors in quality, configuration management and project planning that orient the team on results and desirable task outcomes.

Although it is critical, it is not the build tool itself that makes continuous integration possible. As with all that we do in application delivery and operation, it is about the processes and practices we use. But most of all, it is how we integrate all of that through automation.

At a minimum, the process of being able to build code must be automated and there must be only one path to the build. Private scripts and personal sandboxes are all well and good, but they rarely reflect the true nature of the build environment, and they introduce error and risk, which results in rework. Developers must be able to integrate their code into the build in the easiest way possible. And the easiest way is to make it a natural byproduct of the development process. When the developer is done, when they check in code, the build should launch.

And the best “nice to have” in all of this is that once the build is complete, the automated test scripts must run automatically.

In an ideal world if the build fails, or any of the automated tests fail, the process should send the developer new “tickets” into their inbox, the code in the repository needs to be marked “incomplete” and the team notified. Breaking the build is a serious matter and affects the productivity of the whole team; consequently, breaking the build should come with serious consequences.

From a management standpoint, it is helpful to build metrics around the performance of the team in terms of numbers of broken builds, number of errors detected by automation, number of turnovers to QA for a particular release, and so on. And collecting these metrics through process automation means that dashboards can show this in real time for the team and show trending.

Selection of a build tool is often a technical merits decision, sometimes a fashion decision and always a cost decision. They all provide similar capabilities and performance and reliability. Indeed, they have become quite commoditized. The most important feature they need to possess outside their required build functionality is that they can be integrated into the fabric of your development processes through automation.
 

For a comprehensive resource on continuous integration, see Continuous integration: Achieving speed and quality in release management.

This was last published in September 2011

Dig Deeper on Application Lifecycle Management Tools and Processes

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close