DevOps — швидкість? Так, швидкість

Якщо подивитися на дев'яності роки минулого століття, то вони дали велику кількість методологій (якщо комусь більше подобається фреймворків) розробки програмного забезпечення: FDD (Feature driven development), Scrum, Rup, XP. Але самими затребуваними виявилися не технічні підходи, орієнтовані на людей. У 2001 році це все призвело до появи Agile-маніфесту. Не треба нам якості, не треба нам підтримки змін, дайте нам швидко те, на що можна подивитися, а вже ми приймемо рішення, що робити далі. В даний час складається відчуття, що соціальні фактори себе вичерпали і для подальшого підвищення швидкості їх вже не вистачає. Підхід, що включає не тільки «про людей», але і «про технології», отримав назву DevOps. Давайте подивимося на що ще ми можемо виграти у швидкості поставки корисності.

image

Якщо подивитися на Agile-маніфест, на те, що входить в Scrum, Kanban, то там все про людей. Про взаємодію всередині команди, про взаємодію із замовником, про організаційні процеси. Ні, FDD і XP, які теж відносять до гнучких методологій, є і інженерні речі (хто, до речі, може відразу пригадати, що там з інженерного в FDD?). І це працює. Збираючи розумних людей в одному місці, даючи їм організаційні шаблони, допомагаючи організувати взаємодію із замовником можна отримати прийнятний, а часто і відмінний результат.

Тільки от, із зростанням складності розроблюваних систем з'ясовується, що не все так райдужно. Навіть розумним людям потрібні інженерні практики, щоб продовжувати видавати прийнятний результат в найкоротші терміни. Зрозуміло, що все вже придумано досить давно, взяти той же «Тест Джоела: 12 кроків до кращого коду», і виявити, що нічого винаходити не треба. Але чомусь до цих пір можна зустріти організації, в яких не використовуються білд сервера. І в рамках боротьби з цим перекосом у бік соціально-організаційних питань і з'явився DevOps. На відміну від інших методологій, у яких є родоначальники, а часто і цілі інститути, що займаються їх розробкою (PMBOK розробляє PMI, ITIL розробляє AXELOS, так і під Agile-манивестом, підписаним в лютому 2001 року в штаті Юта США, стоять конкретні прізвища), що таке DevOps досі викликає суперечки і непорозуміння. Ні, є стаття в вікіпедії, проводяться конференції, але формального опису, що входить в DevOps, з яким все співтовариство або хоча б більша частина розробників погодилася, немає.

Компанія Gartner спробувала провести систематизацію підходів, застосовуваних у DevOps:

image
*джерело зображення Gartner.

Як видно з картинки, DevOps включає в себе і те, за що ратує Agile: автономні, кросфункциональные команди; культуру довіри; спільні мітинги. Але при все при цьому, основний акцент робиться саме на технології. Чи Можете ви розгорнути свою програму в один клік? Чи використовуєте ви безперервну інтеграцію і тестування? Якщо на ці та багато інших питань, які можна задати по блокам з картинки, відповіді немає, то це є варіанти вдосконалення команд, процесів, продуктів в організації.

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

Або інфраструктура як код. Регулярно виникає проблема, що у розробника «лампочка горить», а в тестовій або навіть в продуктовій середовищу немає. Можливість зберігати інформацію про інфраструктуру на высокоуровневом мовою, можливість розгортати абсолютно ідентичні середовища за запитом, можливість редагувати та тестувати середовища, можливість мати версійність середовищ. Все це дозволяє істотно економити час розробників, тестувальників, експлуатаційників. А вже як це істотно знижує проблеми при реконфігурації продуктової середовища та викладення релізів.

Колеги, поділіться в коментарях, що ви використовуєте з наведених практик, щоб економити час? Або може у вас є щось не включене в схему Gartner, але реально дуже корисне? Так, якщо є бажання розповісти про це не тільки на Хабре, то можна зареєструватися в якості доповідача на DevOpsDays і обговорити ваш підхід ще і в особистому спілкуванні з людьми, яким це все дуже цікаво.
Джерело: Хабрахабр

0 коментарів

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