Софт

что такое релиз программы

Рейтинг: 4.0/5.0 (208 проголосовавших)

Категория: Windows

Описание

Релиз (программное обеспечение) - это

Релиз (программное обеспечение) это:

Релиз (программное обеспечение)

У этого термина существуют и другие значения, см. Релиз .

Релиз (жарг. от англ.   releaseвыпуск ) — выпуск окончательной версии программы — готового для использования продукта. В релизе обычно собирают все версии и обновления, и выпускают конечный продукт со всеми исправлениями, который не нужно обновлять, так как он является последней версией ПО .

Управление релизами

Релиз — это набор новых и/или измененных конфигурационных единиц, в отношении которых осуществлено тестирование и которые рекомендованы для использования одновременно.

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

Процесс Управления релизами состоит из трёх этапов:

  1. этап разработки: может, не всегда быть применим в той или иной организации, но для некоторых компаний, данный этап может являться одним из основополагающих, к ним могут относиться, например, компании по разработке программных средств или конструкторские бюро;
  2. этап тестирования: на данном этапе необходимо определить вначале критерии, по которым будет проводиться тестирование для каждого релиза, то есть определить степень определения готовности релиза к распространению и внедрению.
  3. этап распространения и внедрения.

На каждом предприятии процесс Управления релизами в той или иной степени исполняется и частично функционирует. Поэтому основной задачей внедрения данного процесса становится консолидация, структурирование и систематизация всех имеющихся компонентов процесса, их дополнение, а также описание процедур реализации существующих версий продуктов. Это позволит в дальнейшем разработать ряд так называемых корпоративных стандартов состава программно технических средств и процедур по их установке, которые в дальнейшем значительно упростят выполнение связанных процессов и сократят занятость высококвалифицированных специалистов.

Задача внедрения данного процесса значительно упростится благодаря функционирующему в организации процессу Управления конфигурациями, итогом которого является актуальная База данных Учётных Элементов (CMDB), в которую включены и описания всех используемых версий компонентов систем информационных технологий. Внедрение данного процесса позволит в дальнейшем так же вести централизованную Библиотеку версий программного обеспечения (DSL); склад горячей замены оборудования (DHS); а в некоторых случаях и специализированную библиотеку технической документации.

В случае успешного и правильного внедрения процесса Управления релизами пользователи получат:

  • Контроль над дополнительными лицензиями программного обеспечения;
  • Обучение пользователей и специалистов работе в усовершенствованных системах, что качественно улучшит взаимодействие с клиентами, и будет являться превентивным действием, способствующим продвижению новых технологий;
  • Оптимально распределенные ресурсы, необходимые для осуществления всех внедрений;
  • Снижение степени риска при внесении изменений в состав систем информационных технологий, а значит и самих сервисов;
  • Оптимизацию повторяющихся обновлений по времени и стоимости посредством их синхронизации и автоматизации;
  • Максимальный эффект от планируемых изменений;
  • Планирование расходов на осуществление тех или иных обновлений.

Отказ от реализации данного процесса приведёт к:

  • Несогласованности нескольких вносимых обновлений, которые эффективнее можно было бы внедрять совместно;
  • Неопределённости в ответственности, кто на самом деле распространяет и устанавливает все проводимые изменения;
  • Необоснованности приобретения дополнительных лицензий и компонентов информационных систем;
  • Риску, при котором ожидаемый эффект от вносимых изменений будет неоднозначен;
  • Вероятности, что будут задействованы неоправданные ресурсы при реализации тех или иных обновлений, эффект от которых будет поглощен затратами.

Успешное построение процесса Управления релизами во многом зависит от правильности реализации процесса Управления изменениями. Поэтому в некоторых случаях рекомендуется проводить комплексное внедрение этих двух процессов. Кроме того, немаловажную роль играет и построение такого процесса как Управление конфигурациями, который необходим для своевременной регистрации всех изменений в Базе данных Учётных элементов

См. также Смотреть что такое "Релиз (программное обеспечение)" в других словарях:

Системное программное обеспечение PlayStation Portable — Системное программное обеспечение PlayStation Portable  это официальная обновляемая прошивка для PlayStation Portable. Обновления добавляют новые возможности и вносят исправления в безопасность для предотвращения запуска программ без… … Википедия

Релиз — (Release) Содержание Содержание 1. Виды релиза 2. (программное обеспечение) 3. Музыкальный релиз Классификаций музыкальных релизов Статус музыкального релиза Тип релиза Формат релиза Прочие характеристики 4. Технология подготовки и написания… … Энциклопедия инвестора

релиз (в информационных технологиях) — Набор аппаратного обеспечения, программного обеспечения, документации, процессов или других Компонентов, которые необходимы для внедрения одного или нескольких согласованных изменений в ИТ услугах. [http://www.dtln.ru/slovar terminov] релиз (в… … Справочник технического переводчика

Стадии разработки программного обеспечения — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия

Blender — У этого термина существуют и другие значения, см. Blender (журнал) … Википедия

Bacula — Тип сетевое резервное копирование, архивирование и восстановление данных Написана на C++[1] Операционная система кроссплатформенная Последняя версия 5.2.10 (28 июня 2012) … Википедия

Subversion — У этого термина существуют и другие значения, см. Subversion (игра). Subversion Логотип Subversion Тип централизованная … Википедия

что такое релиз программы:

  • скачать
  • скачать
  • Другие статьи, обзоры программ, новости

    Что такое релиз?

    Что такое релиз?

    Те, кто работают в журналистике, сталкиваются с ними каждый день, причём не один раз. Мы имеем в виду пресс-релизы. Но то, что является простым и ясным для акул пера, может быть совсем непонятным для большинства людей. Итак, давайте разберемся – что такое пресс-релиз?

    Определение понятия «пресс-релиз»

    Пресс-релиз представляет собой некое сообщение для прессы, которое содержит в себе новость о частном лице или организации, о той или иной позиции по какому-то вопросу, высказанное для публикации в средствах массовой информации. Как правило, пресс-релизы раздают журналистам на пресс-конференциях и брифингах или рассылают по электронной почте.

    Виды пресс-релизов

    Определившись с тем, что такое релиз, перейдём к их классификации:

    • пресс-релиз-анонс. Сообщается информация о событии, которое ещё не случилось и должно произойти в ближайшее время. Разослав такой пресс-релиз своевременно, компания обеспечит присутствие журналистов на самом мероприятии;
    • пресс-релиз-новость. Сообщается информации о событии, которое уже произошло. Здесь можно подробно писать о прошедшем мероприятии и дать комментарии компетентных лиц.
    • пресс-релиз информационный. Сообщает о событии текущем, которое еще не завершилось. В нём сообщают о текущих изменениях, при этом подразумевается, что суть события уже сообщалась многим ранее.
    Как правильно написать пресс-релиз

    Вы уже знаете, что значит релиз, и каким он бывает. Теперь осталось рассказать, какова технология его написания.

    Пресс-релиз нужно писать, если ваша новость действительно интересна, иначе журналисты просто оставят её без внимания. Кроме того, релиз должен отвечать нескольким важным правилам:

    • информация интересна для аудитории тех изданий, в которые вы отправляете релиз;
    • информация актуальна;
    • она общественно значимая и близка читателям;
    • информация «свежая», произошедшая недавно;
    • в тексте есть несколько комментариев на обозначенную тему.

    Чем большим правилам будет соответствовать релиз, тем больше вероятность, что он заинтересует средства массовой информации.

    Что такое релиз и модельный релиз

    Что такое релиз и модельный релиз

    November 7, 2012

    Неологизм «релиз» появился сравнительно недавно, но уже прочно обосновался в русском языке. Однако точно, что такое релиз, знают относительно немногие. Имеется два варианта перевода этого слова с английского языка: «выпуск» и «освобождение».

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

    Молодых людей чаще интересует не второе значение этого слова, а первое, то есть «выпуск». Действительно, отвечая на вопрос «Что такое релиз?», трудно не вспомнить о том, что и демонстрация или публикация чего-либо, и показ фильма, и выпуск нового альбома либо новой версии программного обеспечения – всё это тоже называют релизом.

    Но иногда этим же словом называют не только выпуск, но и сам объект, который был выпущен недавно. Кроме того, часто выпуск чего-либо сопровождается специальным сообщением для печати, в котором указывается основная информация о продукте. СМИ никогда полностью не публикует весь пресс-релиз, а только опирается на эти материалы, создавая свои статьи или выступления.

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

    Вот такое многогранное слово явилось в русскую речь и осталось жить навсегда! Теперь-то уже никто не спросит, что такое релиз музыкальный или интернет-релиз. Например, скачал сынуля из интернета какую-то новую программу, запустил её, а она «парит мозги». Он к программисту: «Что, старик, это значит?» И «старик», почесав свой ещё не знавший бритвы подбородок, с умным видом ответит одногодку: «А что ты хотел? Эта программа ещё не имеет релиза! Ты, брат, поторопился, недоделку слизал!» Вот какое это властное слово – «релиз». Нет его – не стоит и мучиться понапрасну.

    А говоря о модельном бизнесе или о фотографировании, стоит уточнить, что «релиз модели» следует рассматривать как соглашение между тем, кто снимает, и тем, с кого эти снимки или видео делаются. Обязательно во время составления данного договора необходимо присутствие третьего лица – свидетеля. Ведь данное соглашение предусматривает право фотографа как на дальнейшую обработку материала (ретуширование, художественная правка), публикацию и распространение, так и на продажу материалов, демонстрацию на выставках и различных конкурсах.

    С другой стороны, этот договор обязательно защищает честь модели. Фотограф не имеет права производить над снимками действий, могущих опорочить честь и достоинство модели ни при помощи обработки снимков, ни добавлением «прикольных» надписей.

    По большему же счёту модельный релиз и самому фотографу крайне необходим. Это является гарантией в случаях возникновений конфликтных ситуаций, когда модель по какой-то причине высказывает своё недовольство какими-либо действиями со стороны фотографа. Например, модели не нравится тот факт, что её фото выложено в какой-либо социальной сети либо фотография принимает участие в выставке или фотосессии.

    Особого внимания заслуживает ситуация, когда фотография занимает призовое место, получает награду. Модель в этом случае может начать требовать с фотографа «своей доли». При наличии же релиза этот вопрос легко улаживается, ведь в нём обговариваются заранее все возможные спорные ситуации. И если выплата процентов по выгоде в нём не предусмотрена, то фотограф имеет полное право заявить модели: «Дорогая! Ты должна благодарить меня за то, что я сделал из тебя знаменитость! А насчёт денег… Ещё неизвестно, кто кому должен платить. Возможно, это я продешевил, однако…».

    Глава 8

    Глава 8. Управление Релизами 8.1. Введение

    С повышением зависимости организаций от ИТ-процессов все большее значение приобретает их эффективный мониторинг и защита. С ростом количества изменений возрастает и потребность в контроле над процессом проведения изменений.

    Изменения ИТ-инфраструктуры происходят в сложной распределенной среде. В современных приложениях клиент/сервер это часто отражается как на клиентской части, так и на серверной. В таких случаях запуск и внедрение новых версий программных и аппаратных средств требует тщательного планирования. Релизом называется набор новых и/или измененных Конфигурационных Единиц, которые вместе испытываются и внедряются в рабочую среду. Релиз определяется Запросом на Изменения (RFC), для исполнения которого он вводится в работу. В Процессе Управления Релизами используется плановый проектный подход к проведению изменений в ИТ-услугах, и он затрагивает все, как технические, так и нетехнические аспекты изменений.

    Задачей Процесса Управления Релизами является обеспечение качества рабочей среды[124] за счет использования формальных процедур и проверок при вводе в работу новых версий. В отличие от Управления Изменениями, занимающегося верификацией, Процесс Управления Релизами занимается внедрением. Управление Релизами осуществляется в тесном контакте с Управлением Конфигурациями и Управлением Изменениями, что гарантирует обновление единой базы CMDB с учетом каждого нового релиза. Управление Релизами также обеспечивает обновление содержания релизов (программных кодов) в Библиотеке эталонного программного обеспечения[125] DSL. С помощью базы CMDB также отслеживаются спецификации аппаратных средств, руководства по инсталляции и сетевые конфигурации. Запас аппаратных средств, в частности стандартизованные базовые конфигурации, хранится на Складе эталонного аппаратного обеспечения[126] DHS. Однако, в первую очередь объектом Процесса Управления Релизами является программное обеспечение.

    В больших проектах Процесс Управления Релизами должен включаться в общий план проекта как его составная часть для обеспечения достаточного финансирования работы процесса. Определенная часть ежегодного бюджета может быть выделена на повседневные работы, такие как незначительные изменения. Расходы, возникающие при запуске процесса, не столь значительны по сравнению с потенциальными потерями, вызванными недостатками в планировании и контроле за программными и аппаратными средствами, к которым можно отнести следующие:

    • большие перерывы в работе из-за плохого планирования выпуска релизов;

    • дублирование работ из-за наличия копий различных версий;

    • неэффективное использование ресурсов из-за отсутствия информации об их местонахождении;

    • потеря исходных файлов, приводящая к повторной закупке программ;

    • отсутствие защиты от вирусов, приводящее к необходимости «лечения» всей сети.

    8.1.1. Основные понятия

    Релизы содержат одно или несколько авторизованных изменений. Они могут классифицироваться в первую очередь по уровню релиза. Часто релизы разделяют на:

    Значительные релизы – крупномасштабное развертывание новых аппаратных и программных средств, обычно со значительно расширенными функциональными возможностями. Такие релизы часто помогают в устранении ряда известных ошибок, включая известные обходные решения[127] и быстрые исправления[128] .

    Малые программные релизы и модернизация аппаратного обеспечения (апгрейды) [129] – эти релизы обычно представляют собой незначительные усовершенствования и исправления известных ошибок. Среди них могут быть такие, которые внедрялись ранее в виде срочных исправлений и теперь окончательно проработаны и включены в данный релиз. За счет такого релиза обеспечивается обновление «Прежнего стабильного состояния[130] », являющегося отправной точкой для всех испытаний.

    Срочные исправления – обычно внедряются как быстрые исправления проблем и известных ошибок.

    В отношении аппаратного обеспечения вопросы возникают только при полной замене ПК или при раздельной замене плат и дисководов жестких дисков (или даже оперативной памяти и процессоров). Для программного обеспечения изменения возможны на уровне системы, комплекса, программы или модуля. Хорошим примером может быть библиотека DLL (Dynamic Link Library) в среде Windows, часто используемая несколькими программами. Иногда в составе пакета поставляется новая версия DLL, что может потребовать нового тестирования и переустановки всех других программных пакетов. В данном процессе также прорабатывается принцип минимального содержания релиза.

    Копии программ могут распространяться из Библиотеки DSL по соответствующим средам:

    Среда разработки — разработка новых версий может вестись на основе более ранних версий из Библиотеки DSL. С каждой новой версией увеличивается ее номер. Изменение программного обеспечения возможно только в среде разработки.

    Среда испытаний – среда для тестирования версий. Часто тестирование разделяют на технические испытания разработчиками, функциональные испытания пользователями, испытания внедрения компоновщиками релизов и, возможно, окончательные приемочные испытания пользователями и руководством.

    Рабочая среда – активная среда, где информационные системы доступны для пользователей.

    Архив – служит для хранения старых версий программных единиц, которые больше не используются.

    Так как возможно использование нескольких релизов, им присваиваются уникальные идентификаторы. В идентификационном номере релиза должна быть ссылка на соответствующую Конфигурационную Единицу, и он должен включать номер версии из двух или более цифр, например:

    Значительные релизы – система расчета зарплаты v.1, v.2, v.3 и т. п.

    Малые релизы – система расчета зарплаты v.1.1, v.1.2, v.1.3 и т. п.

    Релизы - срочные исправления – система расчета зарплаты v.1.1.1, v.1.1.2, v.1.1.3 и т. п.

    На рис. 8.1 показаны тестирование и возможные модификации каждой новой версии перед ее выпуском. Старая версия архивируется как часть запуска нового релиза на случай возможного возврата.

    На рис. 8.2 показан возврат.

    Рис. 8.1. Выпуск версии в Процессе Управления Релизами

    Рис. 8.2. Возврат в Процессе Управления Релизами

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

    Быстрая разработка и продвижение на рынок новых версий аппаратного и программного обеспечения может привести к тому, что релиз может устареть до его внедрения. С другой стороны, частые изменения могут оказать отрицательное воздействие на предоставление услуг.

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

    Дельта-релиз – в дельта-релиз включаются только измененные аппаратные и программные средства. Это часто связано с экстренными и быстрыми исправлениями. Недостатком этого типа релизов является то, что часто невозможно проверить все связи с остальной частью среды, в результате чего не удаляются модули, к которым программа больше не обращается. Дельта-релиз удобен в случае, если программное обеспечение может быть изолировано от остальной части ИТ-среды. Преимуществом дельта-релиза является то, что для создания тестовой среды требуется меньше усилий.

    Полный релиз – при полном релизе идет распространение полного комплекта ПО, включая неизмененные модули. Такой подход предпочтителен в случаях, когда точно не известно, что изменено в программном обеспечении. Более тщательные испытания программных и аппаратных средств обеспечивают в этом случае меньшее число инцидентов после внедрения. При подготовке полного релиза легче определить, достигается ли запланированный уровень производительности. Преимуществом полного релиза является возможность одновременного внедрения нескольких изменений. Подготовка облегчается благодаря возможности использования стандартных сценариев инсталляции[131]. Также при инсталляции может быть «очищена» программная среда. Однако полный релиз требует большей подготовки и ресурсов, чем дельта-релиз.

    Пакетный релиз – пакетный релиз, или комплект релизов, обеспечивает пользователям более длительные периоды стабильной работы. Исправление незначительных программных ошибок, с которыми пользователи могут мириться, и внедрение новых функций часто являются действиями, которые можно эффективно объединить. Так же плановые апгрейды, например системного программного обеспечения и офисных приложений от внешних разработчиков, могут включаться в пакетные релизы.

    Рис. 8.3. Типы релизов

    Библиотека эталонного программного обеспечения [132] (DSL)

    Библиотека эталонного программного обеспечения (DSL) – это надежное хранилище для эталонных авторизованных версий (мастер-копий) всех Конфигурационных Единиц программного обеспечения. Физически библиотека DSL может находиться в разных местах и состоять из нескольких надежных хранилищ и огнеустойчивых сейфов для носителей информации. Управление Релизами начинает контролировать жизненный цикл программ с момента их включения в библиотеку DSL. Релизы конфигурируются из известного надежного программного обеспечения, хранящегося в DSL. После этого разрабатываются инсталляционные скрипты[133]. а в децентрализованной среде могут быть записаны соответствующие компакт-диски.

    В библиотеке DSL может храниться несколько версий одного и того же программного обеспечения, включая архивные версии, документацию и исходные коды. Поэтому необходимо создание резервных копий[134] Библиотеки DSL, поскольку она содержит не только текущую версию программного обеспечения, но и копии на случай возврата к прежней версии. При наличии в компании нескольких территориальных объектов с локальным руководством, на каждом из них должна быть копия Библиотеки DSL на случай развертывания программного обеспечения.

    Склад эталонного аппаратного обеспечения [135] (DHS)

    Склад эталонного аппаратного обеспечения предназначен для хранения запасных аппаратных средств. Это запасные компоненты и узлы, состояние которых поддерживается на том же уровне, что и у соответствующих им компонентов в активной среде. Аппаратные средства со склада DHS используются для замены или ремонта аналогичных Конфигураций в ИТ-инфраструктуре. Информация о составе этих Конфигураций должна содержаться в базе CMDB.

    Конфигурационная База Данных (CMDB)

    В рамках всего Процесса Управления Релизами рекомендуется проверять информацию о Конфигурационных Единицах в базе CMDB. Как только версии программного обеспечения добавляются в Библиотеку DSL, а версии аппаратных средств – на Склад DHS, производится обновление CMDB. Для поддержки Процесса Управления Релизами база данных CMDB должна содержать информацию по следующим вопросам:

    • содержание запланированных релизов, включая Конфигурационные Единицы аппаратного и программного обеспечения со ссылкой на исходный Запрос на Изменения (RFC);

    • аппаратные и программные Конфигурационные Единицы, на которые может повлиять релиз;

    • данные о физическом местонахождении аппаратных средств, имеющих отношение к релизу.

    8.2. Цель процесса

    Процесс Управления Релизами занимается управлением и распространением (дистрибуцией) используемых в рабочей среде версий программного и аппаратного обеспечения, находящихся на поддержке ИТ-подразделения для обеспечения необходимого уровня услуг.

    Задачами Процесса Управления Релизами являются:

    • Планирование, координация и внедрение (или организация внедрения) программных и аппаратных средств.

    • Разработка и внедрение рациональных[136] процедур для распространения и инсталляции изменений в ИТ-системах.

    • Обеспечение отслеживаемости и безопасности программных и аппаратных средств, подвергшихся изменениям, и гарантирование того, что в рабочей среде находятся только корректные, авторизованные и тестированные версии.

    • Коммуникации и оповещение пользователей, учет их ожиданий при планировании и развертывании новых релизов.

    • Определение состава релизов и планирование их развертывания совместно с Процессом Управления Изменениями.

    • Внедрение новых версий программных и аппаратных средств в рабочую инфраструктуру под контролем Управления Изменениями и при поддержке Управления Конфигурациями. Релиз может включать любое количество Конфигурационных Единиц, а также не только программные и аппаратные средства, но и документацию, например, отчеты, планы, руководства по поддержке.

    • Обеспечение сохранности оригинальных копий программ в Библиотеке эталонного программного обеспечения (DSL) и регулярного обновления базы данных CMDB; то же касается аппаратных средств на Складе DHS.

    8.2.1. Преимущества использования процесса

    Вместе с эффективными Процессами Управления Конфигурациями и Управления Изменениями Процесс Управления Релизами способствует тому, чтобы:

    • Использовалось программное и аппаратное обеспечение высокого качества, которое разрабатывалось и тестировалось с проведением процедур контроля качества.

    • Сводилась к минимуму возможность возникновения ошибок в программно-аппаратных комплексах, или ошибок выпуска некорректных версий.

    • Бизнес-подразделения внимательно контролировали инвестиции в программное обеспечение, от которых во многом зависит бизнес.

    • Уменьшалось общее количество отдельно взятых внедрений, и проводились серьезные испытания каждого внедрения.

    • Уменьшалась опасность возникновения инцидентов и известных ошибок за счет тестирования и контроля внедрения.

    • Пользователи больше привлекались к участию в тестировании релизов.

    • Заранее публиковалась программа ввода релизов для улучшения координации ожиданий пользователей с политикой и практикой появления новых релизов.

    • Для целей бизнеса существовали структуры централизованного проектирования и компоновки программных и аппаратных средств или структуры для их закупки с последующим распространением по пользователям.

    • Бизнес-подразделения могли стандартизировать версии программного и аппаратного обеспечения в своих подразделениях для облегчения их поддержки.

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

    • Облегчалось обнаружение неавторизованных копий и некорректных версий.

    8.3. Процесс

    Процесс Управления Релизами состоит из следующих видов деятельности:

    • разработка политики в отношении релизов и их планирование;

    • компоновка и конфигурирование релизов;

    • тестирование и приемка релизов;

    • планирование развертывания релизов;

    • оповещение, подготовка и обучение;

    • распространение и инсталляция релизов.

    В действительности эти виды деятельности не располагаются в хронологическом порядке. Определение политики и планирование релизов могут проводиться раз в полгода или в год, в то время как другие действия могут проводиться ежедневно.

    Рис. 8.4. Управление Релизами

    Успешное проведение Управления Релизами зависит от входной информации, поступающей из других процессов ITIL, и от взаимодействия с этими процессами (рис. 8.4). Главными являются интерфейсы со следующими процессами.

    8.3.1. Управление Конфигурациями

    Управление Конфигурациями отвечает за регистрацию доступных версий программного и аппаратного обеспечения в базе данных CMDB в качестве Базисных Конфигураций. Программы, включаемые в Библиотеку DSL, и аппаратные средства для DHS регистрируются в CMDB с согласованным уровнем детализации. Мониторинг статуса, выполняемый Процессом Управления Конфигурациями, отражает статус каждой Конфигурационной Единицы, например, «В активном использовании», «В разработке», «В тестировании», «В запасе» или «В архиве».

    8.3.2. Управление Изменениями

    Деятельность по распространению (тиражированию) релизов контролируется Процессом Управления Изменениями. Кроме того, Управление Изменениями гарантирует, чтобы было проведено адекватное тестирование релизов. Управление Изменениями также принимает решение о количестве изменений, которые могут быть скомбинированы в одном релизе. Управление Изменениями определяет процедуры, обеспечивающие авторизацию изменений, включая анализ степени воздействия и анализ необходимых ресурсов. В большинстве случаев Руководитель Процесса Управления Релизами несет ответственность за внедрение программных и аппаратных изменений и он обычно участвует в работе Консультативного комитета по изменениям.

    8.3.3. Управление Уровнем Услуг

    ИТ-сервис обычно включает в себя инфраструктурное аппаратное обеспечение вместе со стандартным или разработанным собственными силами программным обеспечением. Управление Релизами отвечает за ввод в работу программных и аппаратных средств и отслеживает соглашения о доступности программных средств, заключенные в рамках Процесса Управления Уровнем Услуг.

    8.3.4. Виды деятельности

    На рис. 8.5 показаны виды деятельности в рамках Процесса Управления Релизами и их связи с жизненным циклом изменения.

    Рис. 8.5. Виды деятельности по Управлению Релизами (источник: OGC)

    8.4. Виды деятельности

    8.4.1. Выработка политики в отношении релизов и планирование

    Руководитель Процесса Управления Релизами разрабатывает политику в отношении релизов, определяя когда и каким образом производится конфигурирование релизов. Значительные релизы могут планироваться заранее, одновременно с присвоением номера версии, чтобы в определенные моменты времени можно было рассмотреть возможность внесения изменений.

    Руководитель Процесса Управления Релизами также определяет, на каком уровне Конфигурационные Единицы могут распространяться независимо друг от друга (релизные единицы). Это зависит от:

    • Потенциального воздействия релиза на другие компоненты.

    • Количества человеко-часов и времени на компоновку и тестирование раздельных изменений, в сравнении с усилиями, необходимыми для их объединения и одновременного внедрения.

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

    • Сложности взаимосвязей между новым программным и аппаратным обеспечением и остальной частью ИТ-инфраструктуры – чем легче изолировать программные или аппаратные средства, тем легче их тестировать.

    Перед планированием релиза необходимо собрать информацию о жизненном цикле внедряемого продукта, а также обо всех подготовленных к сдаче в рамках данного релиза продуктах, описании соответствующих ИТ-услуг и их уровней и данные об авторизации соответствующих Запросов на Изменения (RFC) и т. д. При планировании релиза рассматриваются следующие вопросы:

    • координация содержания релиза;

    • разработка графика ввода релиза;

    • согласование графика, территориальных объектов, на которых произойдет распространение релиза, и организационных единиц;

    • посещение объектов для определения реально используемых аппаратных и программных средств;

    • разработка плана оповещения (коммуникаций);

    • согласование ролей и ответственностей;

    • получение подробных коммерческих предложений и переговоры с поставщиками о новых аппаратных и программных средствах, а также услугах по их инсталляции;

    • разработка планов на случай возврата к исходному состоянию;

    • разработка плана обеспечения качества релиза;

    • планирование приемки релиза руководством и пользователями.

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

    8.4.2. Проектирование, компоновка и конфигурирование

    Рекомендуется выработать стандартные процедуры проектирования, компоновки и конфигурирования релизов. Основой релизов могут быть наборы компонентов (Конфигурационных Единиц – CI), разработанные внутри организации или закупленные у третьей стороны и прошедшие этап конфигурирования. Руководства по инсталляции и конфигурированию релизов должны рассматриваться как часть релиза и в качестве Конфигурационных Единиц должны включаться в число объектов, находящихся под контролем Процессов Управления Изменениями и Управления Конфигурациями.

    Перед инсталляцией на месте рекомендуется настроить и протестировать все аппаратное и программное обеспечение в «лабораторных условиях». Компоненты программных и аппаратных средств необходимо тщательно конфигурировать и зарегистрировать, чтобы обеспечить возможность их многократного воспроизведения. Необходимо разработать рабочие инструкции таким образом, чтобы каждый раз воспроизводился один и тот же набор компонентов. Часто в резерве имеются стандартизированные аппаратные средства, которые используется только для компилирования или создания образов ПО[137]. Для надежности желательно, чтобы эта часть процесса была автоматизирована. Необходимые для этого программные и аппаратные средства также попадают в сферу действия Процесса Управления Релизами. В среде разработки программ такая деятельность называется Управлением Компоновкой[138] и входит в зону ответственности Управления Релизами.

    План возврата к исходному состоянию

    В плане возврата к исходному состоянию на уровне релиза в целом определяются действия, необходимые для восстановления услуг в случае сбоя во время внедрения (имплементации) релиза. Ответственность за разработку планов возврата несет Процесс Управления Изменениями, но Управление Релизами должно оказывать в этом помощь для обеспечения практической реализуемости этих планов. В частности, при внедрении пакетного релиза, объединяющего несколько Запросов на Изменения (RFC), может возникнуть необходимость координации различных планов возврата для этого релиза. Если возникает сбой Полного релиза или Дельта-релиза, рекомендуется свернуть релиз полностью до Прежнего стабильного состояния[139]. На случай невозможности полного свертывания релиза должны существовать Планы восстановления на случай чрезвычайных обстоятельств[140] для возобновления предоставления услуг.

    Требования плана возврата к исходному состоянию, такие как создание резервных копий и обеспечение запасного сервера, рекомендуется выполнять заранее. В случаях, если внедрение может занять больше времени, чем предполагается, и если задержка может поставить под угрозу нормальное предоставление услуг, в план возврата должен включаться крайний срок, определяющий время приведения в действие плана возврата. Это требуется для своевременного возобновления услуг (например, не позднее 7:00 в понедельник). План возврата к исходному состоянию должен включаться в анализ рисков изменения и должен быть одобрен пользователями.

    Реальная компоновка релиза может включать компилирование и связывание программных модулей, или наполнение баз данных тестовыми данными, или такими данными, как таблицы почтовых индексов, налоговых ставок, часовых поясов и валютных курсов, а также информацией о пользователях. Часто это выполняется автоматизированными инсталляционными скриптами[141]. хранящимися в Библиотеке DSL вместе с планами возврата. Полные релизы должны отражаться в базе CMDB как Стандартные Конфигурации для облегчения конфигурирования в будущем. Планы тестирования должны включать тестирование и приемку по качеству программного и аппаратного обеспечения, процедур, инструкций по операционной деятельности и сценариев (скриптов) развертывания[142] перед выходом релиза и, возможно, оценочные испытания после внедрения релиза. Должно также проводиться тестирование инсталляционных скриптов. Для этого требуется следующая информация:

    • график ввода релиза;

    • инструкции по конфигурированию и компоновке релиза;

    • описание позиций, требующих приобретения или лицензирования, с приложением графиков закупки;

    • автоматизированные инсталляционные скрипты и планы тестирования;

    • исходные копии кодов программ для включения в библиотеку DSL;

    • планы возврата к исходному состоянию

    8.4.3. Тестирование и приемка релиза

    Наиболее частой причиной неудовлетворительного внедрения изменений и релизов является неадекватность тестирования. Для предотвращения этого перед внедрением релиза должно проводиться функциональное тестирование представителями пользователей и операционное (эксплуатационное) тестирование персоналом ИТ, оценивающим технические характеристики, функциональность, операционные (эксплуатационные) аспекты, производительность и интеграцию с остальной частью инфраструктуры. Также должны тестироваться инсталляционные скрипты, процедуры возврата и любые изменения процедур управления. Формальная приемка каждого этапа должна быть представлена в Процессе Управления Изменениями. Последним этапом является утверждение внедрения релиза.

    Перед тем, как Процесс Управления Релизами начнет развертывание релиза, Процесс Управления Изменениями должен организовать формальную приемку релиза пользователями и его окончательную сдачу разработчиками.

    Релизы должны приниматься в контролируемой тестовой среде, состоящей из Базовых Конфигураций, которые должны быть подробно описаны в ходе определения релиза. Соответствующие Базовые Конфигурации должны быть зарегистрированы в CMDB. Если релиз не принимается, он возвращается в Процесс Управления Изменениями.

    Результатами деятельности по тестированию и приемке релиза являются:

    • протестированные процедуры инсталляции;

    • протестированные компоненты релиза;

    • известные ошибки и недостатки релиза;

    • документация для управления и поддержки;

    • перечень систем, подвергающихся воздействию;

    • операционные (эксплуатационные) инструкции[144] и средства диагностики;

    • планы на случай непредвиденных ситуаций и протестированные планы возврата;

    • программы обучения персонала, руководителей и пользователей;

    • подписанные приемо-сдаточные документы;

    • авторизация из Процесса Управления Изменениями для выполнения релиза.

    8.4.4. Планирование внедрения

    Составленный на предыдущих этапах план теперь дополняется информацией о действиях по внедрению.

    Планирование развертывания релиза включает:

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

    • составление перечня инсталлируемых и снимаемых с использования Конфигурационных Единиц, с указанием способа вывода из операционной среды;

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

    • рассылку уведомлений о релизе и другие контакты с вовлеченными сторонами;

    • составление планов закупки аппаратного и программного обеспечения;

    • закупку, размещение на хранение, определение и регистрацию всех новых CI для данного релиза в базе CMDB;

    • планирование встреч с руководством, управляющими подразделениями, персоналом по Управлению Изменениями и представителями пользователей[145] .

    Существует несколько способов осуществления развертывания:

    • полное развертывание релиза – подход «большого скачка»;

    • поэтапное развертывание релиза, включающее несколько разновидностей:

    - функциональное наращивание, когда все пользователи получают одновременно новые элементы функциональности;

    - наращивание по объектам, когда развертывание ведется от одной группы пользователей к другой;

    - эволюционное развертывание с поэтапным расширением функциональности.

    8.4.5. Оповещение, подготовка и обучение

    Персонал, находящийся в контакте с заказчиками (Служба Service Desk и Управление Взаимоотношениями с Заказчиками – CRM), операционный (обслуживающий) персонал и представители пользователей должны быть в курсе планов внедрения и его возможных последствий для повседневной деятельности. Для этого можно организовать совместное обучение, сотрудничество и совместное участие в приемке релиза. Необходимо согласовать распределение ответственностей, с соответствующим уведомлением каждого. При поэтапном развертывании релиза пользователи должны быть проинформированы о планах и времени, когда для них будут доступны новые функции.

    Необходимо заранее информировать весь задействованный персонал об изменениях в Соглашениях об Уровне Услуг (SLA), Операционных Соглашениях об Уровне Услуг (OLA) и Внешних Договорах (UC).

    8.4.6. Распространение релизов и инсталляция

    Управление Релизами осуществляет мониторинг процессов логистики/материально-технического обеспечения по закупке, хранению, транспортировке, поставке и передаче программного и аппаратного обеспечения. Этот процесс поддерживается процедурами, регистрационными записями и такими сопроводительными документами, как упаковочные листы, что необходимо для предоставления достоверной информации в Процесс Управления Конфигурациями. Склады аппаратного и программного обеспечения должны быть надежными и доступными только для авторизованного персонала.

    Для распространения и инсталляции программного обеспечения рекомендуется, по возможности, использовать автоматизированные инструментальные средства. Это позволит сократить время, необходимое для распространения ПО, и повысить качество при сокращении затрат на ресурсы. Часто такие инструментальные средства также облегчают проверку успешности инсталляции. Перед началом любой инсталляции необходимо проверить, удовлетворяет ли среда, где предполагается внедрение релиза, необходимым требованиям, таким как достаточное дисковое пространство, безопасность, требованиям к окружающей среде или ограничениям эксплуатационных условий, например, кондиционирование воздуха, площадь помещения, источники бесперебойного питания (UPS), сетевое питание и т. п.

    После инсталляции необходимо обновить информацию в базе данных CMDB для облегчения проверки лицензионных соглашений.

    8.5. Затраты и проблемы

    Затраты на Процесс Управления Релизами включают:

    • затраты на персонал;

    • затраты на хранение в Библиотеке DSL и Складе DHS, а также на поддержку среды компоновки, тестирования и распространения релизов;

    • затраты на инструментальные программные средства и необходимое аппаратное обеспечение.

    Возможно возникновение следующих проблем:

    Сопротивление изменениям – вначале возможно сопротивление персонала, привыкшего к старым привычным методам работы. Например, некоторым сотрудникам бывает трудно принять тот факт, что для проведения определенной деятельности они будут получать инструкции из другого подразделения. Для устранения таких ситуаций необходимо информировать этих сотрудников о преимуществах подхода ITIL.

    Обход Процесса Управления Релизами – использование неавторизованных программ может привести к распространению вирусов, отрицательно повлиять на услуги и затруднить поддержку. Поэтому в отношении персонала и пользователей, пытающихся использовать неавторизованные программы, особенно в среде PC, должны быть предприняты решительные действия.

    Срочные исправления – не следует действовать в обход Процесса Управления Релизами даже при необходимости срочных изменений.

    Распространение – при развертывании программ на нескольких объектах необходимо обеспечить их синхронизацию, для предотвращения разницы версий на разных объектах.

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

    Примечания:

    ITIL является зарегистрированной торговой маркой агентства CCTA/OGC