By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Mobile development increases the complexity of integration
A development team can currently use Jenkins, TFH or other platforms to do automated builds and testing for mobile. There are also tools available to help users write scripts in Calabash and "device clouds" for testing on simulated hardware that can all be integrated with continuous integration (CI). However, what these tools can't do is identify, predict or prevent all the potential problems that will arise and throw a wrench in the works. On a practical level, there's still a lot of hands-on work in mobile development.
Eran Yaniv from Perfecto Mobile agreed that CI as a process has a long way to go to make the developer experience seamless and productive. "The main difference is the nature of mobile. You have many surprises. There can be corruption of your mobile device, there can be loss of signal, battery draining, and so on. When you are doing Continuous Integration testing for a traditional environment, you start the Jenkins 'job', you have a flow end to end, you come in the next morning and read the emailed report, and you move forward."
The main difference is the nature of mobile. You have many surprises.
Eran Yaniv, Perfecto Mobile
The situation is a lot less rosy for mobile application development. "In mobile, the continuous integration needs to be mature enough to be considered unattended CI. Right now, it's more difficult because there are more elements that can get in your way. It could be operating system bugs, software bugs, hardware bugs, hardware limitations or issues you don't expect. When you come in the next morning to read the report, you may not find what you expect, and you have lost that time." When this happens, Continuous Integration looks a lot more like "Stop and Start" integration.
Mike Hostetler at Append To said he sees substantial progress in making testing work for JS in CI. "Testing especially is growing in importance. There are three tools we recommend. QUnit is the most popular. There's also Jasmine and Mocha. You can't go wrong with any of the three. All three plug into CI systems that will do the type of Continuous Integration and Continuous Deployment you're used to in a more statically typed language." The expansion of JS into the backend is also having a positive impact on the evolution of JS and CI. According to Mike, the explosion of Node.js tooling in particular is beginning to carry over into the front end, adding to the options available for JS development.
How has moblie changed the way you do CI? Let us know.