Релиз — странности терминологии

Освежал сегодня в памяти содержание стандарта ISO 20000. Опять наткнулся на странность, которая меня каждый раз заставляет задуматься — определение релиза. В общем-то, текст стандарта ISO 20000 стройностью и полнотой терминологии никогда не отличался. Например, стандарт с названием "Information technology — Service management" не содержит определения Service. А определения терминов Service desk и Service management и вовсе выглядят комично. Но сейчас не об этом — о релизе.

Определение в стандарте звучит так:

Release — collection of new and/or changed configuration items which are tested and introduced into the live environment together.

Это немного странно. Например потому, что если мы говорим о дельта-релизе, то релиз может превратиться не в набор CI, а в набор изменений в одной CI (вспоминаем, что release unit >= CI).

Глоссарий ITIL хитрее:

Release — a collection of hardware, software, documentation, processes or other components required to implement one or more approved Changes to IT Services.

Тут уже CI к делу не пришьешь — это слово в определении не встречается 🙂 Но суть по-моему остается — это набор компонентов. С бытовой точки зрения — все ОК. Например, вот релиз ПО. Он состоит из диска с дистрибутивом и пары книжек. Но если мы говорим об определении термина релиз в рамках процесса управления релизами, то мне непонятно, почему бы не дать определение релиза как "Совокупность одного или нескольких изменений, которые тестируются и внедряются в продуктив совместно"? Это определение и точнее (нет проблем с дельта-релизами), и ближе к сущности процесса управления релизами.

ITIL ITIL Intermediate: Release Control and Validation

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

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

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

  1. Анатолий Павлюченко

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

    Т.е. важным, на мой взгляд, есть не то, что изменятся, а сама возможность выполнения процесса.

  2. Юрий Ерин

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

    На практике, все-таки, под релизом понимают набор компонентов, которые собираются, тестируются, распространяются и развертываются в продуктивную среду. Вместе.

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

    Касательно отсутствия упоминания CI в определении релиза в ITIL, на мой взгляд, разумно. Компоненты всегда есть, а вот CI появляются вместе Config Management. При этом, CI в CFG mgmt не обязательно то же самое что изменившийся компонент (C = приложение, как правило состоит из более чем одного компонента).

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

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

      Вот смотри. Разработчикам поступают запросы на изменение. По этим запросам готовятся доработки продукта / системы. Одно, второе, третье... Запросы на изменение с завершением разработки конечно не закрываются, так как внедрения еще не было. Лежат и ждут своего часа. Затем подходит срок планового релиза. Выполненные доработки собираются вместе (с учетом их взаимосвязей), идут на тестирование, затем на внедрение. При этом в рамках релиза на этапе relese deployment выполняются работы и по конфигурированию серверов, и по обновлению ПО, и другие (если необходимо). Эти работы могут выполняться и как задания (в составе релиза), и как изменения (это уже специфика конкретного решения — распределения ответственности, уровня контроля изменений и релизов, масштаба изменений в конце концов).

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

      1. Николай

        Нет, следуя ITIL — не получается.

        Если очень надо определить релиз через изменение, то всё же скорее так (если придерживаться того, что понятие релиз имеет право на существование 🙂 —

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

        Это следует из определений релиза и изменения:

        а) release — «collection of CIs required to implement one or more Changes»

        b) change — «addition, modification or removal of anything that could have an effect on IT Services».

        Иными словами, релиз=набор_компонент, а изменение=действие.

        Набор компонент не может равняться нескольким действиям — природа разная 🙂

        А вообще по мне текущие трактовки релиза — отрыжка прошлого, оставшиеся с ITIL v.1, где речь шла исключительно про ПО. И желание перевести содержание этого понятия с набора CI на набор работ мне понятно — только это будет уже не ИТИЛовский релиз 🙂

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

          «Иными словами, релиз=набор_компонент, а изменение=действие.»

          Николай, я это понимаю. Вопрос был про то, _почему_ так и _почему_ нельзя иначе. Обрати внимание на цель процесса управления релизами в ISO 20K (есть здесь, см. несколько коментов выше). Альтернативное определение ничему не противоречит 😉

          1. Николай

            Ну ладно... будем считать, ты меня спровоцировал 🙂

            «Почему так?» — потому что тяжелое прошлое ИТИЛ-1 никто не удосужился переосмыслить. Иными словами, так — потому что недодумали 🙂

            «Почему нельзя?» — наоборот, можно и нужно. Только мне кажется некорректным пробовать просто «поменять определение». Я предлагаю более радикальный (и как мне кажется честный) путь. Давате признаем, что процесс release в паре с change в том виде, что есть в ITIL — непонятен, несовершенен, а значит неэффективен.

            После этого откажемся от него, а вместо — сделаем другой, разумный 🙂

            Можно и конкурс на название (с охватом) объявить: например «управление внедрениями» или «управление плановыми работами».

            Кстати, интересно — определение релиза из Стандарта (про collection of configuration items) только мне напоминает бейслайн? 🙂

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

              «Кстати, интересно — определение релиза из Стандарта только мне напоминает бейслайн?»

              Нет, ты не один 🙂 С точки зрения ITIL эти вещи очень близки, особенно в части стандартных изменений (но конечно не только в них).

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

              «Я предлагаю более радикальный (и как мне кажется честный) путь. Давате признаем, что процесс release в паре с change в том виде, что есть в ITIL — непонятен, несовершенен, а значит неэффективен.»

              Objection. Мне понятен. Вопрос совершенства и эффективности — это вопрос конкретной реализации, а не книжки.

              1. Николай

                Ээх... если бы он (процесс, описанный в книжке) был понятен, то не возникло бы этого топика 🙂

                Позволю себе процитировать тебя: «если мы говорим об определении термина релиз в рамках процесса управления релизами, то _мне непонятно_ почему бы не дать определение релиза ...» Итого — непонятное в ИТИЛе определеньице, хромоватое 🙂

                  1. Николай

                    Ну, тогда всё хорошо. Здорово, когда понимаешь процесс управления тем, определения чего не понимаешь или не принимаешь 🙂

                    Слава консультантам!

                    А если по делу — неужто никогда не было желания скоуп процесса release поменять? Напрмер, чтобы снять казуистическую проблему «если я просто сервер выключу и ничего не меняя включу — это изменение, релиз или что?»...

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

                      «А если по делу — неужто никогда не было желания скоуп процесса release поменять?»

                      Как же не было? Каждый раз меняем 🙂

  3. Юрий Ерин

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

    Думаю, для ИТ специалистов, задействованных в развертывании такое определение релиза будет вполне понятно. Развертывание релиза для них может быть естественным образом представлено в виде одного или нескольких изменений/заданий. Для тех кто разрабатывает, собирает, тестирует ПО, это не очевидно. Просто потому, что они работают с компонентами, изменяющимися/создаваемыми на основании ТРЕБОВАНИЙ. Конечно, можно представить набор требований как набор изменений, однако, у меня есть сомнение в целесообразности.

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

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

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

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

ИЮН
5
Учебный курс:
Основы ITIL (очно)