DevOps — новий рівень взаємодії груп розробки та експлуатації

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



Зрозуміло, багато компаній вже давно усвідомили неефективність подібної моделі випуску додатків і почали пошуки способів її оптимізації. Одним з таких способів є модель Agile, яка передбачає плідну взаємодію відділів розробки і тестування, що здійснюється згідно з загальними цілями, загальними правилами і загальними критеріями ефективності. При цьому відділ експлуатації все ще залишається «за рамками» моделі Agile. Якщо розробники і тестувальники зацікавлені в як можна більш швидкому створенні працездатного коду, помилок в якому немає, то експлуатація, як і раніше, не готова до нових підходів. Адже будь-яка зміна, що вноситься з появою нового програмного коду, загрожує потенційними аварійними ситуаціями та іншими небажаними інцидентами в роботі ІТ-інфраструктури. Існує ймовірність того, що з установкою нової версії програмного забезпечення, все просто «завалиться». Саме цього і побоюються фахівці служб експлуатації, і часто такі побоювання небезпідставні.

Необхідно усунути останню перешкоду між розробниками і тестерами, з одного боку, та службами експлуатації, з іншого. Це завдання покликана вирішити методологія DevOps, яка, по суті, розширює рамки Agile, залучаючи до них підрозділу з експлуатації, але не тільки. Її можна реалізувати і в традиційній класичній моделі розробки Waterfall. Можливі варіанти, коли одна частина команди працює по методології Agile, а інша — за Waterfall. При цьому перехід на DevOps дозволить врахувати загальні інтереси і критерії, щоб налагодити спільне ефективне взаємодія буквально всіх підрозділів — розробників, тестувальників і фахівців з експлуатації. Адже суть DevOps не тільки у формалізованих процесах, але в зміну культури розробки програмного забезпечення.

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

image
Ho DevOps складається не тільки з технологій. Не менш важлива роль відводиться взаємодії людей і процесів. За даними Gartner, опублікованими в кінці минулого року, 50% успіху проектів DevOps криється саме в людському факторі, 37% — у процесах, і тільки 8% — в технологіях. Найчастіше замовники сподіваються, що після установки та інтеграції всіх необхідних програмних продуктів у них запрацює DevOps, але подібні проекти провалюються найчастіше. Поки люди не стануть єдиною командою з загальними інтересами і критеріями ефективності, DevOps функціонувати не зможе. Поки фахівці з експлуатації не усвідомлюють свою відповідальність ще на етапі постановки вимог, а розробники не будуть відповідати за якість коду в експлуатації, методологія DevOps залишиться незатребуваною.

Що ж необхідно зробити для створення єдиної команди за правилами DevOps? Насамперед потрібно з'ясувати, як працюють співробітники, що їм допомагає, а що заважає. Існує чимало різних освітніх курсів з побудови DevOps, є такі курси і в HPE. Якщо в організації використовуються не тільки класичні Waterfall-підходи до розробки, але і методи Agile, слід подумати про масштабування всього процесу, в якому бере участь кілька команд. В якості найбільш ефективного інструменту для вирішення цієї задачі HPE рекомендує Scaled Agile Framework.

HPE активно готує і вже запустила частина навчальних курсів з оновлення та освоєння методології DevOps. Один з них, DevOps Awareness, доступний і в Росії; у ньому розповідається про загальні принципи методології та про спеціалізовані підходах компанії HPE. Крім того, для російських користувачів вже практично готові інші курси: поглиблений за DevOps, з його використання на практиці, а також з супутнім програмним продуктам.

Яку реальну економічну вигоду для замовника здатний принести перехід на модель DevOps? Методологічно вона базується на Scaled Agile Framework, який дозволяє обчислити переваги в рублях і відсотках при переході на DevOps з Waterfall, Agile і в разі змішаних варіантів. По суті, DevOps можна порівняти з автомобільним конвеєром, максимально швидко виводить готовий автомобіль від інженера до споживача. У порівнянні з Waterfall, приміром, у DevOps є незаперечна перевага: максимальне зниження ризиків при розгортанні завдяки автоматизації усіх процесів. При розробці моделі Waterfall приблизно третина всіх похибок обумовлена людським фактором: люди помиляються при внесенні змін, при підготовці інфраструктури і т. д. Найчастіше ці помилки виникають із-за того, що в різних підрозділів, що беруть участь у створенні програмного забезпечення, немає загальних інструментів і відсутня можливість ділитися отриманими знаннями. Ще один важливий момент — розмивання відповідальності, коли кожен спеціаліст відповідає тільки за свій вузький ділянку.

image
Тепер трохи про те, як реалізована продуктова підтримка DevOps. Спочатку в продуктах HPE Project Portfolio Manager і Service Manager відбувається планування змін. Сюди належать потреби і запити, про які повідомляє бізнес.

Крім того, за допомогою Service Manager служба експлуатації може повідомити, які зміни потрібно внести в програмний код для усунення конкретного інциденту, і ці зміни відразу ж трансформуються в завдання для Project Portfolio Manager. Ще один продукт, з якими інтегрується Project Portfolio Manager — HPE Agile Manager, в ньому завдання зв'язується з User story. Таким чином, призначивши завдання Project Portfolio Manager, ми можемо вказати, що ця задача буде реалізовуватися за гнучкої методології Agile Manager, тобто інтегруємо їх, і в результаті все User story Agile Manager відображаються в Project Portfolio Manager.

Наступний етап — розробка. Можна використовувати абсолютно будь-яке середовище розробки Visual Studio, Eclipse і т. д. Всі ці продукти теж інтегруються з Agile Manager і мають доступ до User Story. Розробник у звичному середовищі отримує повідомлення з Agile Manager про призначення йому тієї чи іншої User Story, після чого приймає її в роботу і починає змінювати програмний код у відповідності з поставленим завданням. Після зміни коду можна зробити контроль безпеки з допомогою HPE Fortify Static Code Analyzer і при необхідності здійснити інші допоміжні операції, а потім дати команду на виконання наступних операцій. Створений код зберігається у сховищі (Git або будь-якому іншому), після чого автоматично компілюється із збереженням артефактів компіляції. Одночасно відбувається оновлення універсальної бази даних управління конфігураціями (UCMDB), яка автоматично переходить на нову версію розроблюваного ПЗ. Всім цим процесом, як правило, «керує» Jenkins або інший Continuous Integration Tool — інтеграційна платформа, що забезпечує безперервність процесів розробки програмного забезпечення.

Далі Jenkins готує середовища для тестування. Тут можна використовувати HPE Codar, VMware, Docker або інші продукти. Найбільш поширені статичні тестові контури, які зміни вносяться в автоматичному режимі. При необхідності тестові середовища — як фізичні, так і віртуальні або змішані — можуть бути створені повністю «з нуля». Саме на цьому етапі вдається уникнути тієї самої третини конфігураційних помилок, що виникають при виконанні цієї процедури в ручному режимі. В тестові середовища вбудовується моніторинг, що дозволяє якомога раніше виявити можливі помилки. Надалі скрипти моніторингу будуть застосовані і в промисловому середовищі.

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

За словами багатьох замовників, цінність описаного підходу полягає в тому, що він дозволяє отримати повну картину розробки моделі — за участю всіх зацікавлених сторін, з чітко позначеними та інтеграційними процесами механізмами. На закінчення слід підкреслити, що стратегія Hewlett Packard Enterprise по відношенню до DevOps передбачає використання не тільки продуктів HPE, але і будь-яких інших рішень, адже головне, як вже говорилося вище, аж ніяк не технології, а люди і процеси.
Джерело: Хабрахабр

0 коментарів

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