Управление релизами
Дулаева Алина гр.3272
Вообще назначение процесса управления релизами и его организация вызывают массу вопросов:
v Нужен ли процесс управления релизами как отдельный процесс?
v Для обработки каких изменений будет привлекаться процесс управления релизами?
v В каких отношениях находятся процессы управления релизами и изменениями (кто кому выдаёт задания, кто перед кем отчитывается, кто принимает решения, а кто их исполняет)?
И так, несмотря на то, что в разных источниках используется одно и то же название «Release management», речь на самом деле идёт о разных процессах (что и вызывает путаницу). Разных не только по способу организации, а по назначению, по месту в процессной модели. Для того чтобы лучше с этим разобраться, возьмём произвольную ИТ-организацию и выделим в ней два подразделения: одно будет отвечать за эксплуатацию информационных систем, другое – за разработку и сопровождение (границы между эксплуатацией и сопровождением берём согласно ISO 12207 «Software Life Cycle Processes»). Так вот в такой ИТ-организации возможны два разных взгляда на управление релизами.
Первый: управление релизами осуществляется в рамках подразделения разработки / сопровождения.
В этом случае на вход процесса попадают требования к изменению ИС (неважно, в виде запроса на изменение или просто в виде служебки с функциональными требованиями), на выходе будет релиз, которые эти требования реализует. Содержание процесса:
|
|
|
§ анализ требований;
§ разбивка их на логические группы;
§ планирование с учётом политик релизов;
§ организация разработки;
§ квалификационное тестирование;
§ выпуск (передача к внедрению в продуктив).
Далее релиз передаётся в подразделение эксплуатации (то есть выполняется приёмка релиза), где в рамках управления изменениями внедряется в продуктив. Похоже, именно о таком процессе написано в SMPM. Вот характерные признаки такого процесса:
§ он обрабатывает только нестандартные запросы на изменения (стандартные обрабатывает процесс управления изменениями);
§ он самостоятельно (не управление изменениями!) отвечает за авторизацию изменений на CAB’е;
§ он имеет дело только с изменениями в приложениях (изменения в инфраструктуре также обрабатываются процессом управления изменениями самостоятельно);
§ естественное определение релиза – набор компонент, которые вместе тестируются и внедряются в продуктив.
То есть управление релизами подразделения разработки и сопровождения стыкуется с управлением изменениями подразделения эксплуатации (хотя может быть корректнее здесь говорить об общем — сквозном — управлении изменениями). Значит есть основание для выделения управления релизами в отдельный процесс.
|
|
|
Второй: управление релизами осуществляется в рамках подразделения эксплуатации.
В этом случае получаем привычный Release management, который отвечает за объединение нескольких изменений в релиз и организует безопасное и контролируемое внедрение. Содержание процесса (каноническое, жизнь потребует корректив):
v определение охвата и содержания релиза;
v сборка релиза;
v тестирование релиза;
v планирование развёртывания релиза;
v информирование всех участников и потребителей услуг;
v развёртывание релиза.
v Именно о таком процессе написано в ITIL и в ITUP. Вот характерные признаки такого процесса:
v стандартные изменения, не требующие всей бюрократии процесса управления изменениями, могут попадать напрямую в управление релизами (то есть, в отличие от BMC-шной модели, это управление релизами прекрасно может выполнять стандартные изменения);
v за авторизацию изменений (и, в частности, за CAB) отвечает управление изменениями, управление релизами – «инструмент» управления изменениями, отвечающий именно за внедрение;
v он может применяться и по отношению к приложениям, и по отношению к инфраструктуре (например, развёртывание стандартного рабочего места для нового сотрудника вполне может быть работой управления релизами);
|
|
|
v естественное определение релиза – набор изменений, которые вместе тестируются и внедряются в продуктив.
То есть управление релизами отвечает за определённый этап общей деятельности по управлению изменениями, выполняемой подразделением эксплуатации. Именно поэтому управление релизами может быть реализовано не в виде отдельного процесса, а как часть процесса управления изменениями.
Что называется, почувствуйте разницу. Если в беседе вы зафиксируете тему не просто в виде «Release management», а договоритесь, о каком именно управлении релизами идёт речь, вы сможете избежать непонимания и обоснованно ответить на заявленные вопросы в начале доклада.
Дата добавления: 2016-01-04; просмотров: 12; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!