The DevOps approach has had notable differences for enterprises striving to make their IT operations more streamlined. This positive impact on companies where DevOps (and Mobile DevOps) approach has been adopted has enabled them to build collaboration across teams, something that typically wasn’t that obvious in the past, just be focusing on the adoption of DevOps practices. There are lots of great success stories of how DevOps mentality changes the way companies where doing things, making process yet more faster, streamlined, and enabling companies to save money.
Despite many of these panegyrical stories about the positive impact of DevOps for enterprises, there are also challenges and other things organizations must tap in. During the past years, use of agile methodologies and impact of it for development, operations and all other parts of the organizations have been accelerating the DevOps movement and breaking down those boundaries between these functions. The question is – how Mobile DevOps can make a difference to an organization? And is the distinctive difference even between regular DevOps and Mobile DevOps? Find answers and more best practices in our free ebook – Mobile DevOps Manifesto.
Building Mobile DevOps culture isn’t necessarily easy. Like any process, culture or behavior changes within organizations it needs to be implemented properly and adopted step-by-step to encourage all stakeholders. It simply doesn’t happen overnight, but the modernization of the process, DevOps tools and practices will respond to business demand.
In this blog, we’ll take a look at some results from the Bitbar Customer Survey that was executed privately for users earlier this year. We’ll deep dive into those fascinating results later but for this blog I’ve snapped all the relevant answers for Mobile DevOps.
How, Why and Where Mobile DevOps Makes A Difference
The discipline for Mobile DevOps requires few important technical and support things to be completed to make difference for any organization. In order to get all pieces together and make the Mobile DevOps tools and process seamless for companies the problem and potential bottlenecks must be identified. These are the top things that came up in our survey and companies should focus on either fixing or adopting the better Mobile DevOps tools and process to get these challenges tackled.
(Way) Too Long Dev-Test-Feedback Cycles
Comparing fully adopted Mobile DevOps approach for development, testing, and deployment the old way of doing things lack a short-cut to reveal, document, and eventually fix found issues. If the development cycle including building, testing, and deployment is too long the development progress might advance faster and it’s definitely harder to keep up.
Even with an agile methodology in use, each step in the Mobile DevOps must be carefully evaluated and measured for efficiency and effectiveness. That eventually makes the process more productive, delivers value, and maximizing the critical business advantages. If the process is too slow some things can be boosted up, paced up and even eliminated if those do not have any impact on the results. Mobile test automation can really help in enabling continuous, frequent and instant releases that can be then quickly integrated, deployed and testing in automation context, and in a timely manner.
Bug Catching/Reporting Too Slow to Developers
When the right tools are in use everybody gets notified about problems pretty much instantly. Then there is only motivational and attitude that prevents developers to jump on those issues. Getting as rich and detailed results as possible will help developers to solve issues. You know, developers get the DNA of the wrong behavior, bugs or failures from log information, so this is critical to be delivered and preferably from as many devices as possible.
Non-Functional or Not Well Utilized Test Automation
Relying on non-agile methodologies, or not fully adopted agile methodology with recommended functions as a mandatory can make things very difficult in the testing phase. Many of the failures with test automation has been due to lack of knowledge and skills to adopt agile test automation for mobile app testing. There are still stories why many developers see test automation as something great but just haven’t got real-life cases to get things running on a variety of different devices. Because of this, test automation has been doomed by those who haven’t got it fully implemented and working. Instead of fully functional test automation, many users have done basic unit/system tests.
Use of Non-Real (Emulators) Test Environment
Testing on emulators gives you something result-wise. But again, are those results trustworthy? No end-user will run your application on an emulator that is typically executed on an x86-powered desktop, with much more memory, with different network infrastructure, and lack of all critical hardware components (different GPU, screen, its resolutions & orientation, WiFi components, and many others). There are very good reasons to stick with real devices and test only using an authentic environment.
Setting Up & Maintaining Real Devices
This has been an issue and one remarkable reason why developer organizations haven’t seen on-premise labs as worth it. Based on the facts, the need for different mobile devices (with all diverse software and hardware characteristics) has gone significantly up. For example, when the typical mobile device farm built internally was about 20-50 devices in 2014, the requirement has already exploded to 500+ devices. That’s significant growth number when it comes to using real devices for testing.
Nowadays, getting and setting up that level of device farm is no problem. For example, Bitbar Private Cloud caters to mobile app developers with any number of devices team must test their app on. Depending on how many devices are reserved and dedicated for customer comes from the market demand, and for what purpose is the application targeted for. Typically, the answer to this is “globally”.
Access to Relevant Mobile Platform / OS version / Devices
Fragmentation is not a new phenomenon for either major OS platforms – Android and iOS – and devices. There are lots of users that are passionate to upgrade to the latest one – and the other half who are just happy how things currently work on the device. In the middle of this, there are also users that have upgraded their OS version at some point but do not want to go the latest or simply their device OEM doesn’t provide an upgrade for that specific device model. That’s very common and is also known as device/user/platform fragmentation.
By defining what is a relevant OS version, as well as finding out devices that people use, can be typically a challenging task. Companies building professional apps may need to investigate both the Android Dashboard and Apple’s iOS Dashboard to get a better understanding of what OS versions are actually used.
Use of Manual Testing – The Weakest Link in Agile and DevOps Process
Manual testing is still (by far) the most used way to test anything on mobile. And that’s the biggest resource hog. Sinking effort and resources to manual doing while there are awesome test automation to help is a bad choice. Organizations understand this and want to build up that test automation competence to get things moving faster, cheaper and getting better results.
No Geographically Relevant Testbed – Devices, Networks, Back-End Integration
The target market matters you the most. If (and typically yes) app developers are targeting their app globally as potential with global app market is simply huge. Instantly, there are hundreds of millions of potential users for the application, game or web product – and making sure it will work well on all possible devices these users use.
According to the results of our survey, there are three major things that app developers are concerned about: 1) devices, 2) networks, and 3) back-end.
Mobile DevOps Tools
There are tons of great Mobile DevOps tools out there and widely used by industry. In addition, many of these tools (in each category) offer open and proprietary technologies that fit well for agile methodology trusted dev teams.
We’ll take a look at the ideal Mobile DevOps tool chain in our next blog, so stay tuned!