5 Reasons to integrate your builds and your bugs
The Agile practice of Continuous Integration is gaining more and more steam these days. It's quite evident why, people are trying to do more with less, and are looking for any opportunity to automate within their organizations. Software development teams are doing this by automating their build processes. Once the build has been automated, then Continuous Integration comes naturally because you can run the build more frequently, increase the amount of feedback your developers are getting, and introduce more items into the build like automated unit tests, automated code coverage utilities, and increase the value of the information that is produced by the automated build.
It's natural at this point when the build is doing so much for you to look at other ways that your Continuous Integration environment can be extended to interact with other areas of your software development lifecycle. In fact if you take a look over at the open source Hudson project, you'll see that the plugins that are available for Hudson tend to cluster into certain areas. Open Source is a great way to look at where the needs are within a community as it encourages people who have an itch to write some code to scratch their itch. If others also have the same issue then you'll tend to see certain clusters of activity around those areas of interest.
Looking at the list of plugins from Hudson, one of the large areas that you'll see people have clustered around is integration with Bug Tracking systems. They have developed plugins for Bugzilla, JIRA, Mantis, Trac, and several others specifically for the purpose of integrating Build information with Bug Tracking systems.
We're all for this level of integration, and for the awareness in general that Builds and Bugs are two systems that can and should work together. Software developers rely heavily on both of these systems, and our philosophy is that Builds and Bugs should be integrated from the ground up. Here are our top 5 reasons to integrate your Build and Bugs systems, and why we think you'll gain in efficiency, save time, and be more productive as you adopt these approaches.
Bug records should display build tag
When you are browsing through bugs, and you see a bug that is marked as "fixed" it should be easy and obvious which build this bug was fixed in. Many bug tracking systems have fields for this, but unless you integrate your build and bug tracking systems, this is left as an exercise to the developer to fill in. Which means they'll leave it blank, or they'll put something invalid in the field if it's difficult to track down which build the bug will be fixed in.
This activity should be handled automatically by the build system by scanning through all bugs in the system that match the build and when the build is complete, all matching bugs should be updated. In Zed Builds and Bugs, when a developer completes an assignment, the "Fixed In Build" field automatically defaults to "next". This keyword is used by the system so that it knows which bugs to update when the next build runs. It eliminates the usual errors associated with collecting this data.
Completing a bug should be able to launch a build
The very act of completing a bug, or an assignment on a task should be a point to which you can attach meaning. The idea of continuous integration is that the build system should be triggered by meaningful events to check that the code base is still in a working state. Your team may want this to be configured to run when developers commit their code. But you may also want to configure it to run when developers change the status of their bugs. For example, say there are 3 different changes to 3 different source code systems that comprise the real fix for a single bug. In this case it doesn't make sense to launch integration builds until everything has been finalized in each of the code systems. It makes a lot more sense to trigger the integration build, tests, and verifications only after the bug has been marked as fixed.
You can only do this reliably if your build system and your bug management system are tightly integrated and share events and triggers between them. Zed Builds and Bugs has a powerful event based rules system that lets you tie different parts of the system together in ways that make sense for your team and your workflow.
Builds and Bugs should be linked and visible from the same system
If you find yourself looking for all of the bugs fixed in a certain build, or for the build in which a certain bug is fixed, you either have to have powerful search capabilities, or a system that naturally links build and bug information together. It allows you to start from either side and easily drill down into the details of the other so that you can get a complete picture of what is happening in your system.
Builds information should flow back to the bug tracking system
Your build system is doing a great job at manipulating your code in many ways. It checks it out from source control, it arranges it properly in modules, it compiles it, tests it, and even performs static and runtime analysis of the code. There's a wealth of information that is output from the build system that by all means should be captured, displayed, and analyzed in its own right.
There are going to be parts of this information that should naturally be used to create bugs in your task system so that they can be further analyzed and followed-up on. In order to do this most efficiently, it should be up to the build system to communicate this information back to your bug tracking system.
Not that every failed build should open a bug record. Hopefully a failed build and the subsequent notification that everyone on your team receives is motivation enough to find and fix the underlying problem.
No, it is for the more interesting facts that the build system discovers that you'll want tracking records created. For example, if a new critical bug is discovered by findbugs, why not have your build system auto-create a real bug in your bug tracking system so that the real issue will be resolved. The developers don't have to manually scan the system to discover things that they should have been working on 3 days ago, the system should notify them now by opening a new bug record.
Having Builds and Bugs in the same system reduces overhead
Let's face it, we're always looking for ways to be more efficient, reduce overhead, save time, money, and do more with less. Having a single system that can accurately track and manage your bugs and tasks, while at the same time providing continuous integration builds for your software enhances the efficiency and quality of your day to day work. Your team has a single point to rally around, all of the information is in the same place, and everyone knows where to look to find the answers to what is going on.
Simply put, you save time and money by optimizing how you work with a single system. You get more done, and you do it more easily.
There are lots of other reasons to integrate your builds and bugs, but these are some of our top 5 reasons to do so. We'd love to hear from you about your own experiences with builds, bugs, and the integration of the two.