- Testing Approach
- The Build Process
- Auto-Update Testing
- Signing the Final Build
- Deployment
- Conclusion
The Build Process
To enable testing, we needed to create new builds on a regular basis. There are two ways to launch an AIR application:
- The first is by using the AIR Debug Launcher (ADL) developer tool to launch and then run/debug the application. This process is easy for developers using Flash Builder, but requires command-line configuration for users who don't have a development environment set up.
- The second way is to create a release build of the AIR app, using a temporary certificate (PK12) key. This approach creates an AIR installer, which anyone can use to install the new build easily. As we mentioned in part 4 of this series, the PK12 needed to be shared between developers to prevent certificate conflicts.
To enable the product team to test the application and share it internally with other departments, we created builds using the temporary key process. This technique allowed for easy testing, giving us the ability to install previous versions to verify issues and keep historical records of builds. As a feature was completed, the developer would create a new release build and then provide it to the team by posting it in a shared Dropbox folder.
The AIR configuration XML file allows for developers to manage version numbers, such as 0.8.5. We decided not to update the version number based on feature completion; instead, we would update the minor version number as milestones were completed. This technique provided a bit more flexibility in the numbering and prevented us from having to update the version number constantly just for a minor feature addition/change or bug fix.