What the Android DevOps-engineer head hurts

It so happened that the DevOps tools are usually illustrated with the example of a large-scale web service CI / CD. This was partly due to historical reasons; partly, wonderful books like Google SRE Book played their part.

To hell with, let's look at something really new . At Mobius 2017, Jing Li from Viacom comes to us with the report “Android meets meets Docker” .

On the eve of the conference, we managed to find a few minutes in his busy schedule and ask a couple of questions. In this interview, Jing talks about DevOps in mobile development, gives examples of tasks and gives specific recommendations for improving your DevOps process.

- Hello. Tell Habra about yourself. Where do you work, what do you do?

“I used to be a developer at Sony, Nokia, eBay and Viacom (they are the owners of MTV, Paramount Pictures and so on). At the moment I am preparing for the next big adventure, relaxing at home and working on my open source projects ( https://github.com/thyrlian ). Information technologies are now developing very fast, every day you need to learn too many new things. Therefore, after work, I try to engage in machine learning and virtual reality.

- How did you get into mobile development? Are you doing DevOps on an ongoing basis or was it a one-time job?

- Just like children love to play on game consoles, I was addicted to a mobile phone since high school, when the grass was greener and the screens were monochrome. It is clear that after graduating from university, I immediately took up mobile development. In mobile development, DevOps happens every minute, especially when someone uploads changes to the code. Just as in the usual development, DevOps requires a lot of work on writing code, the correct architecture and complex configurations. Given the combination of these three aspects, it is difficult to say that this is some kind of one-off work. This is an ongoing process, its progress in which can be monitored for many very specific signs:

• Speed - your reaction time should be such that developers do not have to wait for a response for too long;
• Stability - no one wants to work with a collapsing system, this is a waste of time;
• Reliability - the results should be of sufficient quality and reliable, no false positives;
• Consistency - the results should not differ between several attempts to start, or between different machines;
• Flexibility - the use of modular systems allows you to write code once, and run it - everywhere (Jenkins, CircleCI, etc.);
• Unification - you need to get rid of language barriers and use one universal language to glue different parts of the system;
• Scalability - if possible, the parallel execution of tasks, you must choose the right ways to resolve engineering compromises;
• Reproducibility - never lose control of your version control system configurations.

I often see people over and over again pressing the “restart assembly” button in the hope that the assembly will turn green. This is due to stability, reliability and consistency issues.

- How exactly does DevOps on mobile platforms differ from what happens when developing web services (like Google) or desktop applications? Is there anything special about it?

- Tulchains for traditional development: backend, frontend, desktop - they are quite functional and run natively. Mobile phones also need to choose between running on a computer or on a mobile platform. Which, in turn, can be both a physical device and a simulator. In addition to the environment, there are dependencies on various third-party services. The most common part is publishing: Google Play, the App Store, or one of the publishing services like HockeyApp or Fabric. For each of these services, there are console utilities that can be used in automation. On the other hand, you can use tools like Fastlane. Often you need to take care of side tasks. One of the main tasks is design. For example, you need to decide how to automatically import and convert designer resources in a simple way. If the application works in several countries, you can meet the task of synchronizing localizations with collective translation services such as Crowdin or POEditor. This is not the whole headache - for example, we wanted to monitor the performance of the application after publication. Or how to get ratings and user reviews? How to display in the form of graphs on a large monitor hanging on the wall? All this data is obtained from external services; it is not easy to integrate them with each other.

“You always have interesting stories in store.” Tell me about any task that you had to devapss for a mobile platform? Better something off-topic to keep intrigue.

- At a time when Google had not yet released Android 6.0 Marshmallow, the system during installation asked the user to provide the appropriate permissions. If the new version of the application wanted extended rights, the application could not automatically update - first the system requested the user permission for this extended set of rights. One day it happened in our team - we added some kind of library, which suddenly quietly added some additional permissions. This instantly brought down the frequency of updates to our application. It became clear that in Continuous Integration, you need to add a check that would signal changes in the list of permissions. Unfortunately, there were no ready-made solutions at that moment. The first thing that occurred to me was to write a unit test, which would check all this programmatically, but it did not work out such a test (you cannot get all the permissions). The second attempt is to parse AndroidManifest.xml , and, of course, this idea was also doomed to failure, since the permissions of third-party libraries are in their own manifests and managed by the manifest collector. Finally, I decided to analyze the generated APK, pull out the full list of permissions from it and then compare it with the previous, previously saved results ( https://github.com/thyrlian/NoNewPermissionForAndroid ). This approach worked great, but as you can see, it is not intuitive and requires additional work. By the way, since Android Studio 3.0, the built-in APK Analyzer provides similar functionality out of the box ( https://developer.android.com/studio/build/apk-analyzer.html ). The ecosystem is getting better and better.

- In Russia, there is a culture of highly specialized teams: a separate development, separate testing, etc. Tell us, what tools should a sysadmin learn in order to better interact with mobile developers, to help them more effectively?

- Mobile system developers seem wizards. In the experience of my previous work, a good wizard in a mobile team looks like this:

• He is not just a master console, he is also well versed in the project. For example, Gradle is the de facto official build tool for Android, so it’s wise to choose Groovy as the main language for all build scripts. But on iOS, CocoaPods and Fastlane are very popular, so Ruby should be chosen.
• System administrators will not be able to protect the peace of the team 24/7. Team members themselves must understand how to break through typical assembly problems, especially through small but pressing problems. When you do not need to constantly wait for someone who comes and solves your problem - not only efficiency, but also your job satisfaction grows.
• “Mobile developers” are called “mobile developers” because they are well-versed in mobile phones. They do not have to be well versed in databases or anything else - in fact, they usually don’t understand. But as soon as the mobile application starts communicating with the server via the API, if problems arise, all this needs to be debugged, and for the mobile developer this debugging is a big pain. Do not even try to teach them complex SQL queries or how to bind logs with a huge command in the console. It is better to arrange for them a small introductory course on the use of Kibana or Grafana, in which you yourself have invented frequently used queries.
• On the other hand, the admin must clearly know the needs of the mobile developer and understand the goal that he wants to achieve. Maybe you've already set up Sonar rules for Java backends thousands of times, but these standard rules are not suitable for Android. Android developers need their own special settings. Before you give them a ready-made solution, carefully check that this solution is specially tailored for mobile development.

- What technologies should a developer learn in order to build a good infrastructure and the right DevOps process? How to write mobile applications so that it is more convenient to devopss ?

- You need to learn at least one scripting language, because in a typical build environment you cannot rely solely on Java / Objective-C. The assembly functionality needs to be turned into modules, small fragments that not only simplify refactoring, but also make it easier to adapt to different conditions (for example, when switching from Jenkins pipelines to Cricle CI, or if you need to jump to Travis CI from Circle CI). Mobile development is rapidly evolving, so you should not pledge to use only some specific third-party solutions, because they can become obsolete at any second. Build on the official tools and public APIs from Apple and Google, and tools based on them. And most importantly, think broadly, consider solutions that differ from their current configuration. For example, if an Android developer suddenly wants to install some kind of new toolkit on your build environment (for example, on MacMini), try to analyze the consequences of this.

- OK thanks! See you at Mobius 2017!