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

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

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. Анатолий Павлюченко

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

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

    0
    0
  2. Юрий Ерин

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

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

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

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

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

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

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

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

      0
      0
      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 на набор работ мне понятно — только это будет уже не ИТИЛовский релиз 🙂

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

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

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

          0
          0
          1. Николай

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

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

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

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

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

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

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

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

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

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

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

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

              0
              0
              1. Николай

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

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

                0
                0
                  1. Николай

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

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

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

                    0
                    0
  3. Юрий Ерин

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

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

    0
    0

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

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

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

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

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