Портал №1 по управлению цифровыми
и информационными технологиями

Два слова об управлении релизами

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

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

  1. система является критичной / значимой для заказчика – её простой или нарушения в работе в течение нескольких часов крайне нежелательны (критичность, например, может выражаться в заметных потерях от простоя, или в нарушении работы очень большого количества пользователей);
  2. по данной системе поступает довольно плотный поток запросов на средние и небольшие доработки, для ориентира скажем 25+ запросов в месяц.

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

emc2Что касается частоты выпуска релизов, то здесь картина довольно проста – при прочих равных условиях и разработчик, и заказчик заинтересованы в частых релизах. Для заказчика частые релизы – это сокращение времени внедрения, а для разработчика – повышение вероятности обнаружить ошибку при тестировании и быстрее локализовать её в продуктиве, если в ходе тестирования её обнаружить не удалось. Меньше кода – меньше ошибок, что подметил еще тов. Эйнштейн в начале 20-го века (см. картинку).

Что снизу ограничивает интервал выпуска релизов? В первую очередь – стоимость. Чаще релизы – выше затраты на инфраструктуру для тестовых сред, больше трудозатраты на их подготовку, организацию тестирования (иногда не только функционального, но и регрессионного, и нагрузочного), выполнение развертывания (особенно в распределенных системах крупных предприятий). Поэтому для крупных компаний «частые» релизы – это раз в месяц (не очень частые – квартал), для небольших – раз в несколько дней (не очень частые – 2+ недели).

Вот такие простые соображения. Годятся?

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Комментариев: 8

  • Андрей

    Про ограничения снизу. В свете моднодного нынче подхода "шустро"(Agile) появился ряд инструментов, позволяющих в значительной степени нивелироватьэти ограничения. Первый класс инструментов – виртуализация сервиса, когда для тестирования используется не сама система, а запись её поведения, своего рода эмулятор. Кстати, самой системы может даже еще и не быть, а есть только согласованная модель поведения. Это, во-первых, значительно снижает стоимость тестовой среды(вместо мэйнфрейма используется малюсенькая виртуалка, которая "внешне" выглядит как майнфрейм ) и во-вторых, что не менее важно, позволяет максимально приблизить тестирование к разработке. Разработчик может сам оперативно протестировать свой код. Второй каласс ситем – ситемы автоматизации выполнения релиза. Ну тут все понятно.

    В пределе обещается что выпуск релизов превратится в непрерывный процесс.:)))

    • вместо мэйнфрейма используется малюсенькая виртуалка, которая "внешне" выглядит как майнфрейм

      Функциональное тестирование изолированной системы таким образом, действительно, провести можно. Тестирование интеграций и, тем более, нагруочное тестирование – едва ли. Кроме того, остается задача подготовки тестовых наборов данных, что в случае проведения нагрузочного тестирования или привлечения к тестированию внешних подрядчиков тоже может требовать времени. По всей видимости, это приведет к тому, что для корпоративных приложений будет относительно редкая сетка full-релизов и очень частая (неделя или меньше) сетка маленьких delta-релизов.

      В пределе обещается что выпуск релизов превратится в непрерывный процесс

      В случаях, когда не требуется UAT, вполне возможно. На прошлогодней эстонской конференции itSMF Адриан Кокрофт как раз рассказывал об этом, как о своей, уже сегодняшней, практике в Netflix.

      • Андрей

        "Тестирование интеграций и, тем более, нагруочное тестирование — едва ли."

        Отнюдь. Попробую развеять ваши сомнения. Именно на нагрузочном тестировании виртуализация дает наибольший финансовый эффект. Эмулятор, в отличие от реальной системы, не тратит ресурсы на подготовку ответа. Он просто находит пару к запросу и отправляет ответ. Кроме того, техгнологии позволяют запустить множество эмуляторов в рамках одного сервиса, используя брокер запросов. В этом случае вы для тестируемой вами системы(модуля) создаете эффект безграничности ресурсов у запрашиваемой системы и в этом случае поведение вашей системы при росте нагрузки не зависит от внешних факторов( ну хорошо – минимально зависит:)) ) Без виртуализации вам для нагрузочного тестирования необходимы внешние системы, сопоставимые по производительности(ресурсам)с реально используемыми, а это весьма и весьма удорожает тестовую среду. Она по цене становится почти как промышленная. Более того, сопоставимая с реальной система не всегда может быть в принципе доступна для тестирования. Часто это касается облачных сервисов.

        Но есть и другое преимущество при  нагрузочном и интеграционном тестировании. Вы можете вводить задержки в работу виртуального сервиса, моделируя тем самым поведение реальных внешних систем. В этом случае особенно хороша интеграция с системами мониторинга производительности систем в промышленной эксплуатации (user experience), как источниками данных о реальных задержках.

        • Попробую развеять ваши сомнения.

          Андрей, а пришлите какие-нибудь ссылки на хорошие матералы по теме. Интересно почитать, составить собственное мнение / развеять сомнения. То, что Вы пишете, мне кажется немного сказочным (то есть создать эмулятор и протестировать его – не сказка, а вот насколько результаты такого тестирования будут отражать жизнь – большой вопрос), но голословно судить не берусь. Посему запрашиваю пруф. А если кроме статей есть и примеры реализации, про которые Вы можете рассказать, велкам вдвойне – крайне любопытно.

      • На прошлогодней эстонской конференции itSMF Адриан Кокрофт как раз рассказывал об этом, как о своей, уже сегодняшней, практике в Netflix.

        …даже как о вчерашней – год назад, когда Адриан это рассказывал, он уже не работал в Netflix, и в основном описывал опыт 2009-2013 годов. Впрочем, судя по той же презентации, то, что Netflix делает "сегодня", весь мир делает через 4-5 лет.


Добавить комментарий для Дмитрий ИсайченкоОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM