- 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
Deployment Planning Strategy
The first requirement we defined focused on the deployment process: How would people get our application, and when? One of the requirements defined during our initial meetings was that WorkflowLab Alpha would be available on Adobe Labs at the start of MAX 2009. Users would download the application by clicking an AIR badge installer, which would support installing WorkflowLab and AIR (if the user hadn't installed it previously).
This requirement meant that we would need to create an AIR badge and any assets for WorkflowLab during the deployment and testing process. We also would need to have our assets and application ready two weeks before MAX, to give the Adobe Labs team enough time to post the assets and content.
Another requirement was that WorkflowLab would be auto-updatable. Therefore, we would need to integrate the AIR Updater into the application, as well as providing a publicly accessible XML file to define the current version of the application (see Figure 1).
)
Figure 1 The AIR Updater process.
The AIR Updater uses the XML file to determine the latest version of the software. If the version listed in the XML file was newer than the user's version, the XML file would also tell the application where the updated AIR file was located, so that WorkflowLab could download the new version of the software.
Because the XML file had to be publicly available and we needed the URL path to the file to stay the same from version to version, we had to work with the Adobe web team to define a special "go" URL that would always point to the correct XML file—even if the XML file later had to be moved. This approach would enable the developers to "bake" (code) the URL into the application, so that the file URL would still work even if the XML file changed locations sometime in the future.