чи Варто боятися DevOps-а сучасному QA



Ви чули про DevOps, але слабо уявляєте що це таке? Може бути, ви QA-інженер і вас лякає, що попит на вас може впасти з DevOps? Або ви розробник і хочете прокачати себе і свою команду до впровадження DevOps-а, але не знаєте, з чого почати? Відповіді під капотом.

На запитання відповідає Full-stack Engineer в компанії ZeroTurnaround, з-провідний російськомовного DevOps подкасту «Two Розробники One Ops» Сергій bsideup Єгоров (twitter.com/bsideup).

Сергій Єгоров:

"… Деплой, зміна інфраструктури, брак знань про різних частинах системи, прозорість доставки змін, складність локальної розробки, «боротьба з вогнем» після викочування на бойові сервера… по кожному з них DevOps дає відповіді та рекомендації"

Розгортання програми — це ціла наука
– Для початку поговоримо про DevOps. Чому ця ідеологія стала популярною за відносно короткий проміжок часу? Які її головні принципи?

– Я не вважаю, що DevOps — це щось принципово нове і узялося з нізвідки. Люди і раніше займалися тим, що зараз вважається канонами DevOps підходу. Інша справа — охоплення, адже якщо раніше великі компанії на пропозицію розробників брати участь в інфраструктурі пропонували їм піти на X Server, так як це звучало шалено і ризики були надзвичайно великі, то зараз, у тих же самих людей, є дуже великий козир в рукаві, і цей козир — досвід. Досвід інших команд, великих команд, рівня IT-гігантів. Правда, ризики нікуди не пішли, і шансів «надевопсить» — повно. Але, в цілому, тренд дуже хороший, вирішальний реальну проблему — проблему взаємодії команди, що займається розробкою і доставкою одного і того ж продукту.

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


… про головні принципи DevOps. Допомагайте один одному, чи що...

– QA вважається однією з складових DevOps. Чи коректно порівнювати їх між собою як дві різні методології і чому?

– Тепле з м'яким. DevOps — це методологія, в той час як QA — все ж процес отримання раннього фідбек про Ваш продукт і верифікації, що продукт відповідає вимогам, які до нього поставили. Тому й не коректно говорити «DevOps інженер», в той час як «QA інженер» — цілком собі посаду. На такі питання дуже легко відповісти, якщо слово «DevOps» замінити на «Agile». Погодьтеся, нерозумно звучить: «Давайте знайдемо аджайла!», «А скільки у вас в компанії аджайлов?». Наймають Agile тренерів. Команда слід Agile підходу. І тут так само.

– В чому ж принципова відмінність DevOps підходу від стандартного підходу в QA?

– З моєї власної практики — у DevOps підході люди починають більше писати інтеграційних тестів, скорочують цикли розробки. Continuous Delivery — цілком природний процес доставки змін в DevOps середовищі, а це опосередковано покращує ситуацію для QA, зменшуючи кількість змін в білдах, які йому потрібно протестувати. Звичайно, ціною збільшення кількості цих самих білдів, але тут вже питання балансу.


DevOps-методологія

Робота розробника не закінчується комітом, вона там тільки починається
– Як DevOps впливає на життя інженерів QA?

– Найчастіше, до QA приходить білд, який вже пройшов якийсь автоматичне тестування. А адже інтеграційне тестування дозволяє протестувати дуже хитрі випадки, які QA відтворити було б важко. DevOps дуже виділяється всіляких tooling-му, і QA в цьому питанні також не обходять стороною. Всілякі розподілені білд системи, паралелізація тестів. Я точно знаю, що деяким QA інженерам можливість піднімати оточення для тестування, максимально близькі до бойових — на вагу золота, адже це цілком природно для DevOps підходу, те, до чого прагнеш.

– Найчастіше в DevOps використовується Continuous Delivery, для якого характерний швидкий темп викочування нових релізів і деплоя. Не перетворюється це в підсумку в «щурячі перегони», коли одна людина займається написанням коду, і тестуванням, і адміністративними функціями?

– Ну, якщо Ви у себе в команді наймаєте «DevOps-інженера» — то перетворюється. До тих пір, поки DevOps будуть пов'язувати з конкретними людьми — то ситуація буде виглядати приблизно так, адже попит буде йти з цих конкретних людей. А от коли у вас вже команда «просочилася» DevOps-му — то выкатыванием займаються всі разом. Адже, нагадую, робота розробника не закінчується комітом, вона там тільки починається. Довести свої зміни до кінцевого користувача — ось це мета кожного.

– Основним інструментом DevOps є всіляка автоматизація. Як результат — запуск такого процесу стає дорогим. Існує межа, до якої використання DevOps не виправдовує себе? Від чого це залежить?

– Думаю, навпаки. DevOps дозволяє зробити швидкий старт, а потім закрутити гайки. Деплоить прототип продукту через годину після хакатона руками з машини розробника простим скриптом, а потім вже налаштовувати автоматизацію, наприклад. Тут дуже важливо дотримуватися підходу MVP — Minimum Viable Product. Це не коли «ми налаштували крутий CI сервіс, скалируемый, красиві пайплайны намалювали, але збірка у нас йде через shell скрипт і виклики javac». Треба всього потроху, і покращувати, коли один з шарів доставки продукту починає сильно відставати від інших.

Головне, щоб команда в цілому була здатна впоратися з будь-якою ситуацією
– чи Підвищує DevOps вимоги до кваліфікації учасників процесу?

– Боюся, що так. DevOps увібрав в себе дуже багато кращих практик, але не всі їх розуміють на достатньому рівні. Наприклад, відкрийте 12factor.net/ru/ від 2012 року і пройдіться по цих 12-ти простим пунктів. Дуже добре визначає готовність розробника перейти на DevOps процес, його здатність писати сучасні сервіси, природні для DevOps.

Але, є і хороші новини — завдяки популяризації DevOps, матеріалу просто неміряно, і підвищувати кваліфікацію в даному набагато простіше, ніж, наприклад, років 10 тому.

– DevOps — це «безшовне» з'єднання декількох відділів. Чи означає це спрощення логістики всередині компанії? Як це позначається на роботі компанії в цілому?

– Я, чесно кажучи, погано собі уявляю DevOps команду з 100 чоловік, наприклад. Набагато ефективніше розбивати відділи на маленькі команди, чоловік з 10, але при цьому команди повинні бути крос-функціональні, тобто мати всіх потрібних людей для виконання поставленого завдання. Хто часто плутає це з тим, що «у кожній команді має бути по людині кожного напряму» — це не так. Люди багатогранні за своєю натурою, і DevOps лише підтверджує це, тому один і той же чоловік в команді може розробляти і налаштовувати інфраструктуру, наприклад. А інший — любитель покодить плагіни для Jenkins-а, і взагалі добре розбирається в системах складання. Головне, щоб команда в цілому була здатна впоратися з будь-якою ситуацією, будь то створення сховища для зберігання коду, налагодження білд системи, розгортання кластера в продакшені, реагування на нотифікації систем моніторингу.

– DevOps сильно виділяється своїм набором необхідних інструментів? Що в них особливого?

– Ну, дай розробнику займатися серверами, і він не буде ними займатися. Він буде розробляти для серверів. Розробники… вони ліниві, а значить хочуть все автоматизувати, от і виходить що з популяризацією DevOps з'явилася величезна безліч різноманітних систем, або їх реінкарнації. Ось візьміть Kubernetes — лідер оркестрации сервісів, практично жодна розмова про DevOps (включаючи цей) не обходиться без згадки. Але хіба це щось нове? Ні, Google реалізували лише «для всіх» свій Borg, який вони використовували більше десятка років.

Не можна не згадати Docker — адже теж, нічого нового, контейнери існували дуже давно, але саме простота використання таких складних систем зробила його таким популярним на хвилі DevOps.

Універсальних інструментів не існує як таких. DevOps — він не тільки про інструменти, не можна просто сказати: «візьміть це, це і це — і буде вам DevOps».

Залежить від Вашого продукту і оточення, в хмарі Ви або на своїх серверах. Можу лише сказати, що явний лідер інструментів DevOps — це автоматизація, як розробки і тестування, так і доставки змін. З'явилося багато систем оркестрации зразок Mesos, Kubernetes, Docker Swarm та інших, які дозволяють вам працювати з Вашою інфраструктурою через API, вони дуже допомагають автоматизувати ту частину, яку часто помилково вважають «ось це і є DevOps». Інструменти, що перетворюють ваші сервера в безлике «стадо», де проблемний сервер простіше створювати, замість турботи про кожному сервері окремо.

– Які проблеми існують у сучасному DevOps-е?

– Думаю, legacy — це одна з найбільших проблем. «Ми тут наш монолітний EAR намагалися запхнути в Docker-контейнер з WebSphere, і чого-то не пішло, не працює Ваш DevOps» — цілком популярний вислів. DevOps допомагає уникнути багатьох проблем в розробці, але він не вирішує більшість із них, якщо вони вже є.

Думаю, також нелегко знайти людей, які організували б DevOps-команду ефективно. Від таких людей потрібно йти в ногу з сучасними технологіями (а без цього нікуди, оскільки більшість DevOps-технологій — молоді), при цьому мати досвід організатора. Пам'ятаєте фразу про 10х-розробника? «Той, хто допоможе іншим 5-ти бути в 2 рази продуктивніше». Думаю, це дуже добре описує людей, які просувають DevOps у своїй команді. І це часом дуже нелегко, змінювати підходи інших людей, доносити до них значущість тих змін у процесі, що несе з собою DevOps. Правда, результат частіше всього виправдовує засоби, і успішні DevOps-команди найчастіше згадують свій старий процес «як у страшному сні».

– Розкажи про те, як відбувається впровадження DevOps в роботу компанії? З чого все починається і як зрозуміти, що всі «запрацювало»?

– Кожна команда знає проблеми свого процесу. Зрештою, DevOps як концепція виник із-за проблем процесу, однакових проблем, в різних компаніях.

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

– У червні 2016 року на сайті devops.com вийшла стаття «How DevOps is Killing QA», в якій говориться, що DevOps не потребує QA. Як ви можете прокоментувати таку точку зору?


Статистика пошукових запитів у Google «sqa jobs» і «devops jobs»

– QA як процес нікуди не дінеться. Так, з'являється все більше і більше автоматизації тестування, стає простіше робити A/B тестування на реальних користувачів, але ось яка справа… Програміст завжди чекає, що код повинен працювати. Тому, коли програміст тестує свій код, він не очікує від нього іншої поведінки, він пише тести, щоб переконатися, що його код працює. Хороший QA інженер, в свою чергу, не бачить код, він бачить продукт, він думає про те, що з продуктом можна зробити, що не можна, і перевіряє, що продукт відповідає специфікації. Так що скільки б тисяч тестів у вас не було написано, якщо вони всі написані програмістами — у вас завжди будуть баги. Так що QA, адміни і всі інші, Ви можете спати спокійно, адже Ви потрібні DevOps, при цьому в ньому від Вас очікують робити саме те, в чому Ви так гарні та унікальні.




А поки DevOps не просяк всі команди в світі, радимо відвідати конференцію Гейзенбаг 2016 Moscow, на якій будемо обговорювати всілякі проблеми тестування, не тільки для тестувальників. Цікаво буде і розробникам, і техлидам:

Список доповідей:

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.