Step Five : Setting up our Development & Deployment Environment With our code deployed and any quick fixes live and working it’s time to invest some effort into the long term development environment for the application. Although the mobile application development world is still in its infancy the toolset and modern development practices are coming to maturity. We will be repeating a bit of best practice modern development methodology here, but we think it is worth highlighting the key differences when building mobile applications which primarily focus on device testing, provisioning and deployment into live environments; particularly the gated app stores. Device Library and Registration One of the early investments you will likely need to make is building a representative library of devices to test upon. There are testing tools which allow for an automated test of UIs similar to those used in web development. However, we have found that for a significant proportion of applications and (in particular those which seek to support a broad array of consumer devices) that a manual test is still required to ensure high standards of visual design. At Indiespring we strive to achieve 90% of Android coverage and 95% of iOS coverage within an application’s target market which typically requires a device library of 30-40 devices upon which the application will be required to be tested at intervals determined by the previously created testing specification. Another thing to consider, particularly on iOS, is that devices need to be provisioned and registered with your distribution system to allow them to run internally deployed builds. On the Android side of deployment things are a little easier but you will still need to ensure users are able to install developer signed APK builds which will likely require some tuition or remote assistance to achieve. The end result should be a complete list of all devices which will be required to test the application with these devices all registered within your chosen provisioning and deployment system. You will also require a process to onboard and offboard devices as users get new handsets, stop using old ones, perform factory resets etc. Basic Automated Testing, Pull Reviews & Quality Assurance Programs We would next seek to ensure that a sensible level of automated testing coverage and appropriate quality assurance to occur across the application development full stop. Different use cases and different organisations will have their own views of the testing process to achieve a high standard of engineering full stop. are implemented and adhered to with mobile application development as much as traditional software development. This will likely mean implementing improved test coverage over time, but setting up the continuous integration services and integrating them with the appropriate deployment systems is an important first step in ensuring a continuous improvement to code quality. Sadly, we often find that mobile applications, particularly those which are several years old, lack some of the engineering safeguards we have come to expect in modern software development. This will take time to rectify, but is worth pursuing as we seek to stabilise the application development. Job Runners & Automating Internal Distribution We usually recommend setting up an appropriate job runner to link together the source code, compilation, signing and distribution phases of the application development lifecycle. We are looking to ensure that environmental variables which allow a given build to target the appropriate deployment environment are set and automated, that the appropriate distribution groups are configured and set up to be alerted upon the release of new builds and that the feedback loop to allow Quality assurance reports and user feedback is enabled and integrated into our ticketing system, Fullstop. The actual implementation of this integration will vary depending on organisation and setup. But the objective is to reduce the time to build, sign and distribute internal builds and increase the speed of iteration and feedback from test groups. It is worth noting that if your application is deployed internally via a mobile device management suite it may be possible to utilise the features herein to pilot new builds with live users. App Store Release The last piece of the puzzle is to enable release builds to be deployed into their appropriate app stores. The application ecosystem is moving quickly and we have not yet found a reliable supported means of automating this final step. So builds will be manually uploaded into the appropriate app stores. additional metadata and supporting marketing assets are available and updated as new builds of the application are released. Description, Pricing, Release Notes and other associated App Store data. Conclusion Now with your development and deployment up and running, a normal release cycle is now in position to allow you to iterative, improvement & proactively assure your app. Step Six : Iterative Improvement & Proactive Assurance ›