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

Коли я кажу про Agile Software Development, я маю на увазі будь-яке потомство, яке вийшло з Маніфесту розробки Agile Software . Такі як Extreme Programming , Scrum , Lean Development Software та інші.

Чи є розробка програмного забезпечення Agile обов'язковою умовою прийняття DevOps на рівні організації?

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

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

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

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

НІ

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

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

На конференції Agile 2008 Ендрю Клей Шафер та Патрік Дебуа обговорили "Agile Infrastructure". Це стало початком руху DevOps.

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

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

ІМХО цього не потрібно .

Від DevOps (міна акценту):

DevOps (відрізана сполука "програмне забезпечення DEVelopment" та "інформаційні технології OPerationS") - це термін, що використовується для позначення набору практик, що підкреслюють співпрацю та спілкування як розробників програмного забезпечення, так і фахівців з інформаційних технологій (ІТ) під час автоматизації процесу доставка програмного забезпечення та зміни інфраструктури. 1 [2] Вона спрямована на створення культури та середовища, де створення, тестування та випуск програмного забезпечення може відбуватися швидко, часто та надійніше.

Я підкреслив, can happenяк це не так must happen.

Ніщо у наведеному вище описі насправді не вимагає гнучкої методики розвитку.

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

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