DevOps акронім від англ development і operations низка практик призначених для пожвавлення взаємодії розробників із фахі

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цілі

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

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

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

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

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

Переваги DevOps

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

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

Примітки

Debois, Patrick (2009). . DevopsDays. Архів оригіналу за 24 березня 2011. Процитовано 31 березня 2011.
Debois, Patrick. . DevOps Days. Архів оригіналу за 8 листопада 2011. Процитовано 31 березня 2011.
. Архів оригіналу за 12 січня 2018.
Theakanath, Thomas. . devops.com. Архів оригіналу за 27 травня 2016. Процитовано 25 жовтня 2017.
. Puppet Labs. Архів оригіналу за 29 січня 2016. Процитовано 22 жовтня 2015.
Humble, Jez; Farley, David (2011). Continuous Delivery: reliable software releases through build, test, and deployment automation. Pearson Education Inc. ISBN .

[devopsdaysghent-1] Debois, Patrick (2009). . DevopsDays. Архів оригіналу за 24 березня 2011. Процитовано 31 березня 2011.

[devopsdays-2] Debois, Patrick. . DevOps Days. Архів оригіналу за 8 листопада 2011. Процитовано 31 березня 2011.

[3] . Архів оригіналу за 12 січня 2018.

[4] Theakanath, Thomas. . devops.com. Архів оригіналу за 27 травня 2016. Процитовано 25 жовтня 2017.

[5] . Puppet Labs. Архів оригіналу за 29 січня 2016. Процитовано 22 жовтня 2015.

[CD_HJ-6] Humble, Jez; Farley, David (2011). Continuous Delivery: reliable software releases through build, test, and deployment automation. Pearson Education Inc. ISBN .