Mobile DevOps in practice
Hi, Habr! Today we share with you a simple and clear guide to how to put Mobile DevOps into practice. In addition to the paper guide, under the cut, you can also find video recordings of the master class of the same name, where every aspect of DevOps is considered in relation to mobile development.
I give the floor to the author, Vyacheslav Chernikov.
')
Greetings, dear reader. Summer once again flew at the speed of a comet, and along with the autumn it is time to return to 150% productivity. Back in the spring, Microsoft and I prepared the “Mobile DevOps in Practice” guide on how to automate the process of developing mobile applications to the maximum. Below is an introductory excerpt from the full manual.
By itself, DevOps slowly walks around the planet in an embrace with flexible management techniques. However, if you take a deeper look, then DevOps is first of all a culture in which the entire team developing and maintaining an IT system works as one. It is communication within the team that is essential for building healthy interactions between business, programmers, sysadmins and testers.
The second important element of any DevOps process is team training. In an ideal world, the team (starting with the business) must learn to better meet the needs of the end user, creating value for the consumer. But in practice, the “value” also needs to be learned to count and draw from this literate conclusions. For training, in any case, feedback from real users is necessary. Systems of continuous monitoring of the viability of IT systems and various logging systems become such a link.
And that this DevOps would exist not only in the heads of developers, it must be implemented in practice with the help of tools that fit the needs of the task. Part of the DevOps culture is also the pursuit of automating routine activities. This makes the process of developing and developing IT systems less painful and more efficient.
DevOps itself appeared as an approach for large teams and companies working on large IT systems consisting of a large number of modules, often written in different programming languages ​​and designed for different execution environments. However, as the term and approach were popularized, DevOps began to adapt by various teams solving a wide range of tasks.
Most often, DevOps is associated with large digital products, the development and maintenance of which are engaged in dozens, hundreds, and sometimes thousands of professionals. Many teams have already developed their own practices and their own tools to support the DevOps process - an automatic build, test, deploy and monitoring system. Usually, this is all created on our own infrastructure, but cloud tools CI / CD are actively developing.
Figure 1. The difference between Mobile DevOps and Enterprise DevOps
All this is a little associated with the development of mobile applications. Mobile DevOps is a “reduced” version of the usual DevOps, since mobile applications are primarily a convenient interface for interacting with external IT systems. The smaller scale of the team, and its specific problems specific to mobile applications (see Figure 1):
In order for DevOps to work and there is real interaction between the teams, you need a single language and a single working documentation, understandable to all participants. Here, no approach provides clear guidelines, and the systems are all different. However, it is the documentation that lives with the project for the full life cycle and is a tool for communication and team interaction.
Figure 2. Working documentation
Competent working documentation can simplify and accelerate the development of the project. This process is described in more detail in our Guide # 2 " Technical Design of Mobile Applications ".
Here we denote the main documents (see Figure 2):
- list of screens;
- map of transitions and states;
- a table of screens.
The use of cross-naming and numbering is important. That is what simplifies and speeds up the process of communication within the team. Also an important factor is the compliance “documentation-code”, which makes the communication of business with developers clear.
So, we have decided on the interaction culture and working documentation and now we can move on to instrumental support in the form of a CI / CD pipeline. The more operations you manage to automate, the better.
Mobile development has 3 distinctive problem areas:
In general, testing and debugging on a large fleet of real devices is indispensable.
In actual practice, it is impossible to do without manual testing on smartphones or tablets. However, part of the code is easily covered by automatic tests based on Unit Testing (hereinafter referred to as unit tests). Let's look at the typical architecture of most applications - Figure 3.
Figure 3. Classic three-tier architecture
It is wiser to carry out a complete test coverage in two directions:
It is not possible to cover all unit tests in mobile applications, plus it reduces the speed of development and system updates. For the automatic unit-testing phase of the CI / CD pipeline, it will be useful to cover the following DAL layer mechanisms:
If we talk about automatic UI tests, we can test the following:
Based on the results of the UI tests, screenshots are collected with each step on each device, and based on them, the QA engineer in manual mode can review the correctness of the application layout at different resolutions and screen sizes.
Convenience, smooth animations and other user characteristics are difficult to outsource autotests, they are best left to live testers and beta users.
The end of the introductory fragment.
The full digital version of the “Mobile DevOps in Practice” paper guide .
I would like to discuss Mobile DevOps live or ask questions - I will be glad to see you at the Microsoft DevOps Summit on September 13 in Moscow ( registration ) or on DevOps Days on September 14-15 in Kazan ( more ).
As always, I will be grateful for the feedback and questions in the comments! Stay in touch!
Vyacheslav Chernikov - head of development at Binwell , Microsoft MVP and Xamarin Certified Developer. In the past, he was one of the Nokia Champion and Qt Certified Specialists, currently he is the Xamarin and Azure platform specialist. He came to the sphere of mobile in 2005, since 2008 he has been developing mobile applications: he started with Symbian, Maemo, Meego, Windows Mobile, then switched to iOS, Android and Windows Phone.
Articles Vyacheslav you can also read the blog on Medium .
I give the floor to the author, Vyacheslav Chernikov.
')
Mobile DevOps: guide to action
Greetings, dear reader. Summer once again flew at the speed of a comet, and along with the autumn it is time to return to 150% productivity. Back in the spring, Microsoft and I prepared the “Mobile DevOps in Practice” guide on how to automate the process of developing mobile applications to the maximum. Below is an introductory excerpt from the full manual.
1. About DevOps
1.1 About DevOps Culture
By itself, DevOps slowly walks around the planet in an embrace with flexible management techniques. However, if you take a deeper look, then DevOps is first of all a culture in which the entire team developing and maintaining an IT system works as one. It is communication within the team that is essential for building healthy interactions between business, programmers, sysadmins and testers.
The second important element of any DevOps process is team training. In an ideal world, the team (starting with the business) must learn to better meet the needs of the end user, creating value for the consumer. But in practice, the “value” also needs to be learned to count and draw from this literate conclusions. For training, in any case, feedback from real users is necessary. Systems of continuous monitoring of the viability of IT systems and various logging systems become such a link.
And that this DevOps would exist not only in the heads of developers, it must be implemented in practice with the help of tools that fit the needs of the task. Part of the DevOps culture is also the pursuit of automating routine activities. This makes the process of developing and developing IT systems less painful and more efficient.
1.2 What is the difference DevOps vs Mobile DevOps
DevOps itself appeared as an approach for large teams and companies working on large IT systems consisting of a large number of modules, often written in different programming languages ​​and designed for different execution environments. However, as the term and approach were popularized, DevOps began to adapt by various teams solving a wide range of tasks.
Most often, DevOps is associated with large digital products, the development and maintenance of which are engaged in dozens, hundreds, and sometimes thousands of professionals. Many teams have already developed their own practices and their own tools to support the DevOps process - an automatic build, test, deploy and monitoring system. Usually, this is all created on our own infrastructure, but cloud tools CI / CD are actively developing.
Figure 1. The difference between Mobile DevOps and Enterprise DevOps
All this is a little associated with the development of mobile applications. Mobile DevOps is a “reduced” version of the usual DevOps, since mobile applications are primarily a convenient interface for interacting with external IT systems. The smaller scale of the team, and its specific problems specific to mobile applications (see Figure 1):
- - various platforms;
- - various devices.
1.3 Unified Documentation and Unified Language
In order for DevOps to work and there is real interaction between the teams, you need a single language and a single working documentation, understandable to all participants. Here, no approach provides clear guidelines, and the systems are all different. However, it is the documentation that lives with the project for the full life cycle and is a tool for communication and team interaction.
Figure 2. Working documentation
Competent working documentation can simplify and accelerate the development of the project. This process is described in more detail in our Guide # 2 " Technical Design of Mobile Applications ".
Here we denote the main documents (see Figure 2):
- list of screens;
- map of transitions and states;
- a table of screens.
The use of cross-naming and numbering is important. That is what simplifies and speeds up the process of communication within the team. Also an important factor is the compliance “documentation-code”, which makes the communication of business with developers clear.
2. Features of Mobile CI / CD
So, we have decided on the interaction culture and working documentation and now we can move on to instrumental support in the form of a CI / CD pipeline. The more operations you manage to automate, the better.
2.1 Mobile Dev Problems
Mobile development has 3 distinctive problem areas:
- Various operating systems and their versions. The application should work correctly on a wide range of very different operating systems, each of which has its own characteristics and limitations.
- Different variants of the CPU architecture. Iron smartphones and tablets are constantly improving, but do not forget about the "old men" five years ago, which may be in the hands of your real users.
- Different screen resolutions devices. Regardless of the number of pixels or aspect ratio, the interface of the mobile application should be correctly displayed on all devices.
In general, testing and debugging on a large fleet of real devices is indispensable.
2.2 What can be tested automatically
In actual practice, it is impossible to do without manual testing on smartphones or tablets. However, part of the code is easily covered by automatic tests based on Unit Testing (hereinafter referred to as unit tests). Let's look at the typical architecture of most applications - Figure 3.
Figure 3. Classic three-tier architecture
It is wiser to carry out a complete test coverage in two directions:
- unit tests (functional, integration) for the Data Access Layer or Repositories.
- UI tests (functional, regression) for Business Logic and User Interface layers.
It is not possible to cover all unit tests in mobile applications, plus it reduces the speed of development and system updates. For the automatic unit-testing phase of the CI / CD pipeline, it will be useful to cover the following DAL layer mechanisms:
- methods for accessing the Backend API;
- data access methods (Repositories);
If we talk about automatic UI tests, we can test the following:
- application performance on real devices with the desired characteristics;
- ability to execute key business scenarios.
Based on the results of the UI tests, screenshots are collected with each step on each device, and based on them, the QA engineer in manual mode can review the correctness of the application layout at different resolutions and screen sizes.
Convenience, smooth animations and other user characteristics are difficult to outsource autotests, they are best left to live testers and beta users.
The end of the introductory fragment.
Useful materials
Mobile DevOps book in practice
The full digital version of the “Mobile DevOps in Practice” paper guide .
Video materials of the Mobile DevOps in practice class (4 parts for 3.5 hours)
Part 1
Part 2
Part 3
Part 4
DevOps Summit
I would like to discuss Mobile DevOps live or ask questions - I will be glad to see you at the Microsoft DevOps Summit on September 13 in Moscow ( registration ) or on DevOps Days on September 14-15 in Kazan ( more ).
As always, I will be grateful for the feedback and questions in the comments! Stay in touch!
about the author
Vyacheslav Chernikov - head of development at Binwell , Microsoft MVP and Xamarin Certified Developer. In the past, he was one of the Nokia Champion and Qt Certified Specialists, currently he is the Xamarin and Azure platform specialist. He came to the sphere of mobile in 2005, since 2008 he has been developing mobile applications: he started with Symbian, Maemo, Meego, Windows Mobile, then switched to iOS, Android and Windows Phone.
Articles Vyacheslav you can also read the blog on Medium .
Source: https://habr.com/ru/post/421465/
All Articles