Building Adobe WorkflowLab, Part 7: Build and Release
- Testing Approach
- The Build Process
- Auto-Update Testing
- Signing the Final Build
- Deployment
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Parts 1–6 of this series discuss in detail the process involved in conceptualizing, designing, planning, and developing the Adobe WorkflowLab product. At this point, the design and development teams had invested considerable time and effort in examining scenarios, considering technologies, planning for production, and developing the framework and components. With all of this groundwork established, the teams were ready to begin testing features in builds and working toward release of the final application code.
Testing Approach
As we discuss in Adobe Flash Platform from Start to Finish: Working Collaboratively Using Adobe Creative Suite 5, the process of product build and release begins with testing the application. For WorkflowLab, we began testing as the development team created features. Once a developer considered a feature complete, the team reviewed the feature to verify that it corresponded with the previously defined specifications and didn't have any issues.
If an issue was discovered, we logged it into a bug-tracking tool. For the first few versions of WorkflowLab, we used Mantis, a free PHP-based tool. Eventually we moved over to Trac for the current development process because our third-party code-repository host provided free integration of the repository with Trac's ticketing system. When logging a bug, we assigned it to the developer who built the affected feature, and then that developer fixed the problem.
The fixed feature was included in the next test build, and the person who originally reported the bug verified that it had indeed been resolved. With that issue addressed, we updated the report in the bug-tracking tool and then moved on to new development or continued testing.