Like many products, DoneDone was conceived largely to solve a specific problem we faced as a business — specifically, what we experienced while managing issues with client projects. But, no matter which issue tracker we used, we discovered a recurring problem with how issues worked:
There was no easy way to take all the issues we had fixed since our last build and release them to our clients for retest in one batch.
The Issue With Most Issue Trackers
For a while, we tried Bugzilla. Then, Elementool. For each project, we created a custom issue status called “Internal – Ready For Retest” to distinguish these bugs from other ones that were truly “Ready for Retest” by the client. Whenever an issue was fixed by one of us, 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 client release.
Each night, we would craft up an 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 60 testable issues associated with it – particularly during the last two weeks before launch. Doing this bit of manual labor was tedious – it added extra grunt work when we could afford it the least.
Release Builds: A Simpler Way to Organize and Test Issues
This singular nuisance in issue tracking drove us to build DoneDone. Specifically, it helped us define a very simple process in DoneDone aptly named Release Builds. It was the core unique feature we released in 2009, and nearly four years later, that has largely remained unchanged.
Release builds are dead simple. When you’ve fixed an issue that you don’t want the assigned tester to review yet, simply mark that issue as Ready for Next Release. That keeps the issue out of your Issues Waiting On You bucket. It’ll also be hidden from the tester’s bucket as well. Essentially, the issue is in a holding pattern until you create a release build.
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. In fact, the new DoneDone automatically displays the number of issues ready for next release above the “Manage Project” icon on the project’s homepage. There’s no digging to find out how many issues are ready to be sent out for clients to test.
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 delivered to each person assigned to test at least one of these issues.
- Release builds are both tracked per issue, and collectively under Previous Release Builds.
At We Are Mammoth, we use release builds at the end of nearly every day to communicate with our clients on a new staging site release. In fact, we’ve done over 1,300 release builds in the last 3 years! It is an integral part of our development process — and we think it should be part of yours too.