И опять из навеянного недавними встречами и обсуждениями с Заказчиками. Вообще назначение процесса управления релизами и его организация вызывают массу вопросов:
- Нужен ли процесс управления релизами как отдельный процесс?
- Для обработки каких изменений будет привлекаться процесс управления релизами?
- В каких отношениях находятся процессы управления релизами и изменениями (кто кому выдаёт задания, кто перед кем отчитывается, кто принимает решения, а кто их исполняет)?
Часть из этих вопросов уже поднималась в предыдущих обсуждениях на этом сайте.
Стремясь привести свои давние мысли на этот счёт в порядок, я решил освежить свои знания первоисточников, коих использовал три: 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. Для подготовки этого описания я сознательно упрощал картинку. Можно развернуть целую дискуссию по уточнению характеристик этих двух различных процессов управления релизами. Думаю, не стоит. Чтобы осознать разницу, надо упрощать. Мне здесь интереснее именно принципиальная разница между двумя видами управления релизами.
А вот – специально для консультантов с двумя руками – и еще один взгляд (курсив – мой):
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 – такой неожиданный либерализм.)