Many companies that have adopted Mobile DevOps as part of their product development lifecycle are also using internal checklists to ensure the expectations of their software and delivery are met. However, these types of checklists also form a great baseline to measure what are the critical areas of improvement for the future and what parts of the process may need to be potentially enhanced.
When looking at Mobile DevOps process there are only a few top categories that need daily attention. But those critical daily tasks must be taken care to ensure the development, testing, deployment and delivery have a smooth flow and teams get things done. We’ll take a look at those categories in this blog.
If we look at what Mobile DevOps is really about, it can be roughly categorized in 6 different subsets to evaluate how well the process is established and probably what parts of it could be improved. The checklist was divided into 6 different topics:
- DevOps Alignment. DevOps is an organizational shift, not just a technical one and unifying group and individual direction and goals around the singular vision of the organization can make a difference.
- DevOps Context. This could be also ‘DevOps participation’. Is everyone participating and is the process adopted by all critical stakeholders? The DevOps context is actually making all relevant information available to those who need it, and when they need it.
- DevOps Learning. Eventually, everyone involved should be learning to execute and by learning those best practices DevOps life can be easier. It’s all about how to empower your team and your personal growth and how to foster understanding through continuous improvement.
- DevOps Lifecycle. Focus on the software as a product with care, attention and reflection, and be a part of the ever-changing ecosystem.
- DevOps Organization and Resources. Providing structure for interactions and ground rules on supporting collaboration and productivity.
- DevOps Process. Habits crafted to foster consistency, confidence and collaboration, provided within the Mobile DevOps framework to achieve continuous improvement.
Okay, with these pre-words, let’s see what are those 5 critical targets for Mobile DevOps every day. Or you can get a free copy of our DevOps ebook that covers more than daily tasks.
5 Daily Tasks of Mobile DevOps
Here are the top 5 tedious things for mobile DevOps – if you don’t rely on sophisticated device farm or have invested in devices to run on a local environment – that should be taken care of every day:
Handling mobile devices can be a cumbersome task. Depending on how large an in-house on-premise device lab is, it’s still number one the most important daily check-up target for mobile DevOps. This is the top reason why mobile device farms are getting significant popularity among mobile-first companies.
For example, have you ever thought how to enable a new Android device in your local test lab? Here are few tips and tricks – and the actual checklist we go through every time we add a new device in our device farm:
- Set WiFi network. Without the network, devices and testing capabilities are limited.
- Add Google account to devices. And a good rule of thumb is to uncheck if auto-sync for the account is enabled. If you leave it checked your daily tasks will be quickly all about checking why devices aren’t ready for testing…
- Keeping Google Play Store relevant. It’s actually important and for sure makes your life easier to have the Google Play store updated and device installed with the latest version. Otherwise, you’ll start getting notifications and again, the circle of ‘why devices are stuck and my tests are flowing’ will hit your fan. Few tips:
- Without Google Play Store installed, the device won’t have the required services which could be critical for some of the testing scenarios.
- Start Play Store once and check possible notifications. Typically there are few so check them and close the app.
- Install Google Play Services. Services provided with Google platform will be in use and you can rely on that there is much less thing to worry about. Also, it’s recommended to disable this functionality occasionally to test how apps work WITHOUT these types of services:
- Open Google Play Store and search “Google Play Services”
- NOTE! Google Play Services is updated quite often. Without upgrading your device will get notifications about a need to upgrade Google Play Service
- Install Google Play Games. Similar to Play Services, and especially if your company is developing a mobile game. Absolutely must to have:
- This is required if – for example – you are testing games or your app depends on it.
- Open Google Play Store, search “Google Play Games” and install it.
- Disable security checks for installing applications through a USB connection. Android is not like Apple and one of its greatness is that apps CAN be installed from various locations, by various developers and sources, without confirming everything. My take, I think Apple will shy away from this sort of features in time, as it can really make this tedious for mobile DevOps:
- Enter “Development options” in Device settings
- Check “USB debugging”, “Stay awake” and “Allow mock location”
- Uncheck “Verify apps over USB”
- Enter “Security” on Device settings
- Check “Unknown sources”
- Uncheck “Verify apps” (This is not necessarily available with all versions of Android)
- Disable Screen Lock. This will save the day. If screen locks for any reason (not used for some time) with some test scripts tests may be
- Enter “Security” on Device settings
- Go to “Screen lock” settings and select “None”
- If this is not possible, you need to configure the device to be unlocked from Device settings on the Admin pages.
- Enter “Security” on Device settings
- Set correct Date & Time to devices. If you get questions why tests were executed yesterday or tomorrow, you know what is wrong and how to fix it:
- Set all “Location Services” on.
- Install Chrome and other browsers. Eventually people want to test on different browsers than what was delivered as part of the device. It’s a good rule of thumb to add a few of them, and preferably the latest and the most used ones:
- Install Google Chrome Browser, if your tests need it
- Sign in to Chrome browser to make it work robustly on tests.
- Set Screen timeout to the maximum value. The same things as with screen lock, if the screen stays up for a longer period time, the better:
- Enter “Display -> Sleep” in Device settings
- Select maximum timeout value for sleep.
Now, these were the tips for adding a new device. But as you can see, if that is not done ‘the right way’ mobile DevOps guys will have a lot of things to do on these devices, every day.
Let’s put devices aside and think about what else is required to run a mobile device lab. As there is a myriad of moving components, attributes, that all must be maintained and checked whether everything is up in speed, many of the mobile device farms rely on either some internal monitoring implementation or commercial ones to keep everyone up-to-date with the status. For mobile DevOps, the monitoring tools and features provide the fastest way to spot if something is (seriously) wrong.
Ready-to-go infrastructure is typically a feature on premium mobile device farms and easily delivers what it promises: no delays for development, testing, deployment, and always focusing on result-driven approach. In long run, this is one of the biggest factors to save money and make things run faster and be more robust.
Support for Developers, Testers, QA – and Customers
The Mobile DevOps culture relies heavily on communication and collaboration across teams, and very often it is the DevOps guys that provide internal support for devs, testers, QA folks – and sometimes even to customers. No, it’s not a full blow customer support division, but when operating large scale labs for different counterparts, they are the best resource to collaborate with external customers as well.
Support provided by Mobile DevOps can be just helping to get test runs progressing, running faster or making sure that (test) results are delivered. Software developers in test (SDET) and QA engineer need a different type of support when using the infrastructure, devices, and basically the agility produced with a DevOps approach can help a lot. And get those important business metrics met (and exceeded).
Operational Side of Things
Isn’t this no-brainer? Actually, it’s again making sure that all infrastructure is working properly. And as devices, infrastructural hardware (servers, databases, monitoring tools, additional physical hardware, among all the other things) and integration points work out, there is still the connectivity. Power supply and making all infrastructure powered is very critical, but so is the connectivity of all these things together. Typically there are a dozen WiFi networks that device farms must use and that monitoring software must continuously scan what is the current service level and how much can be gained from the service provider.
Integration with DevOps Tools and Test Automation Frameworks
There is no doubt: open source frameworks, technologies, and tools are the most successful when it comes to the use of those in today’s agile processes. It all starts with the nature of those products. When something is open it basically means these products are always available and usable, can be easily changed to something else, and this gives the reliability and freedom for organizations to change those any given day.
Proprietary frameworks and tools may offer better support, but that’s just another side of the coin. These proprietary tools, frameworks platforms have disadvantages in that you are dependent on the limited capabilities that a vendor can provide and if you need to do something outside of the box you don’t have many options other than begging for enhancements and having to wait.
The maturity of open-source testing frameworks such as Appium, Calabash, UI Automation and Espresso have come a long way. There are vibrant communities surrounding these platforms and lots of contributors. Most use cases are covered and you have the ability to branch for your own needs. There are a few cloud vendors supporting open source, but make sure that you’re not having to use custom libraries or methods in order to make things work, as this limits the ease of executing locally on your own devices and creates vendor lock-in.
What this means to Mobile DevOps and does it need to happen every day? Well, making sure that open source enablement is part of the process is crucial and helping hand is required every day to ensure test automation scripts run smoothly on a set of devices. Integration flow can break easily if not monitored as people tend to bring their own habits (and yet often, proprietary, non-compatible) tools to be part of the process.
In the next blog, we’ll take a look at the tool process and what tools should be in each step of the process.