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.

CI/CD pipeline

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.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.