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

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

Опубликовано 23 марта 2011
Рубрики: ITIL, Управление релизами
Комментарии

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

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление изменениями и конфигурациями в ИТ
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Также по теме:

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

  • Андрей

    Вот оно, переход knowledge в wisdom 🙂

  • Дмитрий Исайченко

    Более того, цель процесса управления релизами в ISO 20K определена как “To deliver, distribute and track _one_or_more_changes_in_a_release_ into the live environment”.

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

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

  • Юрий Ерин

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

    • Дмитрий Исайченко

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

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

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

      • Николай

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

        • Дмитрий Исайченко

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

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

          • Николай

            Ну ладно… будем считать, ты меня спровоцировал 🙂
            “Почему так?” – потому что тяжелое прошлое ИТИЛ-1 никто не удосужился переосмыслить. Иными словами, так – потому что недодумали 🙂
            “Почему нельзя?” – наоборот, можно и нужно. Только мне кажется некорректным пробовать просто “поменять определение”. Я предлагаю более радикальный (и как мне кажется честный) путь. Давате признаем, что процесс release в паре с change в том виде, что есть в ITIL – непонятен, несовершенен, а значит неэффективен.
            После этого откажемся от него, а вместо – сделаем другой, разумный 🙂
            Можно и конкурс на название (с охватом) объявить: например “управление внедрениями” или “управление плановыми работами”.

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

            • Дмитрий Исайченко

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

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

            • Дмитрий Исайченко

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

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

              • Николай

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

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

                • Дмитрий Исайченко

                  Определеньице – да. Но “процесс release в паре с change” – понятен. Мой топик как раз про определение, предложение расширить scope до процессов – не мое 😉

                  • Николай

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

                    А если по делу – неужто никогда не было желания скоуп процесса release поменять? Напрмер, чтобы снять казуистическую проблему “если я просто сервер выключу и ничего не меняя включу – это изменение, релиз или что?”…

                    • Дмитрий Исайченко

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

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

  • Юрий Ерин

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

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

    • Дмитрий Исайченко

      “Для тех кто разрабатывает, собирает, тестирует ПО, это не очевидно.”

      Тут я пожалуй с тобой соглашусь. И даже два раза. Второй – что нельзя определять релиз как совокупность CI.

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.