Сегодня DevOps находится на интересной стадии своей эволюции: учитывая огромное количество доступных средств, можно говорить о «кембрийском взрыве» разнообразия инструментов и областей их применения. Но действительно ли это многообразие необходимо?
Методы Agile не панацея, и у них есть своя «темная сторона», что, однако, не помешало им улучшить практику разработки ПО. В любом случае они не отменяют знаний в области программной инженерии, накопленных за предыдущие десятилетия.
Для компаний со сложившимися структурой и процессами достаточно сложно масштабировать Agile-разработку, однако сегодня это необходимо всем, кто надеется быть конкурентоспособным в условиях цифровой экономики.
Новые способы взаимодействия бизнеса с клиентами и поставщиками потребовали новых способов организации управления ИТ. И наоборот, новые технологии управления ИТ-инфраструктурой открыли перед бизнесом новые возможности. Появление философии DevOps было лишь вопросом времени.
Новые технологии, изменяющие и бизнес, и ИТ-службы, требуют адаптации процессной модели ITIL в условиях роста популярности Agile и DevOps, которые, хотя и не противоречат базовым принципам ITSM, работают по спиральной, а не каскадной модели, традиционно описываемой в документах ITIL. Переход к другой модели — естественное направление развития ITIL.
Роль архитектора сегодня сильно изменилась, и для успеха проекта потребуется уйти от традиционных методов работы. Современный архитектор должен ориентироваться на продукты, участвовать в принятии решений, фокусироваться на всем цикле выпуска ПО, понимать код, который создают программисты, и работать децентрализованно.
Облака, Большие Данные и Интернет вещей способны предоставить цифровому бизнесу конкурентные преимущества, однако традиционные ИТ уже не могут обеспечить поддержку новых бизнес-моделей, своевременную разработку новых сервисов и приложений или изменение уже имеющихся.
Гибкие, или скорые, методики разработки программного обеспечения потеснили сегодня традиционные подходы к ведению проектов. Разработчики, уставшие от ожидания четких постановок задач и от неспособности заказчиков сформулировать свои пожелания, делают ставку на организацию работы, которая, как показывает практика, зачастую позволяет добиться результатов, даже если цель не видна на старте. Однако распространение такого рода методик разработки закономерно приводит к необходимости ответить на вопрос, как должно быть организовано сопровождение созданного в соответствии с подобными методиками ПО?
Сочетание формальных и скорых методов при разработке программного обеспечения позволяет свести к минимуму сложности, связанные с внесением изменений в код.
Чаще всего под DevOps понимают методологию разработки и эксплуатации программного обеспечения, основной идеей которой является сосредоточение на коммуникации, сотрудничестве и интеграции между командами разработки и эксплуатации, однако DevOps — это прежде всего культура, а уже потом практическая деятельность.
.jpg)