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

Разбираемся с управлением релизами

И опять из навеянного недавними встречами и обсуждениями с Заказчиками. Вообще назначение процесса управления релизами и его организация вызывают массу вопросов:

  • Нужен ли процесс управления релизами как отдельный процесс?
  • Для обработки каких изменений будет привлекаться процесс управления релизами?
  • В каких отношениях находятся процессы управления релизами и изменениями (кто кому выдаёт задания, кто перед кем отчитывается, кто принимает решения, а кто их исполняет)?

Часть из этих вопросов уже поднималась в предыдущих обсуждениях на этом сайте.

Стремясь привести свои давние мысли на этот счёт в порядок, я решил освежить свои знания первоисточников, коих использовал три: ITIL, BMC Service Management Process Model (SMPM), IBM Tivoli Unified Process (ITUP). Свои выводы (наверняка для многих весьма спорные) решил обнародовать.

И так, несмотря на то, что в разных источниках используется одно и то же название «Release management», речь на самом деле идёт о разных процессах (что и вызывает путаницу). Разных не только по способу организации, а по назначению, по месту в процессной модели. Для того чтобы лучше с этим разобраться, возьмём произвольную ИТ-организацию и выделим в ней два подразделения: одно будет отвечать за эксплуатацию информационных систем, другое – за разработку и сопровождение (границы между эксплуатацией и сопровождением берём согласно ISO 12207 «Software Life Cycle Processes»). Так вот в такой ИТ-организации возможны два разных взгляда на управление релизами.

Первый: управление релизами осуществляется в рамках подразделения разработки / сопровождения.

В этом случае на вход процесса попадают требования к изменению ИС (неважно, в виде запроса на изменение или просто в виде служебки с функциональными требованиями), на выходе будет релиз, которые эти требования реализует. Содержание процесса:

  • анализ требований;
  • разбивка их на логические группы;
  • планирование с учётом политик релизов;
  • организация разработки;
  • квалификационное тестирование;
  • выпуск (передача к внедрению в продуктив).

Далее релиз передаётся в подразделение эксплуатации (то есть выполняется приёмка релиза), где в рамках управления изменениями внедряется в продуктив. Похоже, именно о таком процессе написано в SMPM. Вот характерные признаки такого процесса:

  • он обрабатывает только нестандартные запросы на изменения (стандартные обрабатывает процесс управления изменениями);
  • он самостоятельно (не управление изменениями!) отвечает за авторизацию изменений на CAB’е;
  • он имеет дело только с изменениями в приложениях (изменения в инфраструктуре также обрабатываются процессом управления изменениями самостоятельно);
  • естественное определение релиза – набор компонент, которые вместе тестируются и внедряются в продуктив.

То есть управление релизами подразделения разработки и сопровождения стыкуется с управлением изменениями подразделения эксплуатации (хотя может быть корректнее здесь говорить об общем – сквозном – управлении изменениями). Значит есть основание для выделения управления релизами в отдельный процесс.

Второй: управление релизами осуществляется в рамках подразделения эксплуатации.

В этом случае получаем привычный Release management, который отвечает за объединение нескольких изменений в релиз и организует безопасное и контролируемое внедрение. Содержание процесса (каноническое, жизнь потребует корректив):

  • определение охвата и содержания релиза;
  • сборка релиза;
  • тестирование релиза;
  • планирование развёртывания релиза;
  • информирование всех участников и потребителей услуг;
  • развёртывание релиза.

Именно о таком процессе написано в ITIL и в ITUP. Вот характерные признаки такого процесса:

  • стандартные изменения, не требующие всей бюрократии процесса управления изменениями, могут попадать напрямую в управление релизами (то есть, в отличие от BMC-шной модели, это управление релизами прекрасно может выполнять стандартные изменения);
  • за авторизацию изменений (и, в частности, за CAB) отвечает управление изменениями, управление релизами – «инструмент» управления изменениями, отвечающий именно за внедрение;
  • он может применяться и по отношению к приложениям, и по отношению к инфраструктуре (например, развёртывание стандартного рабочего места для нового сотрудника вполне может быть работой управления релизами);
  • естественное определение релиза – набор изменений, которые вместе тестируются и внедряются в продуктив.

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

Что называется, почувствуйте разницу. Если в беседе вы зафиксируете тему не просто в виде «Release management», а договоритесь, о каком именно управлении релизами идёт речь, вы сможете избежать непонимания и обоснованно ответить на заявленные вопросы в начале поста.

P.S. Для подготовки этого описания я сознательно упрощал картинку. Можно развернуть целую дискуссию по уточнению характеристик этих двух различных процессов управления релизами. Думаю, не стоит. Чтобы осознать разницу, надо упрощать. Мне здесь интереснее именно принципиальная разница между двумя видами управления релизами.

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

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

  • А вот – специально для консультантов с двумя руками – и еще один взгляд (курсив – мой):

    After envisioning, planning, developing, and stabilizing, the solution is ready to be deployed. The Deploying Phase implements the tested solution in the production environment. The migration project Release Management team deploying the solution works with the operations team to successfully deploy and stabilize the solution. At the close of the Deploying Phase, customer approval for the migration is obtained, and the solution is transferred to the operations team. It is also possible that the operations team handles the deployment with the aid of the project team. Irrespective of which team does the deployment, the key goal of the Deploying Phase is to successfully migrate the new solution into the production environment as smoothly as possible, and with the least amount of disruption to the business environment or the end users.
    (это я полез посмотреть, что об этом думает Microsoft. Было понятно, что раз управление релизами (старательно избегаю слова “процесс”) описано в MOF, значит, MS – за вторую модель. Но решил подсмотреть на всякий случай в MSF. Ясно, конечно, что подходы несколько разъехались во времени, но все же сравнивать, по-моему, можно. И вот в первых же строках главы про фазу Deployment – такой неожиданный либерализм.)

    • Доктор, поясните. Не догнал. В смысле “может быть и так, и так”?

      • …причем в рамках одного подхода.

        • Есть 2 мысли.

          1. По-моему это не страшно. Я такую двойственность встречал однажды в жизни у одного из заказчиков. И она была очень разумно обоснована. Если интересны детали, расскажу.
          2. Я писал не про то, что одна и та же деятельность может исполняться “и там, и там”, а про то, что деятельность эта получается разная. И разница достаточно серьёзна.

  • Юрий Ерин

    Подход к получению ответов на поставленные вопросы, на мой взгляд, должен основываться на определении состава решаемых задач на ограниченном отрезке жизненного цикла ИТ системы и последующем оптимальном распределении ответственности за их выполнение на существующие/новые процессы. При этом, “где будет осуществляться управление релизами” с т.зр. организационной структуры будет зависеть в первую очередь от того, какие задачи мы отнесем к процессу управления релизами и как эти задачи маппируются на организационную структуру.
    Подход “если управление релизами осуществляется в подразделении эксплуатации, это одни задачи, а если в разработке/эксплуатации – другие” мне кажется не корректным.
    Ответ на вопрос “нужен ли процесс управления релизами как отдельный процесс”, на мой взгляд, будет зависеть от ответа на вопрос “зачем”. Зачем производственные компании организуют процессы закупки и продаж? Зачем банки организуют процессы кредитования т депозитарного обслуживания? Зачем ИТ подразделения организуют процессы управления инцидентами и проблемами?

    • Так в том и дело, что ответ на вопросы “зачем”, заданные тобой, в существенной степени зависит от того, о каком структурном подразделении мы говорим 🙂

      В итоге мне кажется, что всё просто (раскрываю карты). С точки зрения общего подхода (подчёркиваю – речь не о конкретном заказчике, а о типовой процессной модели) я бы сделал три вещи:

      1. Отделил процессы управления разработкой (в т.ч. управление релизами) от процессов эксплуатации. В управлении разработкой есть RUP, MSF, CDM и так далее. Им (разработчикам) виднее, как строить свою работу. Так будет меньше конфликтов.
      2. Сделал бы сквозным процесс управления изменениями в ИТ-услугах / информационных системах. В частности, разработка, imho, должна быть одним из этапов изменения и должна координироваться общим процессом. При этом в отношении разработчиков осуществляется только общий контроль исполнения: задача, ответственный, срок. Без управления отдельными аспектами разработки.
      3. Не выделял “эксплуатационное управление релизами” в отдельный процесс. Разработку политик управления релизами выделил бы в CHG, инициативу по созданию / изменению политики управления релизами отдал бы в CHG (как часть совершенствования процесса) и в SLM (как часть проектирования и совершенствования услуг).

      Техническая реализация такого подхода также очевидна.

      • Добавлю (навеял пост Вадима ниже):

        “1. Отделил процессы управления разработкой … Им (разработчикам) виднее, как строить свою работу. Так будет меньше конфликтов.”

        Тем более, если разработчики – внешняя компания. Или несколько внешних компаний со своими процессами управления релизами (или без оных).

      • И ещё добавлю. Как показывает практика, у разработчиков разных систем практики управления релизами могут отличаться, в том числе из-за технологических особенностей сред разработки. Например, управление релизами у команды разработки SAP скорее всего будет отличаться от управления релизами у разработчиков in-house приложения, написанного на C++.

      • Юрий Ерин

        В целом, пожалуй, соглашусь. Общее планирование, координация и контроль необходимы.
        Есть ньюансы, которые потребуется учесть в такой схеме. Например, в компании, где я работаю, бОльшая часть изменений “приходит” из проектов. Содержание проектов, приоритеты (новая, изменяемая функциональность) определяются бизнесом. Организация и контроль за выполнением осуществляется менеджерами проектов. С другой стороны, эксплуатационщики также инициируют изменения (функциональность, устранение багов), которые для бизнеса не всегда могут иметь первостепенный приоритет. При этом, ресурсы (разработчики, тестировщики) практически одни и те же. В такой ситуации, для того чтобы сделать CHG “сквозным” потребуется существенная корректировка отношений между ИТ и бизнесом, перераспределять отвественность между управлением изменениями и управлением проектами.

        • “В целом, пожалуй, соглашусь.”

          Уже неплохо 🙂

          “В такой ситуации, для того чтобы сделать CHG «сквозным» потребуется существенная корректировка отношений между ИТ и бизнесом, перераспределять отвественность между управлением изменениями и управлением проектами.”

          Нет, думаю это не обязательное условие – надо просто определять порядок и особенности инициации изменений из проектов. Я думаю, это можно сделать за счёт “заточки” процесса управления изменениями. Но детали реализации в конкретной компании давай обсуждать приватно.

  • Андрей Шилов

    Первый вариант вызывает вопросы. Согласование отдельного потока изменений – то, что я не стал бы реализовывать на практике. Можно дожить до согласования развертывания релиза на железе, которое выключат в это же время в рамках другого согласованного изменения. Предвижу предложения по использованию единого календаря изменений и релизов, и все же решение – не нравится. Не определен (или не очевиден) порядок действий на случай, если в релиз вошли программные компоненты и компоненты инфраструктуры (или их синхронное изменение). Примеряя подходы на существующую практику, выбрал бы вариант “схождения” потоков изменений в один ближе к согласованию внедрения и его выполнению.

  • Был прикольный пример в тему! Когда в одном из Банков, ИТ и Разработчики были очень далеки друг от друга. У разработчиков давно существовал процесс управления релизами (первая модель). Было забавно, когда в рамках внедрения ITSM в блоке ИТ, тоже появилсяcя процесс управление релизами (вторая модель). В итоге появилось много непоняток и весь ИТишный процесс управления релизами поместили в описание «пакета изменений» в процессе управления изменениями.

    В целом неоднократно встречал примеры, когда работают обе модели, при этом очень часто вторая модель не выделяется в отдельный процесс.

  • Вадим

    IMHO оба процесса, с позволения сказать, release management’а на самом деле про разные релизы. Релизы с точки зрения подразделения разработки и релизы с точки зрения подразделения эксплуатации – разные. Косвенно про это говорит фраза который отвечает за объединение нескольких изменений в релиз. Поэтому релиз с точки зрения разработки – всего лишь потенциальное изменение с точки зрения эксплуатации.
    Я бы даже сказал, что независимо от того, как в разработке организована среда (development-test-production), самый что ни на есть продакшн разработки является не более чем test’ом для эксплуатации. Правда, соответствующим образом должна быть построена конфигурация эксплуатируемой инфраструктуры и организована сама эксплутация.
    Продиктовано такое разделение ессно различными целями обоих подразделений. Ну а если представим, что вместо подразделения разработки выступает внешняя компания, то все должно быть более очевидно.
    Безусловно возможен вариант некоего совместного процесса (в целях оптимизации трудозатрат или в силу высокой значимости результата) по внедрению созданных “релизов”.

  • Георгий

    Поучившиь в далеком 2004 году ITIL, я честно долгое время думал сам и учил других коллег тому, что Release Management как отдельный процесс в ходе эволюции ITIL прекратит существование и вольется в Change Management как часть процесса.
    ITILv3 в этом плане нарушил мое предсказание на 100% 🙂

    • Блииин…. Всё пропало 🙂

      • Георгий

        Нет! за 4 года я взял себя в руки и стойко перенес трагедию 😀

        Тем более, не все потеряно, раз уже и у тебя появилось подозрение, что “скрипач не нужен” :)))

        • Да уж давно. Года 3-4 как появилась. Просто тема всплыла и появилась новая для меня информация по отличиям в ремедёвой модели. Так что – спокойно, дружище. Ты не один!

    • О, да! ITIL v3 в теме управления релизами раздул такого слона, которого никто съесть не сможет (вот ведь фраза получилась…).

      Хотел бы я посмотреть на компанию, где построены и работают Transition Planning & Support, Release & Deployment Management, Service Validation & Testing, ну и Evaluation, куда же без него…

  • Мне кажется здесь есть ещё один любопытный момент, который пока в обсуждениях не прозвучал. Дело не только в том, что есть релиз на стороне разработчиков и на стороне “эксплуататоров”. И так понятно, что они есть и они разные. Дело ещё в том, что даже в пределах “ITIL-based” (или “ITIL-like”) моделей, к которым относится и BMC SMPM, описаны _разные_ процессы управления релизами. Разные не с точки зрения отдельных деталей реализации, а с точки зрения логики организации (см. текст поста).

  • Прикольный

    У меня вопрос по основному посту.
    Дима, сопровождение по меньшей мере равноудалено от разработки и эксплуатации. Два описанных релиз-менеджмента неточно отражают реальность.

    • “… сопровождение по меньшей мере равноудалено от разработки и эксплуатации. Два описанных релиз-менеджмента неточно отражают реальность.”

      Спорно. Не встречал ситуации с тремя структурными подразделениями: разработки, сопровождения и эксплуатации. Обычно их два. И чаще одно отвечает за разработку, а второе за сопровождение и эксплуатацию. Иногда (реже) одно отвечает за разработку и сопровождение, второе – за эксплуатацию. Поэтому в конкретной организации о равноудалении говорить не приходится. Или давайте как-то определимся как измерять удаление, если я неправильно понял вашу мысль.

      P.S. Простите, а с кем имею честь?

      • Прикольный

        ИТ-подразделения – это условность. Впрочем, именно это и имел в виду под “как минимум” – большую близость сопровождения к эксплуатации, чем к разработке.
        А вот как источник изменений это важно. Изменения/релизы у разрабов малоинтересны – это очень специальная область, боковая для ИТСМ. Изменения/релизы из эксплуатации – наверняка вторая модель, описанная в топик-посте.
        Но ведь абсолютное большинство инициатив обретает форму именно в сопровождении. Обе описанные модели управления релизами им плохо соответствуют. Я не про Вашу мысль, это проблема в реальности. Не говоря о том, что на автомате в разработку поступают задачи, которые следовало бы решать в рамках эксплуатации. Нужен третий релиз-менеджмент, самый востребованный – а он чувствуется только как щель между двумя блестяще описанными.
        to P.S. Да я ничего интересного собой не представляю.

        • “to P.S. Да я ничего интересного собой не представляю.”

          Просто Вы обратились ко мне по имени. Именно в связи с этим я счёл возможным попросить Вас представиться. Но не настаиваю 🙂

        • “Нужен третий релиз-менеджмент, самый востребованный — а он чувствуется только как щель между двумя блестяще описанными”

          Честно говоря, мне так не кажется. То, о чём Вы говорите, мне понятно: большие задачи управляются в рамках проектов, маленькие – в оперативном управлении изменениями. А вот со средними (средние доработки в рамках сопровождения) – с ними хуже. Это как в физике: задача двух тел решается аналитически в рамках механики (трёх – численно), 6*10^23 – в рамках статфизики, а вот с коллективами из 10^2-10^6 тел / частиц ситуация гораздо хуже.

          Но я думаю это не вопрос к управлению релизами, это вопрос проработки управления изменениями в следующих областях:

          1. классификация изменений по типам, источникам и параметрам обработки;
          2. наложение процесса управления изменениями на оргструктуру ДИТ (в частности, возможность эффективного управления при вовлечении в реализацию изменения нескольких отделов, в т.ч. разработчиков);
          3. определение интерфейсов между управлением изменениями и проектами;
          4. определение интерфейсов между управлением изменениями в ИТ и в бизнесе.

          По всем задачам есть / возможны вполне разумные и ясные ответы. Не как в ITIL 🙂

          • “Это как в физике: задача двух тел решается аналитически в рамках механики (трёх — численно), 6*10^23 — в рамках статфизики, а вот с коллективами из 10^2-10^6 тел / частиц ситуация гораздо хуже.”

            Дим, ты меня просто убил сейчас…


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM