Примерно в 2009-ом в мире разработки ПО появилось еще одно модное словцо — DevOps. Если коротко, то так называется методология ИТ-разработки (сильно напоминающая философию), при которой собственно разработка (Development, Dev) тесно интегрируется с процессом пользования продуктом (Operations, Ops).  

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

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

В плане процессов развертки новых версий DevOps сводится к continuous improvement implementation, схематично это будет примерно так:

Почему DevOps суждено было появиться?

Сначала была обычная («каскадная», «водопадная») разработка. Заказчик приносил требования. Требования получали разработчики. Разработчики закрывались на пару месяцев. Заказчику показывали готовое.

Вполне нормальный, рабочий подход. Но почему возникла потребность придумывать что-то еще?

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

Но вот проект усложняется. Заказчик не уверен, что нужно делать именно так. Аналитик, хоть и парень с головой, но тоже не экстрасенс. Кто знает, вдруг продукт вообще не воспримется пользователями? Скетчи, мудборды, прототипы и прочая подстраховка — хорошо, но только реальные пользователи расскажут, как продукт должен работать на самом деле.

Так наступает новая веха в разработке ПО — время Agile и гибких методологий

Процесс меняется в сторону стирания барьера коммуникации между клиентом и разработчиком. Теперь работает другая схема. Заказчик приносит требования. Их разбивают на задачи и упорядочивают по важности для продукта. Разработчики набирают задач на одну-две недели. Закрываются и работают. Показывают первую версию продукта. Запускают на рынок! Далее по кругу, пока все задачи не будут сделаны, а продукт не обрастет всеми плановыми функциями

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

Возникла потребность в изменениях по ходу работы? Не проблема, можно добавить новых функций, на следующем заходе команда их сделает. Увидели, что уже базовый функционал продукта получает негативные отзывы пользователей? Давайте все переосмыслим и поменяем, пока не поздно. Явные плюсы:

1. Проект становится более гибким, изменениями становится возможно управлять.
2. Наконец-то появляется возможность апробации проекта на настоящих пользователях (а не моделирование ситуаций).

Однако фактически гибкие подходы не решают еще одну важную проблему — барьер есть не только между клиентом и разработчиком, но и между разработчиком и IT-отделом (тестировщиками и админами, ответственными за выкладку изменений на продуктив).

Так появляется DevOps

В чем, собственно, проблема, которую DevOps решает? Даже если команда работает по Scrum, функции разрабатываются «пачками». Потом «пачками» тестируются. И, наконец, внедряются в работающий продукт тоже «пачкой».

Соответственно, изменения на продукте происходят не ровно, а «скачками».

То есть по факту Agile-разработка с заявленным «ровным» темпом изменений становится тем же каскадом.

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

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

Скачкообразные изменения — не единственная проблема. DevOps стремится нивелировать еще одну проблему многих ИТ-компаний — существование барьера между разработчиками и IT. Из каких «кирпичиков» состоит противоречие?

• Разработчики мотивированы делать больше изменений, за них им платят. ИТ-отдел мотивирован выпускать в свет наиболее стабильный продукт (меньше изменений — меньше рисков, что что-то сломается).

• Разработчики мыслят «главное — сделать строго по заданию». IT мыслят «главное — сделать оптимально для пользователей».

• Разработчики делают работу в своей среде, QA зачастую настраивают свою среду для тестирования.

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

• Разработчики и отдел эксплуатации мало контактируют друг с другом, у них нет осознания чужих проблем.

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

Что предлагает DevOps? Методология провозглашает три развернутых ключевых тезиса (их еще называют «пути»):

1. Оценивается производительность системы в целом, а не отделов или конкретных разработчиков, админов, специалистов по качеству. Задача руководителя, внедряющего DevOps — заставить всех участников проекта работать единой командой на достижение глобальной цели: увеличение ценности продукта для пользователей. Обязательное условие — развивать кросс-функциональность, делать сотрудников более универсальными солдатами, заставлять их почувствовать себя в шкуре бойца из «лагеря противника».

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

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

Практические рекомендации

Из того, что же можно сделать конкретно, информации не так много, как ее хотелось бы.

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

Вот здесь отличная подборка нужного софта

Ок, что можно сделать для того, чтобы достичь кросс-функциональности в командах продукта?

• Самое простое: не разделять команды стенами — так они смогут общаться без помех.

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

• Создавать общую инфраструктуру. Причем всегда поддерживать ее актуальность. Если речь о каких-то программных инструментах — то они общие для всех, строго одинаковых версий. Если это площадка для тестирования продукта — то не нужно вручную настраивать одну среду для разработки, одну для теста и потом трястись над ней. Всё в облако, протестировали, исправили баги, удалили платформу (чтобы ни у кого не было соблазна в следующий раз «случайно» воспроизвести неведомый баг на неактуальной уже платформе).

Одно из самых трудных — создать нужное настроение в команде, общность целей, понимание того, для чего всё делается в конечном счете. Достигается за счет так называемой«коллективной ответственности». Из того, что пробовали на себе — включаем разработчика в процесс деплоя и теста (он, например, готовит среду).

Ответная мера — QA вместе с разработчиками пишут тест-кейсы, по которым потом будут оценивать работоспособность продукта (это делается на этапе планирования).

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

Методология рабочая?

Но, как мы ни крутили методологию, оставался открытым главный вопрос: а есть ли заказчик среди заказной веб-разработки с реальной потребностью в таком крутом и техничном процессе?

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

Допустим, даже если мы как подрядчик готовы допилить свои процессы до такого совершенства...В итоге нет.

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

Или для тех команд, которые пилят собственный продукт, предварительно спланировав все ресурсы.

В общем, если кто-то из IT-компаний вдруг пробовал внедрить DevOps — будем рады послушать ваш опыт.

Почитать про DevOps

1. DevOps — новая методология разработки.
2. Agile DevOps — гибкая разработка и эксплуатация ПО: Выравнивание процесса выпуска программного обеспечения.
3. DevOps Wiki.
4. 12 антипаттернов DevOps (перевод).
5. 11 важных вещей, которые нужно знать про DevOps — часть первая (перевод).
6. 11 важных вещей, которые нужно знать про DevOps — часть вторая (перевод).
7. Доклад о DevOps (видео и презентация).

Оригинал: http://blog.sibirix.ru/2014/11/19/devops/