Я робив / створював багато презентацій, пов'язаних з SCM, і зараз я намагаюся "оновити" його наступником DevOps.

Те, що я завжди намагаюся зробити в своїх презентаціях, - це створити слайд вступу, який якимось чином включає повідомлення, яке я хочу передати (і яке потім я детально розробив у решті своєї презентації). Роблячи це, я намагаюся відповісти на власне запитання на кшталт "Що б мені було 1 - 3 фрази, які я хотів би використати, якби отримав від 10 до 20 секунд (тільки!), Щоб пояснити це комусь новому? * ".

Я думав, що знаю, що насправді означає DevOps і про що йдеться. Але я бачив деякі химерні звички / контексти DevOps (навіть на DevOps.SE ...). Мене змушує замислитись, чи, можливо, те, що, на мою думку, є DevOps, абсолютно неправильно.

Отже, що, як правило, погоджується з визначенням DevOps?

DevOps в двох словах

З Вікіпедії :

DevOps (відрізаний склад " програмного забезпечення DEV elopment " та " інформаційних технологій OP eration S ") - це термін, що використовується для позначення набору практик, що підкреслюють співпрацю та спілкування як розробників програмного забезпечення, так і фахівців з інформаційних технологій (ІТ) під час автоматизації. процес доставки програмного забезпечення та зміни інфраструктури.

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

З огляду :

Діаграма Венна, що показує DevOps як перетин розвитку (інженерія програмного забезпечення), операцій та забезпечення якості (QA)

Хоча для DevOps не існує єдиного "інструменту", а набору інструментів, також відомого як інструментальний ланцюг DevOps :

Ілюстрація, що показує етапи в інструментальній ланцюжку DevOps

Ілюстрації DevOps

Нижче наведено кілька цитат з деяких питань на DevOps.SE , які, здається, так чи інакше відповідають / підтверджують частину опису DevOps, описаного вище:

• Від ' Яка різниця між SRE і DevOps? ':

  ... DevOps - це підтримка коду ...

• Від ( відповідь до) " Як я найняв хороший DevOps, який відповідає моїй компанії? ':

  ... Поширена думка, що DevOps - це роль у компанії. Слово лише позначає організаційну зміну в програмних компаніях ...

• Від ' Чи потрібно моїй організації прийняти Agile Soft. Дев. перед прийняттям DevOps? ':

  ... Є ще організації, які не практикують Agile у розробці програмного забезпечення, які можуть бути зацікавлені у прийнятті DevOps ...

DevOps НЕ роль

Нижче наведено кілька цитат з деяких питань на DevOps.SE , які, здається, ілюструють, що DevOps НЕ є роллю:

• З ( відповідь на) " Яка різниця між Sysadmin та DevOps Engineer? ':

  ... DevOps - це не роль (коли використовується як така, це швидше модна мова, ніж реальна роль).

• З ( відповідь до) " Як я найняв хороший DevOps, який відповідає моїй компанії? ':

  ... Поширена думка, що DevOps - це роль у компанії. Слово лише позначає організаційну зміну в програмних компаніях ...

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

Шаблони організації

Анти візерунки DevOps:

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

• Міст DevOps - саме тут одна або декілька команд покладаються на відповідальність за прийняття роботи у команд розробників і « продукують » її, щоб зробити її функціональною. Проблема зводиться до того, що зараз є два хенд-мени, тобто розробка → DevOps і DevOps → Операції.

• Команда DevOps - це, мабуть, може працювати, якщо команда несе відповідальність за створення інструментів, що підтримують операційну модель, що підтримує DevOps, однак її, мабуть, слід назвати "Команда інструментів" або "Команда платформ".

Шаблони DevOps:

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

• Інституціоналізований DevOps - де проектна команда спільно відповідає як за розробку, так і за функціонування пакету програмного забезпечення спільної власності та позитивних зворотних зв'язків.

Практики

Фактична практика DevOps ґрунтується на кількох інших практиках, а саме:

• Спритна доставка
• Постійна інтеграція
• Постійна доставка
• Безперервне розгортання

Кожен з перерахованих вище методів спирається на іншому, то можна НЕ брати до уваги практику, однак, це означає важливий цикл зворотного зв'язку відсутня , який може свідчити про «втрачені можливості». Ключовим диференціатором дотримання будь-якої іншої практики та DevOps є функціонування програмного забезпечення у виробництві .

Три шляхи

У проекті «Фенікс» Джин Кім та його співавтори описують це три способи DevOps :

Система мислення

Перший шлях наголошує на ефективності всієї системи, на відміну від виконання певного робочого силосу або відділу - це може бути настільки великим підрозділом (наприклад, Операції з розробки або ІТ) або настільки ж невеликим, як окремий учасник (наприклад, , розробник, системний адміністратор).

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

Підсилення циклів зворотного зв'язку

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

Я, як правило, досягаю цього за допомогою постійної інтеграції / доставки / розгортання та спільного моніторингу та оповіщення, тому це дуже добре вписується в інструменти компонент DevOps.

Культура постійного експериментування та навчання

Третій шлях - це створення культури, яка виховує дві речі: постійне експериментування, ризикування та навчання від невдач; і розуміння того, що повторення та практика - необхідна умова оволодіння.

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

Я чув багато-багато різних визначень DevOps. Вони включають:

• Розробники, що працюють з операційними завданнями
• Одна людина, яка виконує вдвічі більше роботи (за одну і ту ж кількість часу)
• Розробники та операційні групи, що працюють один з одним
• Операції працюють з інструментами для розробників (у руслі "Web Ops")
• Назва роботи для того, хто створює та підтримує інструменти для розробників
• Використання автоматизації в операціях
• Використання громадських хмар в операціях
• Робота, яка поєднує аспекти діяльності, розвитку та забезпечення якості
• Робота, яка тягне за собою допомогу командам з розвитку та операцій працювати разом
• Філософія подолання бар'єрів між командами
• Трактування інфраструктури як коду
• Що ви отримуєте, коли колишні інженери програмного забезпечення переходять до операцій
• Цілком безглуздий казковий слово

Не існує суспільного консенсусу щодо того, що насправді є DevOps . Кілька років тому у нас були подібні проблеми з "Agile", і це має письмове визначення .

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

Визначення, яке я завжди використовую в цій ситуації, таке:

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

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

У наступному науково-дослідному дослідницькому документі для вивчення саме цього питання "Що таке DevOps" запропоноване визначення похідного DevOps таке:

DevOps - це методологія розробки, спрямована на усунення розриву між розробкою (Dev) та операціями (Ops), підкреслюючи комунікацію та співпрацю, постійну інтеграцію, забезпечення якості та доставку з автоматизованим розгортанням, використовуючи набір практик розвитку.

[Джаббарі та ін.] "Що таке DevOps ?: Систематичне картографічне дослідження щодо визначень та практик" (2016)

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

Найважливішою метою завжди повинно бути забезпечення того, хто приймає рішення, щоб прийняти рішення . Уявіть мобільний додаток вашого банку. Коли ви вимагаєте переказу, це відбувається, коли ви натискаєте кнопку. Ви прийняли рішення, потім прийняли рішення. Те ж саме і з вашими операціями. Коли відповідна особа вирішить, що якась робота готова до розгортання у виробництві, вона повинна мати можливість натиснути кнопку і "Правильні речі трапляються". Так само вони повинні мати всю необхідну інформацію, необхідну для прийняття правильних бізнес-рішень.

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