DevOps означає, що розробники тепер беруть на себе відповідальність за інфраструктуру та випуск - але які драйвери стоять за цією зміною?

DevOps означає, що розробники тепер беруть на себе відповідальність за інфраструктуру та випуск - але які драйвери стоять за цією зміною?

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

Але галузь рухається в цьому напрямку, тож які причини цього? Які проблеми спричинили "стара" модель спеціалізації ролей?

Основна причина - хмара.

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

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

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

Я скептично ставлюсь до того, що розпродаж варто того, наскільки часто це роблять люди.

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

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

Програмне забезпечення проти апаратних питань
Пригадайте мультфільм Про помилок Бані, де Багз і Даффі сперечаються, чи це сезон качок чи сезон кроликів? Тепер уявіть, що ми замість цього зробили це з розробниками та операціями, де розробники стверджують, що це апаратне питання, а операції стверджують, що це проблема програмного забезпечення. Для кінцевого споживача це відмінність без різниці. Вони просто хочуть, щоб це було виправлено.
Об’єднуючи розробників та операції, їм доведеться виправляти проблеми. І може виявитися, що це проблема програмного та апаратного забезпечення.

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

Очікування / перевернення
З DevOps обидві спеціальності вивчать деякі навички, традиційно виконувані іншим. Ніхто не очікує, що системний адміністратор стане інженером програмного забезпечення, а розробник - інженером мережі, але, як очікується, обидва візьмуть на себе інші обов'язки. Це означає, що коли вам справді потрібні додаткові руки, вони там є.

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

Якість написання коду просто недостатньо. Ви або частина проблеми, або частина рішення.

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

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

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

Це щось, що пішло рука об руку з Agile & Scrum. Більше немає чітко визначених робочих ролей - кожен - «розробник».

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

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

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

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

Я впевнений, що розробникам також можна керувати операціями та контролю якості (іноді) є декілька вагомих причин . Ось три з них:

• Інтерес
  Деякі розробники насправді хочуть працювати над усіма аспектами продукту. Якщо вони в цьому хороші і якщо вони заповнюють порожнечу в команді або надають хорошу підтримку існуючим членам команди в інших ролях, можливо, не буде жодних причин зупиняти їх.
• Вартість
  Великі компанії можуть дозволити собі спеціалізованих працівників. Малі компанії іноді не можуть. Деякі з цих місць можуть найняти 1 або, можливо, 2 або 3 розробників, які повинні мати можливість просто дістати робочі речі з дверей.
• Розмір проекту
  Не кожен проект є проектом для багатьох людей. Якщо ви будуєте "невелику" програму, можливо, просто зайвим буде працювати більше 1 людини. Більше того, малі проекти з багатьма особами, які виконують конкретні ролі, страшно . Ніхто не має достатньо роботи - навіть якщо ви можете дозволити собі тримати їх навколо, щоб закрутити великі пальці протягом 6 місяців, хороші не залишаться. Якщо їм не набридне, вони злякаються, або ви зрозумієте, що платите зовсім небагато. Так чи інакше, ваші хороші співробітники залишатимуть і скажуть усім триматися подалі від вас.

... І інші причини, я впевнений.

"Необхідно турбуватися про інфраструктуру та випуски, а також щодо якості та пов'язаної з цим церемонії - це відволікання від написання хорошого коду"

По суті, я думаю, що DevOps стверджує, що турбуючись про інфраструктуру та випуски та QA IS пише хороший код.

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

Тепер ви можете стверджувати, що розширена спеціалізація як на Dev, так і на Ops дозволяє нам подолати деякі з них, але все-таки багато можна вирішити лише шляхом обміну знаннями та роботи між нашими командами.

DevOps не повинен означати "Dev тепер також Ops". Спочатку термін означав " люди Dev і Ops тісно працюють разом в одній команді". Це робить означає , що Ops люди повинні стати більш схожим Devs, тому що автоматизація речей вимагають свого роду програмування, а старий ручний спосіб не ріже його (див інших відповідей на більш детальне опрацювання з цього питання).

З Вікіпедії :

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

Тож, на мою думку, насправді, якщо ви як розробник несете ті самі старі обов'язки та додатково зараз оперативні обов'язки, це здається прорахунком з боку управління. Автоматизуючи речі, цілком можливо, що вам буде потрібно менше людей, що обслуговуються, і, таким чином, фактично можна заощадити кошти. Але DevOps, безумовно, не означає: "Позбудьмося всіх людей Ops та дозвольте Devs на додаткову роботу".

Як це часто трапляється з Buzzwords, трапляється семантична дифузія , і раптом люди думають: "Давайте також зробимо Devs робити Ops, і я думаю, ми можемо заощадити гроші ..."