DevOps

DevOps (акронім від англ. development і operations) — низка практик, призначених для пожвавлення взаємодії розробників із фахівцями інформаційно-технологічного обслуговування та зближення їхніх робочих процесів одне з одним. Ґрунтується на думці про тісну взаємозалежність між розробкою та використанням програмного забезпечення і має на меті допомогти організаціям швидше створювати та оновлювати програмні продукти та послуги.

Визначення та історія

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

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

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

Термін «DevOps» потрапив до широкого ужитку внаслідок серії зустрічей «DevOps Days», що спершу відбулися 2009 року в Бельгії^[1], а відтак поширилися на інші країни^[2]. Відповідна подія має відбутися в Україні у березні 2018 року^[3].

Набір інструментів

Позаяк DevOps — це командна робота (між співробітниками, що займаються розробкою, виробництвом і перевіркою якості), немає єдиного інструменту «DevOps»: це скоріше добірка (або «інструментальний ланцюжок DevOps») декількох інструментів. Як правило, інструменти DevOps вписуються в одну або декілька з цих категорій, що відображує ключові аспекти розробки та доставлення програмного забезпечення:^{[джерело?]}

1. Code — розробка та аналіз коду, інструменти контролю версій, злиття коду;
2. Build — інструменти безперервної інтеграції, статус складання;
3. Test — інструменти безперервного тестування, що повідомляють про бізнес-ризики;
4. Спакування — репозиторій артефактів, попереднє встановлення програми;
5. Release — керування змінами, офіційне затвердження випуску, автоматизація виробництва;
6. Конфігурація — конфігурація та керування інфраструктурою, інструменти коду інфраструктури;
7. Моніторинг — відстеження продуктивності застосунків, досвід роботи з кінцевим користувачем.

Попри наявність багатьох інструментів, деякі їхні різновиди мають вкрай важливе значення для налаштування інструментальних засобів DevOps з метою дальшого використання в організації. Деякі спроби ідентифікувати ці основні інструменти подибуємо в наявній літературі.^[4]

Такі інструменти, як Docker (контейнеризація), Jenkins (безперервна інтеграція), Puppet (інфраструктура як код) і Vagrant (платформа віртуалізації) і багато інших часто використовуються і згадуються у дискусіях стосовно інструментів DevOps.^[5]

Порівняння Agile з безперервною доставкою

Agile і DevOps схожі, але Agile являє собою зміну мислення і практики (що має привести до організаційних змін), а DevOps приділяє більше уваги впровадженню організаційних змін для досягнення своєї мети.^{[джерело?]}

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

Безперервна доставка і DevOps мають на меті дещо спільне і часом поєднуються, та все ж існує певна різниця. DevOps має ширший простір застосування й зосереджений навколо:

1. Організаційних змін: зокрема, для підтримки тіснішої співпраці між різними типами працівників, які займаються постачанням програмного забезпечення;
2. Розробників;
3. Операцій;
4. Гарантії якості;
5. Керування;
6. Системного адміністрування;
7. Адміністрування бази даних;
8. Координаторів;
9. Автоматизації процесів постачання програмного забезпечення.^[6]

Безперервна доставка — це підхід до автоматизації доставлення програмного забезпечення, який зосереджено на:

1. Об'єднанні різних процесів;
2. Виконанні їх швидше та частіше.

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

Цілі

Конкретні цілі DevOps охоплюють весь процес постачання програмного забезпечення. Вони включають:

1. Скорочення часу для виходу на ринок;
2. Зниження частоти відмов нових релізів;
3. Скорочення часу виконання виправлень;
4. Зменшення кількості часу на відновлення (у випадку збою нової версії або іншого відключення поточної системи).

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

Інтеграція DevOps призначена для доставлення продукту, безперервного тестування, тестування якості, розробки функцій, оновлень обслуговування для підвищення надійності та безпеки, і забезпечення більш швидкого циклу розробки та розгортання.^{[джерело?]}

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

Переваги DevOps

• значне скорочення часу виходу на ринок,
• підвищення якості продукції,
• надійніші релізи,
• підвищення продуктивності та ефективності,
• збільшення здатності створювати правильний продукт шляхом швидкого експериментування.^{[джерело?]}

Дослідження 2200 ІТ-керівників і фахівців галузі, оприлюднене у січні 2017 року, засвідчило, що лише один з п'яти опитаних вважає, що DevOps має стратегічний вплив на їх організацію, попри дедалі більше поширення. Відповідно до того ж опитування, лише 17% визнали DevOps за ключовий інструмент.^{[джерело?]}