Mobile developers are designing a user experience. They need the power of Continuous Agile to work with users from day to day and to mold the look and feel of their applications. However, they also face three challenges:

• They are building a server and a client. The client must be distributed to the mobile devices.
• Appstore vendors add delays in distribution of two days to three weeks.
• They are designing software to run on multiple devices and form factors.

Luca Milanesio of LMIT Software explains how to use Jenkins and Android for continuous delivery of a mobile user experience

Moving towards Kanban and Continuous Delivery on Mobile

Most of the software development community is unleashing the power of Agile by moving away from SCRUM sprint-based planning to more Agile Kanban-style feature development. This features a new methodology promoted by the DevOps Movement (http://en.wikipedia.org/wiki/DevOps) and implemented by marrying continuous integration methodology with automated deployment. This is now known as continuous deployment.

However, the mobile applications market is struggling with a flashback to "waterfall" planning methods imposed by mobile platform owners.

Continuous deployment makes sense for the cloud backend development which powers the RESTFul API used by mobile apps. But does it make sense to extend it to the client layer as well ?

Releasing without Continuous Delivery

One solution to the problem is to isolate the mobile clients from the backend cloud deployments, keeping them as much as possible in different silos with a set of APIs between them.

In this environment, new ideas go into the backlog, changes are done in both client and backend layers, and features are developed and tested in a few days, Kanban-style.

However, continuous delivery is not implemented. The back end is deployed to the cloud in real time after the build. But deploying the updated mobile client takes longer. The packaging of the mobile client has been completed, but distribution is just starting. The mobile distribution channel typically takes from two to five days. And after distribution is completed, before you can get feedback, you still need to allow time for real users to install and discover the new features.

This issue is illustrated in the diagram below.

The development team starts work on the next feature on Day 3. However, no feedback is available until Day 10. Feature development starts to overlap between releases and block new releases. Because of this, delays in delivering the mobile app impact the entire Kanban cycle.

Releasing with Continuous Delivery

In our continuous delivery system, the client and backend are built and delivered at the same time. Selected users see the completed feature and provide feedback before it is delivered to the official distribution channel.

Bringing the Kanban methodology to Mobile

With Kanban it is key to reduce the size of each deployment by limiting the size of your work-in-progress queue (which determines the scope of the new release). Your team will finish a task before moving to the next task.

To achieve high velocity you must reduce the time required to get new software to mobile devices:

1. Clients need to find alternate ways to install the software in addition to the official mobile platform distribution channel.
2. App users need to be informed early on about the availability of a new software release, and should be able to install it seamlessly.
3. App users must have visibility into what has changed in the new software. Provide them with release notes.

When dealing with mobile applications it is key that everybody is involved in providing feedback on the application itself. It is not uncommon to have early alphas installed on every developer's smartphone in order to have someone using the app on a daily basis, even in its early stages.

We like to give our users visibility into all the tickets that are in the WIP queue, and even allow them to comment with a simple "Like it, seems cool !" or "Please don't do that, would kill my daily experience #!$@#!".

The most important concept behind Agile is the "fast feedback loop." The sooner you get feedback on a feature, either positive or negative, the better your choice of the next task to make the user happy. Fast is often a synonym of "easy" and "automatic." If you make something easy for people, they will do it more often.

Auto-assign feedback to stories

Users of your mobile application should see the stories that are implemented in a new software release. They can look at the affected features and use cases and provide feedback. Feedback should be automatically attached to the original story, so that it immediately goes to the correct developer.

Imagine that you introduce a new feature to send instant messages to other users. If you give users access to a full description of this feature, you will have the chance to get feedback while they are still on your app. When they have completed a successful flow for the feature, ask them for positive or negative feedback and a short explanation.

Some users will not be interested in the new feature and will continue to use the app as before. For these users, anomalies introduced by the new release can be classified as "side-regressions." Negative feedback from these users can identify features that are impacting the overall stability of your product.

Distribute Clients Directly from Continuous Integration

There are many tools to provide ad-hoc over-the-air (OTA) software distribution and to collect feedback from customers (i.e. Zubhium, TestFlight, Hockeyapp, Apphance). However, the central focus of your application lifecycle is often a continuous integration server. That server fetches code from your version control system, tracks changes included in each release and the user stories associated with them, runs automated unit tests, and produces binaries for distribution.

We have extended Jenkins with mobile clients and plugins so that it can distribute software and release notes to our mobile beta users.

Mobile acceptance tests

There are a number of acceptance tests you can run during continuous integration builds. You can automate many of them with both commercial and open-source tools such as the Android emulator plug-in for Jenkins in combination with MonkeyRunner.

However, there are a number of usability acceptance tests that cannot be run automatically, because they require people to use the features on a device and provide real feedback with real thumbs on the touchscreen.

Allow real beta testers to put their hands on the application and use it. Whenever they find problems they can report them directly within the application. Feedback can be automatically collected and organized into acceptance test reports.

Auto-dynamic release notes

The goal of continuous delivery is to have everybody aligned to the "latest and greatest" version of the software. This avoids troubleshooting on older branches and keeps customers engaged with the latest features of the software.

In order to avoid losing control of which features are contained in a specific software upgrade, a new way of composing release notes is needed.

1. Always associate stories to commit changes. Include in each source code commit the ticket-id of the feature that has been included in that change. Never mix up multiple features in a single commit, because that makes it difficult to isolate the effect of each feature in case of a failure.
2. Auto-extract release notes at build time. During the continuous integration build, cross-reference the changes coming from your commits with the list of tickets referenced. This builds up your release notes so they are automatically associated with the correct release artifacts.
3. Dynamically compose notes for each client upgrade. Each client migrating from Version X to Version Y will include a different set of features. This results from the union of all tickets resolved in the code between the two versions. Users need to see reports on the full set of changes included in their "release jump."

Conclusion

Mobile application development is moving fast. Continuous integration and deployment needs to be adapted for the mobile experience so you can include your clients in the loop, show them what you are delivering, and collect their real feedback in real time.

Tools such as JenkinsMobi can facilitate this feedback loop by integrating all the elements of your Agile Lifecycle Management (ALM) into the mobile experience, and by integrating feedback about the client software into your issue tracking backlog. The cycle looks like this: