Can any tool that does builds be used to do continuous integration, or are there special features that need to...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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.
Dig Deeper on Application Lifecycle Management Tools and Processes
Related Q&A from Kevin Parker
Add controls to the business of delivering software, and teams will scream about delays. However, fast development is often the result.continue reading
Kevin Parker discusses the pros and cons of industry analyst reports and advises when it might be best to trust your own instincts.continue reading
Actually, application development veteran Kevin Parker says ALM is really a part of the APM process when you look at it from a distance.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.