Завдання і передові методики DevOps для мобільних додатків

1. Що таке DevOps
2. DevOps для мобільних додатків
3. Завдання DevOps для мобільних додатків
4. Малюнок 1. Архітектура мобільного додатка LinkedIn
5. 10 передових методик DevOps для мобільних додатків
6. Теорія і практика DevOps
7. Безперервні інтеграція і поставка
8. Тестування і моніторинг
9. Поставка мобільних додатків
10. Висновок
11. Ресурси для скачування

10 передових методик DevOps для мобільного підприємства

В останні п'ять років багато галузей активно адаптуються до масового зміни поведінки користувачів бізнес-додатків, оскільки мільйони людей усього світу стали використовувати мобільні пристрої в якості основного засобу доступу в Інтернет. Це вирішальна зміна поведінки користувачів змушує підприємства розробляти мобільні канали для існуючих бізнес-додатків і планувати нові види додатків, здатні використовувати унікальні характеристики мобільних пристроїв. Як при інших великих змінах в ІТ-індустрії, перші роки цього переходу супроводжувалися бурхливою діяльністю щодо задоволення попиту і завоювання часток ринку без урахування стратегічних питань, таких як витрати на розробку додатків, зручність обслуговування, якість і безпеку. Сьогодні, коли ринок мобільних додатків стає більш зрілим і його пік спадає, саме час зайнятися комплексними питаннями розробки програмного забезпечення.

У статті описуються проблеми інтеграції мобільних додатків в корпоративну систему і наводяться 10 передових методик DevOps для мобільних додатків. Ми почнемо з огляду DevOps і опису конкретних проблем (і необхідності) інтеграції мобільних корпоративних додатків за допомогою DevOps. Потім ми представимо 10 передових методик реалізації DevOps в процесі, що поєднує безперервну інтеграцію, моніторинг, тестування і поставку мобільних додатків.

Що таке DevOps

DevOps - це не методика і не процес, а підхід, що гарантує безперервне постачання додатків, починаючи з розробки і закінчуючи експлуатацією. До появи DevOps підприємства зазвичай мали роздільні групи розробки та експлуатації. Відсутність взаємодії і співпраці між цими групами в чому перешкоджало зростанню та інновацій. Поділ розробки та експлуатації було неприємно для підприємств, що впровадили гнучку розробку, оскільки гнучкі методики на порядки збільшують число збірок нової програми при розробці, тестуванні та розгортання. Замість передачі нової збірки групі експлуатації з періодичність в кілька місяців розробникам доводилося створювати нові збірки кожні кілька годин і набагато частіше випускати версії-кандидати.

Розвиток DevOps почалося зі спроби груп розробки і експлуатації об'єднати зусилля для більш ефективного вирішення завдань безперервного постачання додатків. Первинною метою було "зрушення вліво" обов'язків фахівців з експлуатації, щоб якомога раніше залучити їх в життєвий цикл поставки додатків. Потім розробникам було рекомендовано писати код додатків, з огляду на проблеми експлуатації з самого початку. Фактично DevOps координує інтереси і знання менеджерів розробки та експлуатації за допомогою принципів економною розробки, підвищуючи ефективність процесу безперервної інтеграції та безперервного постачання.

IBM використовує комплексний підхід DevOps, визначаючи його як можливість підприємства здійснювати безперервне постачання програмного забезпечення, яка дозволяє клієнтам своєчасно реагувати на ринкові можливості і скорочувати час відгуку користувачів.

Ключовим поняттям цього визначення є безперервна поставка. Безперервна поставка означає автоматичне (і на вимогу) розгортання програмного забезпечення і середовища, в якій воно виконується, на будь-якому етапі життєвого циклу поставки ПО. При безперервної поставки можна розгорнути всі що завгодно - від простих змін конфігурації до постійних змін коду, схеми бази даних, середовища або всього стека ПО.

DevOps для мобільних додатків

DevOps використовує одні й ті ж базові принципи при написанні як корпоративних, так і мобільних Web-додатків. Групу мобільного розробки слід включати в процес впровадження DevOps на підприємстві, навіть якщо вона дуже мала або дотримується власного підходу до розробки ПЗ. Це особливо важливо при розробці мобільних додатків в якості інтерфейсу до існуючих бізнес-додатків і сервісів. Це також відноситься як до зовнішнього, так і до внутрішнього користування послугою.

Мобільні додатки, безпосередньо взаємодіють з корпоративними додатками і сервісами, повинні бути повноправними учасниками життєвого циклу DevOps. У міру додавання нових функцій в корпоративні додатки і сервіси їх можна плавно інтегрувати в мобільні додатки.

Завдання DevOps для мобільних додатків

Хоча базові принципи DevOps однакові для корпоративних і мобільних додатків, останні вимагають від DevOps вирішення специфічних завдань, а саме:

1. мультиплатформенна підтримка
   

   Мобільні додатки не мають єдиної цільової середовища. Більшість мобільних додатків призначений для декількох пристроїв, що означає роботу з різними технічними специфікаціями, версіями операційних систем і формфакторі. Добре відома фрагментація платформи Android, коли кожен виробник створює власну версію цієї операційної системи для своїх пристроїв (прикладами є Android для Nexus, Android для Kindle Fire і Android для Nook). Нові системи, такі як BlackBerry 10, Windows® Phone 8, Ubuntu і Firefox, продовжують фрагментацію ринку Android. Навіть iOS, яка спочатку була жорстко стандартизована, тепер має кілька варіантів. Додаток для iOS має підтримувати кілька версій iOS: формфактор iPhone 4S (і молодше), формфактор iPhone 5, формфактори iPad і iPad mini.

2. Мобільні додатки як корпоративний інтерфейс
   

   Зазвичай мобільні додатки, особливо категорій B2C (бізнес-споживач) і B2E (бізнес-співробітник), мають обмежену бізнес-логіку на самому мобільному пристрої. Мобільні додатки B2C і B2E служать інтерфейсом до одного або декількох корпоративних додатків, таким як системи обробки транзакцій, системи управління персоналом або системи залучення клієнтів. На малюнку 1 показано такий додаток з обмеженою бізнес-логікою на самому пристрої.

   Малюнок 1. Архітектура мобільного додатка LinkedIn

   

   джерело: блог LinkedIn Engineering

   Мобільний додаток LinkedIn являє собою інтерфейс до серверній платформі LinkedIn Platform, що містить програми та сервіси Профіль (Profile), Контакти (Connections), Групи (Groups). Мобільний додаток, яке використовується на декількох платформах як вбудоване або гібридне, має розроблятися і поставлятися разом з сервісами платформи LinkedIn Platform. Завданням DevOps є комплексний підхід до всіх програм підприємства та координація процесів і циклів їх складання і випуску.

3. Безперервні інтеграція і поставка

   У силу значної бізнес-мотивації на користь швидкої поставки мобільних додатків на ринок терміни їх розробки зазвичай дуже стислі. Типовий період від початку розробки до поставки становить від кількох місяців до кількох тижнів. Прагнення до прискорення поставки мобільних додатків призводить до впровадження методів гнучкої розробки в більшість успішних мобільних проектів.

   Безперервні процеси інтеграції та поставки є важливими елементами практично всіх гнучких проектів. Зміни додатки, що поставляються розробниками, повинні негайно застосовуватися для всіх цільових мобільних операційних систем. Для вбудованої або гібридної реалізації мобільного додатка потрібно виконати кілька різних збірок при кожній поставці набору змін розробниками. Для кожної підтримуваної мобільної середовища установка і конфігурація збірки різні. Швидше за все, для обробки збірок, призначених для кількох операційних систем, буде потрібно невелика ферма серверів збірки.

4. магазин додатків

   У більшості випадків мобільний додаток можна розгорнути на пристрої безпосередньо. Це необхідно робити через магазин додатків. Таку модель поширення додатків запропонувала корпорація Apple, заблокувавши свої пристрої з метою запобігання установки додатків розробниками і постачальниками безпосередньо. Цьому приклад наслідували й інші виробники пристроїв, наприклад, RIM.

   Магазин додатків додає додатковий асинхронний крок в процес розгортання, так як розробники не можуть виконувати розгортання оновлень програми на вимогу. Навіть в разі виправлення критичних помилок нові версії програми повинні пройти процедуру подання та розгляду. Замість безперервного постачання ми отримуємо поставку "відправ і чекай".

5. Розгортання за допомогою Pull, а не Push

   При традиційному розгортанні використовується модель Push, коли фахівці з експлуатації "виштовхують" нову версію програми, будь то Web-додаток або будь-яке інше серверний додаток. Однак оновлення мобільних додатків являє собою процес Pull ( "підтягування"), при якому в більшості випадків самі користувачі вибирають оновлення своїх додатків. Розробники мобільного застосування практично не керують тим, яку версію програми завантажує користувач на свій пристрій. З точки зору DevOps це означає, що серверні сервіси, з якими взаємодіє додаток, повинні підтримувати всі його попередні версії.

6. Безвідмовна робота додатків

   Ніщо так не шкодить бренду, як однозірковий рейтинг додатки, особливо якщо цей рейтинг відбивається в магазині додатків. Думка незадоволених користувачів як про платні, так і про безкоштовних мобільних додатках швидко стає відомим. Якщо скарги на проблеми з Web-сайтом направляються службі технічної підтримки, то скарги на мобільні додатки бачать всі користувачі магазину додатків. Щоб гарантувати якість мобільних додатків, необхідно виконати всебічне тестування їх функціональності, зручності використання і продуктивності.

10 передових методик DevOps для мобільних додатків

Для вирішення специфічних завдань мобільних додатків ми рекомендуємо 10 передових методик DevOps. Ці методики розділені на три групи можливостей:

1. Безперервні інтеграція і поставка.
2. Тестування і моніторинг.
3. Поставка мобільних додатків.

Мета полягає в використанні 10 кращих методик для створення конвеєра поставки, який дозволяє застосувати ці можливості одночасно з вирішенням завдань, специфічних для мобільних додатків.

Теорія і практика DevOps

Конвеєр поставки реалізує технічну сторону DevOps, проте так само важливі людські та культурні аспекти DevOps. Передові методики, описані в цьому розділі, призначені для того, щоб зробити групи розробки та забезпечення якості мобільних додатків повноправними членами спільноти DevOps на підприємствах. Комплексний підхід DevOps повинен враховувати вимоги і проблеми груп розробки мобільних додатків, що працюють в тандемі з групами розробки корпоративних Web-додатків і сервісів.

Безперервні інтеграція і поставка

1. Забезпечення можливості наскрізного відстеження всіх активів

   Значення відстеження всіх активів розробки та забезпечення якості більше не є предметом спору. Група розробки мобільних додатків повинна забезпечити наскрізне відстеження всіх активів: коду, конфігурацій, сценаріїв, інфраструктури як коду, сценаріїв тестування, проектної документації. Важливо також, щоб відстеження не обмежувалася активами мобільного розробки; воно повинно поширюватися на корпоративні додатки і сервіси, з якими інтегруються (а також до яких підключаються або мають доступ) мобільні додатки.

2. Реалізація безперервної інтеграції

   Методики гнучкої розробки вимагають безперервної інтеграції, яка означає виконання частих збірок і безперервної інтеграції нового коду з кодом, розробленим раніше іншими групами як для мобільних, так і для корпоративних додатків. Безперервна інтеграція означає, що код, що поставляється однією групою розробки, буде працювати разом з кодом і модулями, що поставляються іншими групами розробки. Для мобільних додатків інтеграція зазвичай виконується безперервно. Її також потрібно періодично виконувати для немобільних серверних компонентів, до яких звертається розробляється мобільний додаток.

   Групи розробки мобільних додатків спільно використовують централізовані сервери збірок і інтеграції коду для всіх цільових мобільних платформ. Автоматизація процесів розробки і збірки забезпечує швидку і надійну інтеграцію збірок, які виконуються на централізованих серверах (фермах серверів), для всіх підтримуваних платформ.

3. Використання окремих областей збірки і інтеграції для кожної підтримуваної версії SDK вбудованої мобільної ОС
   

   Фрагментація в області мобільних пристроїв не обмежується чотирма основними операційними системами - iOS, Android, Blackberry і Windows Phone. Кожна з цих платформ теж внутрішньо фрагментована. Apple розробила версії своєї iOS для iPad. Android має версії практично для кожного пристрою. Компанія RIM розробила нову операційну систему BlackBerry 10, що має небагато спільного з успадкованою BlackBerry OS. Windows Phone 8 серйозно відрізняється від попередніх версій Windows Phone. Спостерігається зростання ряду нових мобільних платформ, таких як Ubuntu і Firefox. В результаті розробники змушені писати кілька варіантів мобільного застосування для підтримки кожної цільової платформи і її варіантів, навіть якщо додаток призначений тільки для однієї платформи. Для кожного мобільного додатка необхідно мати кілька версій SDK.

   Щоб розділити код і специфічні можливості цільових платформ, розробникам потрібно підтримувати окремий потік розробки для кожної версії мобільної програми для конкретної платформи. Такий поділ вимагає використання окремих областей збірки і інтеграції для кожної цільової платформи. Наприклад, розробники Android-додатків повинні мати окремі потоки для Kindle Fire, Nook HD, Nexus і інших операційних систем.

4. Використання сценаріїв автоматизованого складання та розгортання

   Розробники мобільних додатків звикли використовувати IDE (інтегроване середовище розробки) при виконанні збірок вручну. Їм часто доводиться виконувати складання вручну і в деяких випадках для різних цільових платформ. У ситуації, коли складність і число збірок ростуть, розробники можуть використовувати сценарії для виконання автоматизованих збірок в міру необхідності на окремих серверах збірок. Сценарії управління збірками та привласнені версії гарантують, що будь-який член групи зможе відтворити будь-яку збірку в будь-який час.

Тестування і моніторинг

1. Ретельне, максимально автоматизоване тестування кожної збірки на змодельованих і фізичних пристроях

   В області автоматизації тестування розробка мобільних додатків відставала від розробки корпоративних додатків. Більшість розробників мобільних додатків виконує тестування на емуляторі, а не на фізичних пристроях. Навіть тестування на емуляторі найчастіше виконується вручну. Через швидкості і гнучкою природи мобільного розробки автоматизоване функціональне регресивний тестування є єдиним реальним способом забезпечення якості. Величезна різноманітність підтримуваних платформ і формфакторів унеможливлює ручне тестування в достатньому обсязі. Крім того, низька якість корпоративних додатків (як для клієнтів, так і для співробітників) є неприйнятним.

   Виконуйте тестування всіх додатків за допомогою інструментальних засобів автоматизації тестування на емуляторах, що надаються в SDK, і на всіх підтримуваних фізичних пристроях.

2. Віртуалізація та моделювання серверних сервісів, Які недоступні во время тестування мобільного додатка

   Наслідком вісокої швідкості розробки мобільніх Додатків є набагато більшу Кількість версій у порівнянні з серверного корпоративними Додатками и сервісамі. Швидка розробка может прізвесті до технічного віпередження мобільними Додатками корпоративних Додатків за рахунок Нових можливий, Які Ще не підтрімуються серверного корпоративними Додатками и сервісамі. Даже при наявності серверних сервісів їх тестування может Вимагати грошей або ресурсов. Например, использование сервісів SaaS даже для тестування зазвічай є платним (оплата за использование). Аналогічно, использование сервісів на основному комплекті System z оцінюється в MIPS. Для вирішенню цієї проблеми можна використовуват віртуалізацію (імітацію) серверних сервісів. Вся екосистема Додатків, сервісів и джерел Даних, з Якими Взаємодіє мобільний додаток, может буті представлена ​​у виде віртуальніх екземплярів, что імітують поведение реальної екосистеми. Такий підхід забезпечує швидке тестування мобільних додатків і їх взаємодії. Він також дозволяє економити ресурси обладнання, на якому виконуються реальні екземпляри сервісів і додатків.

3. Моніторинг продуктивності розгорнутих мобільних додатків і серверних сервісів

   Для розробників немає більшої проблеми, ніж мобільний додаток, яке добре працює в середовищі тестування і перестає працювати в реальних умовах. Основними причинами поганої продуктивності є ненадійна мережу, недолік пам'яті, недостатня потужність і втрата даних. Не всі ці причини можна передбачити і протестувати в лабораторії, тому вкрай важливо, щоб розробники могли виконувати безперервний моніторинг продуктивності додатків. Такий моніторинг може виконуватися або в додатку, або на сервері стека додатків, до якого цей додаток взаємодіє.

   Найгірше, якщо мобільний додаток відмовляє при його використанні в реальних умовах. Додавання в додаток логіки для збору діагностичної інформації в разі відмови (дані про місцезнаходження і характеристики пристрою) забезпечує розробника необхідними даними, що дозволяють знайти причину відмови і усунути її. Вбудована логіка фіксації і аналізу відмов є важливим компонентом мобільних додатків.

Поставка мобільних додатків

1. Централізоване управління мобільними профілями, сертифікатами і ключами API

   Відправляючи додаток в магазин додатків або використовуючи API внутрішнього або зовнішнього застосування, розробник (або компанія) визначає справжність і приналежність додатки за допомогою наданих постачальником ключа поширення або ключа профілю. Ці ключі використовуються для авторизації в магазині або API. Зазвичай індивідуальні розробники отримують свої власні ключі і використовують їх при розробці. Однак після випуску готового додатка необхідно замінити ці персональні ключі офіційними корпоративними ключами. Необхідно захищати корпоративні ключі і профілі і використовувати їх тільки для офіційних версій програми. Процеси управління мобільними додатками повинні бути добре визначені і керовані. В першу чергу слід обмежити доступ до корпоративних ключам. Авторизація - це питання конфіденційності та безпеки, що вимагає суворого управління.

2. Використання віртуального магазину додатків для тестування розгортання пристрої

   Мобільний додаток передається на мобільний пристрій тільки через магазин додатків. Перш ніж потрапити в магазин, додаток проходить ручний процес підтвердження. Як тільки додаток потрапляє в магазин, користувач повинен "придбати" його, після чого воно передається на пристрій користувача. Для тестування всього процесу група розробки може використовувати "закритий магазин розробки додатків". Такі віртуальні магазини додатків (див. Розділ Ресурси) імітують поведінку реального магазину додатків, дозволяючи розробникам ефективно тестувати процес відправки додатки в магазин і передачі його в пристрій.

3. Перетворення відгуків користувачів в запити на вдосконалення і призначені для користувача історії

   Мобільні додатки мають унікальним механізмом зворотного зв'язку, яким є магазин додатків, що дозволяє користувачам оцінювати додатки і залишати про них відгуки. Хорошу репутацію мають додатки з чотирьох- або п'ятизірковим рейтингом. Малопопулярні додаток, як правило, має одно- або двозірковий рейтинг і зазвичай супроводжується негативними відгуками. Для мобільних додатків, на відміну від інших платформ, петля зворотного зв'язку не існує як формально централізований механізм. Розробники зазвичай дізнаються про проблеми настільних додатків, тільки коли користувач звертається в службу технічної підтримки або залишає коментар на форумі розробників. Групи мобільного розробки повинні уважно стежити за відгуками і рейтингами в магазині додатків і використовувати відгуки в призначених для користувача історіях, при розширеннях і вдосконалення програмного забезпечення. Максимально використовуйте цю цінну інформацію для безперервного вдосконалення мобільних додатків.

Висновок

Не існує окремого підходу DevOps для мобільних додатків. Підхід DevOps працює для всіх додатків і компонентів - від інтерфейсних мобільних додатків до проміжного програмного забезпечення, серверних компонентів і сховищ даних. Застосовуйте методики і принципи DevOps для всіх груп розробки і експлуатації на підприємстві, щоб забезпечити безперервне постачання всіх цих компонентів.

Мобільні додатки мають специфічні вимоги і проблеми, які потребують особливої ​​уваги. 10 передових методик DevOps для мобільних додатків спрямовані на задоволення цих вимог. Метою описаних методик є приведення розробки, забезпечення якості та досвіду експлуатації мобільних додатків до стандарту корпоративних додатків. Використання цих методик дозволяє підприємству впровадити DevOps в групи мобільного розробки, постачати високоякісні мобільні додатки і виконувати безперервні удосконалення та інновації.

Ресурси для скачування

Схожі тими

• Оригінал статті: DevOps for mobile apps challenges and best practices (EN).
• DevOps для мобільного розробки (Майкл Роу (Michael Rowe), IBM developerWorks, вересень 2013): використання DevOps для безперервних процесів інтеграції та поставки мобільних додатків, особливо при розгортанні різних версій на різних пристроях (EN).
• Від ручної до безперервної автоматизованої розробки мобільних Worklight-додатків (Джоул Кейн (Joel Cayne) IBM developerWorks, лютий 2014 г.): посібник з використання IBM UrbanCode Deploy для визначення DevOps-розгортання мобільних артефактів IBM Worklight (EN).
• Використання Web-контенту в мобільних додатках за допомогою Worklight (Винод Аппайанна (Vinod Appajanna) і Стефан Хеппер (Stefan Hepper), IBM developerWorks, березень 2104 г.): реальні приклади використання метаданих Web-контенту та динамічних правил, які виконуються всередині IBM WebSphere Portal і IBM Web Content Manager, в мобільних додатках IBM Worklight (EN).
• Використання IBM Mobile Quality Assurance в управлінні якістю мобільних додатків (Лі Вільямсон (Leigh Williamson), IBM developerWorks, березень 2014 г.): застосування набору хмарних інструментальних засобів, що дозволяють розробникам виконувати тестування мобільних додатків в ручному режимі (EN).
• Тестування мобільних додатків за допомогою Rational Test Virtualization Server (Манджула Согі (Manjula Sogi), IBM developerWorks, січень 2014 г.): покрокове введення в наскрізне тестування мобільних додатків за допомогою Rational Test Virtualization Server, Rational Test Workbench і Rational Quality Manager (EN).
• Тестування мобільних додатків за допомогою IBM Rational Test Workbench (Прагаті Махешварі (Pragati Maheshwari), IBM developerWorks, серпень 2013): практичне запровадження в використання IBM Rational Test Workbench для тестування мобільних Android-додатків (EN).
• Початок роботи з IBM Worklight : Установка Worklight і початок роботи.
• Rational Test Virtualization Server : Середа для розгортання віртуалізованих сервісів, програмного забезпечення і додатків для простого і ефективного тестування.
• Відвідайте блог IBM developerWorks Mobile Frontier Blog и розділ Mobile development , Де можна знайти інші статті по даній темі.
• IBM Rational Test Workbench : Комплексне рішення для автоматизації тестування мобільних додатків, регресійного тестування, технологій інтеграції, а також тестування продуктивності і масштабованості.
• Rational Test Virtualization Server : Середа для розгортання віртуалізованих сервісів, програмного забезпечення і додатків для простого і ефективного тестування.
• IBM UrbanCode Release : Завантажте програмне забезпечення для планування, виконання та контролю версій на всіх етапах моделі життєвого циклу.
• IBM Mobile Quality Assurance : Безперервна поставка високоякісних мобільних додатків.
• IBM UrbanCode Deploy : Організація та автоматизація розгортання додатків, змін проміжного програмного забезпечення і змін бази даних в середовищах розробки, тестування та експлуатації.
• IBM Rational Test Virtualization Server : Видалення тестових залежностей програми дозволяє зменшити час установки і витрати на інфраструктуру.
• Worklight Developer Edition : Відкрита комплексна платформа розробки, призначена для створення, виконання та обслуговування вбудованих, гібридних і HTML5 мобільних додатків.
• Рішення IBM Rational для Collaborative Lifecycle Management : Підвищення продуктивності групи з використанням засобів інтегрованого управління життєвим циклом додатків (ALM).

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів