Building release builds with DoneDone

This is the final post in a five-part series introducing DoneDone, our simple, straightforward issue tracking tool to finish projects strong. Sign up for a 30-day free trial or paid account at http://www.www.getdonedone.com.

In today's final introductory post to DoneDone, we introduce release builds.

When we first started using other issue tracking tools, we discovered a recurring problem with how issues worked. There was no easy way to take all the issues we fixed since our last build and release them to our clients for retest in one batch.

In Elementool, we did this by creating a custom issue status called "Internal - ready for retest" to distinguish from "ready for retest." Whenever an issue was fixed by one of us developers, we'd mark it with this "Internal -RFR" status. This meant a bug was fixed but not available for our client to see until our next build.

Each night, Lindsay would create a release build email to the client and change the status of each issue to "ready for retest" by hand. For just a few issues here and there, this wasn't a big deal. But, there were times when a new release of the project had 50 or more issues associated to it. Doing this bit of manual labor was tedious and unrewarding.

Elementool treats issues like so many others - just a bunch of numbers in a bucket. There's no human-friendly meaning to issue statuses. They're just tags. This inspired us to create a very simple process in DoneDone aptly named "release builds."

When you create a new project, you can enable release builds on the project settings page.

By enabling release builds, DoneDone creates a new issue status called "Ready for next release." When someone is done fixing an issue, they mark it "ready for next release" and simply move on to another issue.

Whenever you're ready to post the latest version of your project for your clients to review, an administrator can go to the release builds page and create a new release build.

The release builds page shows you all issues in the "ready for next release" state. By creating a release build, three things happen:

• DoneDone moves all issues in the "ready for next release" state into "ready for retest"
• DoneDone also preps an email (which you can edit) that will be sent out to everyone who's assigned an issue in the release build. They are the ones responsible for confirming whether the issue has or hasn't been resolved.
• Finally, release builds are tracked in the build history. This is a nifty way to keep track of all the release builds for a given project and all the issues that made it in each release build.

What would take maybe a half hour to do by hand is wrapped up in one button push in DoneDone.

Nothing revolutionary. Simple and straightforward. We just haven't seen it thought through in any other issue tracking software. So far, it's become one of the most valuable features of DoneDone.

Sign up for a 30-day trial at www.www.getdonedone.com.