Building Adobe WorkflowLab, Part 4: Planning for Build and Release
- Core Requirements
- Deployment Planning Strategy
- Initial Signing Process
- Testing Process
- What's Next?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The first three parts of this series have covered quite a lot of work in the creation of WorkflowLab. In part 1, we determined the high-level vision for our project, building and gaining approval for a prototype of the user interface. In part 2, the project team fleshed out use cases and features, determining a set of technical questions to address specific scenarios. Part 3 took us into planning for development, pinning down the relevant technologies that would be needed to create WorkflowLab.
In this article, we'll discuss how we developed the build and release process for our application. During this process we needed to answer a few core questions: What requirements did we need to address in order to create the app? How and when would we release our product to the public?
Core Requirements
In Adobe Flash Platform from Start to Finish: Working Collaboratively Using Adobe Creative Suite 5, we discuss the challenges and strategies required for building, testing, and releasing a Flash-based application. When planning the process of testing and deploying any application, multiple considerations have to be addressed. For AIR apps, these considerations differ from those of creating standard browser-based applications. We knew that WorkflowLab would be created using AIR, so our initial build-and-release strategy focused on these differences.
The first step in the build-and-release planning process was to define our requirements. Four core requirements had to be considered during the planning phase:
- Which version of AIR would be used, when would it be available to the public, and how would they get it?
- WorkflowLab would be updatable using AIR's auto-update feature.
- AIR applications need to be digitally signed with a certificate to allow for publisher verification.
- We had to develop a testing strategy to verify the features before release.
Once we had defined a set of core requirements, we could begin analyzing them to determine how they would affect the build and release process. This analysis also allowed us to start solving—or at least begin the process of solving—some of the bigger challenges that faced us, such as the intra-department communication and security requirements that are part of larger companies such as Adobe.