для каких дефектов проверяется включение в состав релиза

Управление релизами и развертыванием в рамках Внедрения услуг

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

Основные цели Управления релизами и развертыванием:

Управление релизами и развертыванием отвечает за выпуск релизов и их эффективное использование заказчиками.

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

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

На рис. 9.1 представлено применение двух подходов.

Пофазовый подход имеет следующие вариации:

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

Рассмотрим последовательность действий в рамках Управления релизами и развертыванием.

Для развертывания релиза необходимо разработать различные планы, в частности, Планы релизов и развертывания. Они должны определять:

Пример, когда результат принимается:

Примеры, когда результаты отклоняются:

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

Среды, необходимые для релиза:

Планирование сборки пакета релизов содержит следующие процедуры:

В рамках составления планов развертывания необходимо ответить на следующие вопросы:

Далее разрабатываются Планы снабжения и предоставления. Они определяют следующее:

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Процесс «Управление релизами» — для постпроектной поддержки или развития продукта

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

Процесс «управление релизами», один из стека процессов ITSM, как раз и предлагает решение для формальной приоритизации и группировки запросов пользователей (запросов на изменения, инцидентов) в общие пакеты доставки — «релизы».

В данной статье кратко раскрываются следующие темы:

Применимость процесса

Когда целесообразно применять процесс, в дополнение к управлению инцидентами и управлению изменениями? Разумеется, в каждом случае набор критериев разный, но перечисленные ниже сценарии — хороший повод задуматься о релизах:

Этапы процесса

Процесс состоит из последовательности этапов. В разных реализациях процесса некоторые этапы могут быть объединены, или могут называться по другому — но общий принцип сохраняется

1. Draft

Активности:
Подбор запросов на изменения и инцидентов в список того, что планируется делать, проводится начальная приоритезация, анализ взаимозависимостей и предварительная оценка трудозатрат на анализ и разработку.

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

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

2. Scope

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

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

3. Approval

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

Результат:
Сформировано финальное содержание релиза.

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

4. Work in progress

Активности:
Разработка и исправление дефектов для всех заявок, вошедших в финальное содержимое релизов. Внутреннее тестирование и подготовка к приемочному тестированию.

Результат:
Заявки, включенные в содержание релиза — разработаны. Передача заказчику на приемочное тестирование.

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

5. Testing

Активности:
Проведение приемочного тестирования заказчиком, исправление выявленных ошибок, проведение необходимых доработок (по согласованию)

Результат:
Содержимое релиза протестировано, принято заказчиком, и готово к распространению.

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

6. Deployment

Активности:
Пакет изменений передается в эксплуатацию. Публикация новой версии продукта в продуктивной среде.

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

7. Closure

Активности:
Завершение работ над пакетом изменений: необходимые формальные шаги (документы, акты, счета ), обсуждение внутри команды результатов релиза.

Результат:
Формальное завершение работ. Улучшения процесса.

Планирование релизов

Как и любую активность, релизы нужно планировать. К счастью, управление релизами — это процесс, и поэтому при планировании можно рассчитывать на то что этапы, их взаимосвязь не меняются. Однако для планирования расписания релиза необходимо принципиально определиться с подходом к доставке:

Планирование релизов с фиксированной длительностью

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

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

Что будет меняться определенно — это ресурсы, доступные на каждом из этапов, в разных релизах (люди болеют, ходят в отпуск). Но с учетом перечисленных ограничений планирования это будет сказываться только на объем доставляемых изменений, а не на календарный план.

В целом, планирование релизов с фиксированной длительностью, и зависимостью объема доставки от наличия ресурсов — задача относительно несложная. В результате, процесс получается максимально предсказуемый и ритмичный, во многом близкий к Scrum.

Планирование релизов от объема доставки

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

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

Относительно сроков доставки, релизы, планируемые от объемов, также не предлагают заказчику большую определенность по сравнению с проектным подходом:

В дальнейшем будем обсуждать только детали, касающиеся релизов с фиксированной длительностью.

Календарное планирование релиза

Поскольку этапы определены, их взаимосвязи зафиксированы, и длительность каждого этапа будет неизменной, календарное планирование одно релиза не представляет сложности. Основной вопрос, с которыми необходимо определиться — длительность каждого из этапов.

Для этого можно попробовать использовать следующие данные, которые у вас могут быть на основании завершенного проекта:

Длительность этапов «Deployment» и «Closure» обычно устанавливается фиксированной, поскольку они на прямую не зависят от объема изменений. Разумеется, если зависимость в вашем случае существует — она должна учитываться.

После определения длительностей каждого из этапов, можно переходить к созданию «календаря проекта» — обозначение дат каждого из этапов. Если вы планируете регулярный выпуск обновлений — скажем ежемесячно, ежеквартально, — удобнее всего строить календарный план путем «обратного планирования», отталкиваясь от ожидаемых дат выпуска.

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

Одновременное выполнение нескольких релизов

Как видно из описания этапов релиза, на каждом из этапов вовлечены разные ресурсы и профиль загрузки — не однородный:

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

В случае, если вы строите процесс управления релизами с параллельными этапами — календарный план релиза должен учитывать перекрытия и загрузку ресурсов. Вполне возможно, что качественное расписание параллельно выполняемых релизов будет накладывать дополнительные требования на состав команды — так чтобы общая «выработка» Аналитиков и Разработчиков с учетом длительности этапов были равны.

Определение содержимого поставки при фиксированной длительности релиза

Посмотрим, из чего складывается ожидаемый объем содержимого релиза.

Фаза анализа требований

Объем заявок на изменения, которые могут быть проанализированы к рамках этапа «Scope» представляют максимальную неопределенность. Действительно — пока аналитик не начнет анализировать заявку, не поймет о чем идет речь, сказать сколько займет полный анализ очень сложно. Конечно, предварительный анализ заявок на стадии «Draft» поможет дать первую оценку, но ее можно использовать для распределения заявок между аналитиками — в зависимости от их специализации и опыта. Кроме того, необходимо учитывать, что аналитик вовлечен в приемочное тестирование — так что, анализом требований и передачей в разработку нагрузка на аналитика в рамках релиза не заканчивается.

Таким образом, первая оценка содержимого релиза может быть дана в терминах «количество заявок на аналитика в релиз». Наиболее пессимистичная оценка «1 заявка на изменение на аналитика в релиз» — с нее и стоит начинать. После того, как статистика по «производительности» аналитиков набрана — оценка содержимого станет более точной.

Подготовка технического решения

Работа по анализу технической реализации, на основании собранных требований, также требует времени и усилий — от группы разработки. Как правило, лидер группы отвечает за подготовку технической спецификации и оценки затрат на разработку.

Может случиться, что подготовка спецификаций занимает больше положенного времени и не укладывается в рамки стадии «Scope» — тогда запрос на изменение автоматически «выбывает» из содержимого текущего релиза.

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

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

Фиксация содержимого проекта

Оценка затрат на разработку, доступные ресурсы Разработчиков, доступность Заказчика для участия в приемочном тестировании — все это определяет финальное содержание релиза.

Итак, без учета переноса готовых запросов с предыдущих релизов — объем содержимого релиза ограничен сверху количеством проанализированных заявок (определяется ресурсами Аналитиков). Ограничения по ресурсам Разработчиков могут дополнительно сокращать объем релиза.

Известные проблемы

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

Переключение контекста при параллельных релизах

При планировании параллельных релизов возникает ситуация, когда все ресурсы — Аналитики, Заказчики и Разработчики должны «переключаться» между релизами. В частности, сценарии переключения следующие:

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

Ресурсные конфликты при нарушении календаря релиза

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

Исходя из конструкции этапов релиза и перехода между ними — наибольший негативный эффект имеет задержка этапов разработки и тестирования. Фазы анализа («Draft», «Scope», «Approval») имеют возможность понизить содержание релиза за счет переноса неоконченных заявок на следующий релиз — и это воспринимается заказчиком, обычно, легче, чем перенос из после утверждения содержания релиза.

Взятие «повышенных обязательств»

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

В качестве меры по можно использовать пессимистичную оценку объема ресурсов при фиксации содержимого релиза на этапе «Approval». Вообще тема «недооценки задачи/переоценки собственных сил и как с этим бороться» — очень дискуссионная. И решение очень сильно зависит от организационного окружения, в котором работает команда.

Реализация «больших» задач

Довольно часто в ходе анализа выясняется, что объем задачи не помещается во временные рамки этапа «Work in progress» — требуемый объем не получается разработать и доставить в рамках одного релиза.

Если увеличить ресурсы Разработчиков не представляется возможным, остается два возможных путей решения этой проблемы:

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

Устранение дефектов в контексте релизов

Обработка инцидентов и устранение дефектов, очевидно, занимают ресурсы команды (в большей мере — Разработчиков, но иногда и Аналитиков). Кроме того, нередко устранение некритических дефектов, имеющих известные способы обхода (workarounds) могут иметь меньшую ценность для бизнеса, по сравнению с требуемыми изменениями. Отсюда — очевидное желание рассматривать задачи устранения дефектов (или предоставления дополнительных сервисов) в общем контексте планирования содержания релиза — делать то, что важно.

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

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

Заключение

Серьезным преимуществом процесса релизов (особенно, при релизах с фиксированной длительностью) в глазах заказчика является заранее объявленное дата выпуска, обычно привязанная к определённым календарным точкам (например — ежемесячно, ежеквартально). Это позволяет строить прозрачный и ритмичный процесс, с ожидаемыми по срокам контрольными точками (переходами между этапами) и ожидаемыми результатами на каждой точке. Кроме того, заказчик непосредственно вовлечён в определение содержимого релиза путём определения приоритетов.

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

Источник

Единый регламент релизного процесса

1. Термины и сокращения

Релиз

Scope freeze

Дата и время фиксации состава релиза, которые указываются в графике релизов для каждого планового релиза (HF/SP/RC):

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

Финализация

Отправка релиз-менеджером релизной сборки в Эксплуатацию для установки на продуктивные стенды регионов. Сборка считается финализированной после отправки уведомления (см. шаблон №5 на странице Шаблоны писем-уведомлений). Это уведомление отправляется после успешного тестирования на prodlike-стендах всех регионов, указанных на релизной странице в блоке «Целевые Prodlike-стенды».

Плановый релиз

Релизы, которые выпускаются в соответствии с графиком релизов и планируются заранее. К плановым релизам относятся:

Если релиз выпускается незапланированно (в срочном порядке), то ему может быть присвоен только тип extraHF, вне зависимости от типов задач, включаемых в состав этого релиза.

Внеплановый релиз

Релизы, которые выпускаются в срочном порядке за рамками запланированного графика релизов. К внеплановым релизам относятся релизы с типом ExtraHF (Extra-hotfix).Типы релизов

RC (Release Candidate)

Плановый мажорный релиз, в который включаются:

Нумерация релиза: x.0.0

Дополнительного согласования состава релиза не требует.

В ту неделю, на которую приходится выпуск RC, не выпускается плановый недельный SP.

На текущий момент принят курс на уход от выпуска крупных RC во избежание большого количества аварий на регионах.
Вместо RC все доработки включаются в SP.
Отдельные масштабные доработки системы могут рассматриваться для выпуска в RC.

SP (Service Pack)

Плановый еженедельный релиз, в который включаются:

Нумерация релиза: x.y.0

Выпускается еженедельно (в среду). Дополнительного согласования состава релиза не требует.

Релиз с типом SP не может выпускаться во внеплановом порядке.

HF (Hotfix)

Плановый релиз, в который включаются только подсвеченные задачи одного из следующих типов:

Аргументы, которые НЕ являются основанием для включения задач в плановый хотфикс (HF):

Если в HF требуется включение задачи с аргументами из п. 1-5, то необходимо согласовать включение (см. Включение неподходящих по критериям задач в плановые HF).

Нумерация релиза: x.y.z

Выпускается каждый понедельник и четверг (фиксация состава релиза производится утром в день выпуска релиза). Включение задач в такой релиз должно быть согласовано с Руководителем направления РМ.

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

Релиз с типом HF не может выпускаться во внеплановом порядке.

ExtraHF (Extra Hotfix)

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

Нумерация релиза: x.y.z.w

Выпускается по требованию. Требуется согласование выпуска релиза с Руководителем направления РМ.

Инцидент

Ошибка, найденная на региональных стендах (Prodlike-стенд / продуктивный стенд). Оформляется через СКУФ и создаётся из задачи проекта PROMEDSKUF.

Ошибка

Внутренная ошибка, найденная на стороне Производства на стендах разработки (в процессе разработки по задаче любого типа, либо при регрессионном тестировании релиза).

История

Задача на доработку существующей функциональности / разработку новой функциональности.

Задача

Эпик

Реестры

What’s new

Описание для пользователей Системы новой функциональности, выпущенной в релизе.

Deployment Plan

Описание порядка действий (плана работ) при обновлении регионов на новую версию.

Типовой Deployment Plan Промед (стандартные операции при обновлении) приведён на странице Типовой DeploymentPlan PROMED.

План отката

План возврата Prodlike/продуктивного стенда на предыдущую версию при возникновении блокирующих ошибок при установке выпущенного релиза и невозможности их исправления в рамках обновления.Стенды разработки

Dev-стенд

Внутренний тестовый стенд, на котором ведётся тестирование задач до слития в релизную ветку. Для тестирования задач с региональными особенностями используется тестирование на региональных контейнерах (обновление происходит с использованием бота).

Командный стенд

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

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

Основной регрессионный стенд

Внутренний тестовый стенд для регрессионного тестирования плановых релизов (еженедельных SP и RC).

На текущий момент основной регрессионный стенд ещё не внедрён в работу.

Регрессионный экспресс-стенд

Внутренний тестовый стенд для регрессионного тестирования срочных релизов (внеплановых HF).

На текущий момент регрессионный экспресс-стенд ещё не внедрён в работу.

Релизный стенд

Prodlike-стенд

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

Prodlike-стенды регионов обновляются для тестирования релизных сборок через уведомления в почту (см. шаблон № 4 на странице Шаблоны писем-уведомлений).

Список Prodlike-стендов регионов представлен на странице https://svn.is-mis.ru/rmis_ver/promed_ver.html.

Beta-стенд

Внутренний стенд, находящийся в зоне ответственности Производства (в отличие от Prodlike-стендов, которые находятся в ЗО Эксплуатации), предназначенный для тестирования в релизной сборке региональных особенностей для регионов, у которых нет Prodlike-стенда.

Продуктивный стенд

Продуктивный стенд региона, на который финально устанавливается сборка релиза после тестирования на Prodlike-стенде региона и согласования установки сборки на продуктивный стенд.

Планирование обновлений продуктивных стендов находится в зоне ответственности Отдела эксплуатации.

Список продуктивных стендов регионов представлен на странице https://svn.is-mis.ru/rmis_ver/promed_ver.html.

2. Основные правила выпуска релизов

Релизы выпускаются (финализируются) последовательно. Плановые релизы (HF/SP/RC) выпускаются со строгим соблюдением версионности, т.е. плановый сервис-пак (SP) не финализируется до тех пор, пока не будут выпущены и влиты в него все плановые хотфиксы (HF) с меньшей версией.

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

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

2При переносе даты финализации релиза Релиз-менеджер оперативно актуализирует дату выпуска на релизной странице и в графике релизов. Перенос даты финализации релиза должен производиться заблаговременно до ранее установленного времени (минимум за 1 час).3

После установки сборки релиза на Rpodlike-стенды регионов допускается внесение правок в релизную сборку с последующим дообновлением уже обновлённых Prodlike-стендов до актуального состояния с учётом последних изменений.

После того, как релиз финализирован (см. Шаг 11. Подготовка релиза к выпуску, финализация релиза), запрещены все коммиты в релизную ветку. При нахождении критических / блокирующих ошибок инициируется выпуск внепланового хотфикса.

В процессе релизного цикла на релизной странице релиза ответственный за этап отмечает факт исполнения этапа в блоке «График подготовки релиза» в колонке «Факт выполнения»:

Источник