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

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

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

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

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

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

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

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

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Release Control and Validation

Учебный курс: преобразование и контроль ИТ-услуг, управление изменениями, релизами и конфигурациями, а также построение CMDB — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Андрей

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

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

    0
    0
    1. Дмитрий Исайченко Автор

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

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

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

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

      0
      0
      1. Андрей

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

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

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

        0
        0
        1. Дмитрий Исайченко Автор

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

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

          0
          0
          1. Андрей

            "то есть создать эмулятор и протестировать его "

            Уточню — тестировать не эмулятор, что его тестировать? Эмулятор используется для тестирования нового модуля и он эмулирует внешние для тестируемого модуля системы.

            Ссылки можно глянуть здесь http://www.ca.com/us/devcenter/ca-service-virtualization.aspx?intcmp=featuredprod_ca-service-virtualization

            Более конкретные матералы отправлю на почту.:))

             

             

            0
            0
      2. Роман Журавлёв

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

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

        0
        0

Добавить комментарий

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
27
Учебный курс:
Основы ITIL (очно)
ДЕК
4