release record

Запись о релизе — это управляемая запись в CMDB, которая фиксирует, что именно входит в конкретный релиз и какие конфигурационные единицы затрагиваются его установкой. В практическом ITSM это «точка сборки» информации о релизе: состав поставки, версия, дата и статус, ссылка на соответствующее изменение, а также трассируемость к затронутым конфигурационным единицам, таким как компоненты приложения, серверы, базы данных, элементы ИТ-инфраструктуры, документация или параметры конфигурации. Такая запись помогает обеспечивать прозрачность развёртывания, поддерживать контроль рисков и соответствие требованиям, ускорять диагностику инцидентов после внедрения и упрощать обзоры после внедрения. Она особенно полезна при частых релизах, в средах с высокой регуляторной нагрузкой и при сложных зависимостях между системами, где важно быстро определить, что изменилось и где именно. При этом запись о релизе не предназначена для замены планов проекта, детальных пошаговых рабочих инструкций развёртывания или хранения исходного кода; она отражает управленческую и конфигурационную сторону релиза в контексте CMDB.

Запись о релизе часто путают с более общими артефактами управления релизами, такими как описание релиза, пакет поставки или запись об изменении. Ключевое отличие в том, что запись о релизе привязана к CMDB и должна обеспечивать трассируемость к затронутым конфигурационным единицам. Запрос на изменение или запись об изменении отвечает на вопрос «почему и кто разрешил», тогда как запись о релизе отвечает на вопрос «что именно поставляется и какие конфигурационные единицы это затрагивает». Ещё одна типичная ошибка — вести запись о релизе как «чек-лист установки» или как технический журнал развёртывания; для этого обычно используют рабочие инструкции и средства непрерывной интеграции/непрерывного развёртывания, а запись о релизе должна оставаться устойчивой точкой учёта состава и связей в CMDB. Практический риск — неполные или неверные связи: если не связать релиз с фактически затронутыми конфигурационными единицами, последующий анализ инцидента или оценка риска при следующих изменениях будет опираться на искажённую картину. Также важно не создавать запись о релизе задним числом без подтверждения факта развёртывания в рабочей среде, иначе CMDB утрачивает доверие как источник управляемой информации.