In many cases, the way a team approaches the processes surrounding mobile development will look very much like whatever the first person that joined put in place: it's notoriously difficult to iterate on mobile development processes. There are definite benefits to taking a step back, reviewing and putting together a mobile DevOps strategy, though. In this article (based on one with a similar title we published on DZone a while back), I'll list some of the basic pillars of a mobile DevOps Strategy. Most of this will be obvious to mobile developers, but keep in mind that a good portion of implementing Mobile DevOps is convincing a bunch of non-mobile developers that "yes, mobile is actually this complicated and really does require its own set of tools and processes" 😉
Maximizing the value delivered through your app releases is the first-, most obvious- and arguably also the most important component of your Mobile DevOps strategy. Because of mobile's inherently rapid (and sometimes public) feedback loops through App Store reviews, a sufficiently mature process should be able to rapidly act on end-user feedback to improve on the apps it's producing.
Your Mobile DevOps strategy should aim to tightly integrate analytics and feedback with your core processes to ensure that insights are widely available and rapidly acted upon.
Being fast counts. Not necessarily being first (there are countless copycat success stories), but rapidly iterating and improving on your applications gives you an undeniable advantage. Exactly how big that advantage is is debatable, but in research done at Peking University, rapid iteration showed to drive growth for apps that rapidly and often released bug fixes and regularly interspaced those with bigger releases containing new features or functionality.
Your Mobile DevOps strategy should provide the necessary sense of security to reduce fear-of-failure and increase confidence in product and development-teams. The more confidence, the higher the velocity.
If you want to see a non-mobile engineer scratch their head in confusion, try to explain device- and OS fragmentation. The fact that we ask ourselves 'how much does it crash?' instead of 'does it crash?' is one of the things that's fundamentally different to most other types of software development.
By putting in place the right tooling and processes, your Mobile DevOps strategy ensures that releases meet the quality standards set by you, but also those expected by your end-users.
"Just double the engineers and we'll be done twice as fast", said no mobile developer ever. Being fast, bringing value, delivering quality all benefit from greater efficiency and — arguably — often suffer from indiscriminately adding more people to the team.
Your Mobile DevOps strategy should provide the tools and processes to automate repetitive tasks where possible, reduce wasted time and allow everyone to focus on their core tasks and competencies.
This is obviously a (very) basic starting point, but if you're interested in learning more on Mobile DevOps strategy, please read the extended version of this article here. From the Mobile DevOps page on Bitrise.io you'll also be able to find a growing collection of related content and articles to help you on your Mobile DevOps journey.
Have any thoughts to share on the subject? Reach out to us on Twitter, our Discuss pages, public Slack or a range of other places on- and offline.