Різниця між DevOps та управлінням конфігурацією програмного забезпечення

Чим відрізняються операції з розробки та управління конфігурацією програмного забезпечення?

Для мене, здається, це те саме, що і DevOps, і Управління конфігурацією програмного забезпечення зосереджені на:

1. Створення інфраструктури розвитку - відповідальність за контроль версій, управління побудовою, управління розгортанням, управління залежностями, постійну інтеграцію та доставку тощо.
2. Використання кращих практик організації середовища розробників .
3. Забезпечення якості процесів розробки - збір показників ефективності розвитку, робота над усуненням вузьких місць процесу розробки (проведення одиничних тестів, оцінка покриття одиничних тестів, проведення перевірок тощо)
4. Управління інфраструктурою - цільові платформи та її специфіка.
5. Управління випуском - переконайтеся, що випуск був доставлений клієнту / клієнту вчасно.

Можливо, мені чогось не вистачає? Це посилання показує, що вживається термін "Управління конфігурацією програмного забезпечення". Але все ж, яку комбінацію слів ви б краще використати для опису переліченого спектру видів діяльності: операції з розробки або управління конфігурацією програмного забезпечення ?

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

З іншого боку, Управління конфігурацією програмного забезпечення є набагато більш усталеним терміном у цій професії і походить від конкретного програмного терміну " Конфігурація управління" . Управління конфігурацією програмного забезпечення часто посилається в контексті інженерії програмного забезпечення, просте визначення Роджер Прессман дає в "Інженерія програмного забезпечення: підхід практикуючого" :

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

Хоча всі терміни, на які ви посилаєтесь, розпливчасті, DevOps представляється лише менш формальним способом опису більш-менш того самого принципу, що і управління керуванням конфігурацією або управлінням конфігурацією програмного забезпечення, якщо розглядатись з точки зору розробника програмного забезпечення, особливо пріоритетно ставлячи до щільно з'єднаних команд :

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

У цій же статті відмічено схожість з SCM:

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

Що стосується використання термінів, то ваше порівняння насправді не має сенсу:

1. SCM - це підмножина CM, а не конкурентний термін,
2. DevOps - це досить новий термін, який не має сенсу порівнювати із встановленими термінами,
3. DevOps походить від операцій розробників (очевидно), але рідко розширюється як такий.

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

Я вважаю, що найкращим способом описати розподіл цих ролей є зосередження уваги на їх відносності до взаємодії. Це означає, що Управління конфігурацією програмного забезпечення фокусується на внутрішніх системах та середовищах, а також на інтеграції, розгортанні, випуску та керуванні вихідним кодом. Де розробники (DevOps) зосереджуються більше на операційному аспекті зовнішньої архітектури додатків, зберігаючи чітке розуміння коду, яким він був призначений для використання та практики його оточення. Якщо продуктивність машини демонструє ознаки деградації, зв’язок між декількома додатками є несправним, обмеження в спілкуванні бізнес-бізнес (BtB) та / або архітектура стосовно виробничого середовища, то ви зверніться до операторів розробника для їх діагностики та рішення.

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

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

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

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

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

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

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

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

Підводячи підсумок, SCM з'єднує Dev і Ops.

Я бачу, що DEVOPs знаходиться в кінці оперативного виконання - сценарії автоматизації розгортання, побудови середовища, подібне. З іншого боку, SCM - це про цілісність продуктів та ефективне управління та простеження змін змін у продуктах. Я завжди розглядав ALM як частину SCM - врешті-решт, як же ви зможете керувати змінами продукту, якщо ви не маєте уявлення про драйвери для змін або хто їх вніс? Рамки розгортання можуть впасти з будь-якої сторони - і яка сторона буде незмінно залежати від регуляторних потреб організації, в якій ви працюєте, - зрештою, чи хочете ви, щоб розробник міг зробити швидкий злом, що означає, що ваш діалізний апарат працює належним чином 99,99% того часу, чи вам потрібна така ситуація, щоб ви могли зламати код свого веб-сайту, оскільки ваші розробники мають жорсткі коди IP-адреси?