Изображение сайта tricentis.com

Существующие реалии буквально требуют от разработки программного обеспечения еще больше сокращать время выполнения проекта: от возникновения идеи до выпуска готового продукта. С завидной периодичностью заказчики просят реализовать проект «вчера», чтобы его не скопировал «сегодня» кто-то другой. И, конечно же, бюджет на то, чтобы сделать невозможное, как всегда, ограничен.

Разработчикам ничего не остается, как вновь и вновь заниматься оптимизацией техпроцесса, экспериментировать, пробовать новые методологии. В особо «запущенных» случаях временные резервы ищут буквально в каждом отделе, а не только заставляют разработчиков печатать быстрее.

Оказывается, быстрее могут работать и тестировщики, и менеджеры, и аналитики, и отдел внедрения. Остается всего ничего – придумать, как этого добиться.

На помощь приходят методологии гибкой и стремительной, а иногда и экстремальной, разработки. Это действительно позволяет частично решить указанную проблему.

Изображение сайта quora.com

Модель Agile предусматривает плодотворное взаимодействие отделов разработки и тестирования, осуществляемое в соответствии с общими целями, общими правилами и общими критериями эффективности.
Agile стал достоянием широкой общественности в 2001 году.

Гибкая разработка сводится к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.

Подразумевается, что «гибкий» программный проект готов к выпуску в конце каждой итерации. Однако на практике это происходит далеко не всегда и не так быстро, как теперь хочется клиентам.

Кроме того, разработка замедляется из-за того, что у различных подразделений, участвующих в создании программного обеспечения, нет общих инструментов и отсутствует возможность делиться полученными знаниями.

Каждое из подразделений выполняет собственные задачи и пользуется разными критериями оценки эффективности своей работы. Для разработчиков — это скорость написания и количество реализованных в программном коде функций, для тестировщиков — число выявленных ошибок, для отдела эксплуатации — стабильность функционирования систем и минимальное количество инцидентов. Подобная модель работы нередко приводит к конфликту интересов: первые стараются как можно быстрее написать код и отдать его на проверку, вторые готовы проверять и тестировать сколь угодно долго, чтобы выявить все баги, а третий с трудом принимает код, поскольку любые изменения влекут за собой потенциальные риски для всей ИТ-инфраструктуры.

Выяснилось также, что отдел эксплуатации – это еще одно слабое звено, которое остается «за рамками» модели Agile.

В 2009 создатели DevOps вселили в широкую общественность надежду на светлое будущее.

Вот так формулируются благородные цели DevOps:

DevOps (development и operations) — методология разработки программного обеспечения, нацеленная на активное взаимодействие и интеграцию специалистов по разработке и специалистов по информационно-технологическому обслуживанию. Базируется на идее о тесной взаимозависимости разработки и эксплуатации программного обеспечения, и нацелена на то, чтобы помогать организациям быстрее создавать и обновлять программные продукты и сервисы.

Стоит отметить, что Agile – не является непременным условием для реализации DevOps.

Clyde Logue, основатель StreamStep, говорит об этом так: «Agile сыграл важную роль в разработке для восстановлению доверия у бизнеса, но он нечаянно оставил IT Operations позади. DevOps это способ восстановления доверия ко всей ИТ-организации в целом».

В DevOps Cookbook и The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, описаны лежащие в основе принципы, с помощью которых все DevOps паттерны могут быть получены с помощью подхода «Три пути»:

Первый Путь подчеркивает производительность всей системы в целом, в отличие от производительности отдельного звена или отдела.

В центре внимания находится все бизнес-потоки по созданию ценности, которые включены в IT.

Второй Путь заключается в создании петли обратной связи идущей справа налево. Целью практически любой инициативы по совершенствованию процесса является сокращение и усиление обратной связь, чтобы необходимые поправки могли внедряться постоянно.

Третий путь заключается в создании культуры, которая влияет на две вещи: постоянное экспериментирование, которое требует принятия рисков и извлечение уроков из успехов и неудач, а также понимание того, что повторения и практики являются предпосылкой к мастерству.

По словам многих заказчиков, ценность описанного подхода состоит в том, что он позволяет получить полную картину модели разработки — с участием абсолютно всех заинтересованных сторон, с четко обозначенными процессами и интеграционными механизмами.

Мы попросили экспертов ответить на несколько вопросов, чтобы узнать, как обстоят дела с DevOps в русскоговорящем мире.

Евгений Оглоблин, DevOps компании из крупнейшей российской тройки:

1. Каким компаниям подходит DevOps?

Мне кажется, что в достаточной степени любым. Крупным – потому что это позволит ускорить разработку, тестирование и релизы продуктов, маленьким – потому что все будут вовлечены в процесс, появится некоторое подобие взаимозаменяемости сотрудников.

2. Насколько глубоко понимание DevOps в русскоговорящем сообществе?

У нас еще очень много «классических админов», которым про продукт вообще не интересно. У них FreeBSD 8 или CentOS 5, все работает и кушать не просит. Значит, и изобретать ничего не нужно.

Плюс сопутствующая DevOps’у автоматизация подразумевает достаточно много работы, зачастую — с новыми технологиями, иногда вообще не известными людям.

Внятно объяснить, что же такое DevOps, по-моему, до сих пор никто не смог — в любой компании есть свои тонкости, наследие и тому подобное. В общем случае все сходятся на мнении, что это автоматизация, стандартизация и более активное участие отдела эксплуатации в разработке, но этих «всех» не так много, если считать в процентах от общего количества IT-людей.

3. Каковы преимущества DevOps?

В случае успешного внедрения DevOps компании могут в перспективе рассчитывать на:

• автоматизацию (снижение рисков человеческой ошибки)
• ускорение и упрощение процессов разработки и релиза
• получение быстрой обратной связи от пользователей (метрики, мониторинг)
• PROFIT!!!

4. Каковы недостатки DevOps?

Нужно очень много поработать.

Нужно не забывать про до сих пор актуальные best practices предыдущих поколений – в море новых технологий сделать это легко.

DevOps по разным причинам может не подойти коллективу, пытающемуся внедрить сабж.

DevOps — не серебряная пуля (а жаль).

5. Насколько широко распространился DevOps в СНГ / России?

В компаниях-лидерах IT-рынка — широко распространился. Хотя, как водится, есть исключения. Но живые компании все чаще понимают необходимость современных методологий.

Евгений Потапов, генеральный директор ITSumma:

1 Каким компаниям подходит DevOps?

Существует несколько значений термина, несколько пластов понимания, что же такое DevOps.

Если мы говорим о культуре взаимодействия разработки и эксплуатации, где программисты понимают, как работают системы, и обладают навыками системного администрирования, а администраторы понимают принципы разработки, то это несомненно надо любой компании, поскольку такой плотный контакт обеспечивает простоту взаимодействия и скорость решения задач, которые часто лежат на границе этих областей.

Если же мы говорим о наборе конкретных практик, связанных с виртуализацией, контейнеризацией, автоматизацией управления инфраструктуры, то здесь самое главное, что компания (а главное сам проект), должна достичь такого размера, при котором накладные расходы на организацию этих практик будут ниже, чем накладные расходы на управление инфраструктурой без них.

2 Насколько глубоко понимание DevOps в русскоговорящем сообществе?

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

3 Каковы преимущества DevOps?

Упрощение коммуникации между специалистами ведет к ускорению взаимодействия.

Пропадает классическая проблема, где программисты винят во всем работу серверов, а администраторы отвечают, что проблемы создает код.

Ускоряется как создание новой функциональности, так и решение старых проблем.

Автоматизация же позволяет избавить от извечной рутины и хаоса в ИТ-проектах.

4 Каковы недостатки DevOps?

Самая главная проблема, которую мы сейчас видим связана не столько с самой методологией DevOps, сколько с повышенным вниманием и ажиотажем вокруг любой новой технологии или практики, когда они применяются не по необходимости, а из интереса к самой технологии.

Зачастую накладные расходы на внедрение и поддержку практик автоматизации, таковы, что даже не ускоряют, а замедляют процессы внутри компании.

Да — иметь возможность часто обновлять код проекта — действительно важно, но как часто небольшому проекту надо иметь возможность выкладывать код ежедневно, десятки раз на дню?

При этом человеческие и денежные затраты на поддержание этой возможности довольно велики.

5 Насколько широко распространился DevOps в СНГ / России?

Существуют развитые сообщества DevOps-специалистов, проходят митапы, выходят отличные книги:

• www.facebook.com/groups/feedme.ru
• www.facebook.com/groups/1418742661718580
• devopsdeflope.ru
• telegram.me/devops_deflope
• eksmo.ru/book/proekt-feniks-roman-o-tom-kak-devops-menyaet-biznes-k-luchshemu-ITD583259

Авторы книги DevOps Cookbook и The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win выделяют следующие бизнес-преимущества DevOps:

• быстрый выход на рынок (сокращение времени цикла и более высокие темпы развертывания);
• повышение качества (повышение доступности, меньше сбоев и так далее);
• увеличение организационной эффективности (больше времени тратится на деятельность, связанную с увеличением ценности продукта и количества функционала).

P.S.
Возможно следующим этапом оптимизации командной разработки будет введение телепатической связи между сотрудниками всех отделов и даже с заказчиками.

Автор:

Источник