Using release builds with tags to organize development environment workflows
Many customers use DoneDone as an issue tracker on development projects. Most of these teams work in multiple environments. For example, your development team might first work on issues on their local machines, then batch all of their updates onto a staging environment for internal QA. After all issues have been verified, the updates all move to a production environment and might be retested one more time to ensure there are no further issues.
This workflow makes Release builds a really powerful tool. Release builds coordinate development teams to retest a batch of issues in a single project all at once—when those issues are ready on a particular environment. With release builds, we offer a canned set of options to label the environment that your issues are being released to.
However, our set of options might be limiting. Plus, the environment label is only associated to the release build and not to the individual issues themselves. This is where you can use
tags to better manage where issues should be tested.
Let's take our example from above. In this example, we'd recommend establishing a tagging convention for the issues your team is working on. For instance:
- Any issues that are testable on local machines should be tagged as on-local by the developer.
- Any issues that have moved to the staging environment should be tagged as on-staging.
- Any issues that are on production should be tagged as on-production.
As developers complete issues on their local machines, they add the on-local tag to an issue while marking the issue Ready for Next Release.
Once a release build is ready to go to Staging, you would add the on-staging tag to all issues in the release. You can do that right from the Release build form:
When the issues have all been confirmed and a release build is ready to go to production, you would add the on-production tag to all issues in the release.
Creating a custom filter for staging environment issues
With this simple workflow established, it's now easy to create a custom filter within a project to find out which issues are ready to test on the staging environment, and which issues are ready to test on the production environment.
For staging environment issues, you'd create a filter with all issues that:
- Include the on-staging tag
- Do NOT include the on-production tag
- Are marked Ready for Retest
This way, only issues that have moved to staging (but not yet production) will appear.
Creating a custom filter for production environment issues
For production environment issues, you'd create a filter with all issues that:
- Include the on-production tag
- Are marked Ready for Retest
This way, only issues that have moved to production will appear.
The big takeaway here is that you don't have to remove the on-staging tag when moving an issue up to production. You simply add the on-production tag. In other words, as issues move up the environment ladder, the corresponding tags are added to them via the release build. Your custom filters take care of only showing the issues that belong to the environment by using both the Including Tag(s) and Not including Tag(s) options.
We've shown a very simple example here, but if you have a more complex workflow with more environments, the process is just the same: Come up with a tagging convention for each environment and create corresponding filters to search for testable issues only in that environment. We hope this tip helps make your issue tracking workflow even more efficient!
