Как использовать шаблон
В релизной стратегии указывают участников релизного процесса, порядок работ, условия перехода между этапами и документы, подтверждающие готовность. Заполните шаблон для своей системы и согласуйте его с заинтересованными участниками.
- Опишите систему, рабочие пространства, контуры и участников.
- Определите календарь, правила ветвления, версии и порядок согласований.
- Для планового и срочного релиза укажите применимость этапов, исполнителей и подтверждающие документы. Проверьте критерии начала и окончания каждого этапа.
- Зафиксируйте согласованную редакцию в своей базе знаний и ведите историю изменений.
Названия полей и статусов в критериях служат примером настройки трекера. Укажите соответствующие поля и статусы своей системы, сохранив состав сведений и условия готовности.
Виды проверок и термины
- ФТ: функциональное тестирование изменений системы.
- ИФТ: интеграционное функциональное тестирование взаимодействий со смежными системами.
- РТ: регрессионное тестирование по актуальной модели.
- НТ: нагрузочное тестирование по актуальному профилю.
- Smoke: базовые проверки работоспособности; объем задается отдельно от РТ и НТ.
- Sanity check: целевые проверки измененного поведения. Системный аналитик определяет влияние изменений, тестировщик выбирает и выполняет проверки.
- Приемочные проверки: проверка выполнения согласованных требований с фиксацией результата.
- Feature freeze: запрет новых функциональных изменений в релизной ветке. Исключения согласуются отдельно.
- Code freeze: запрет изменений кода на указанном в стратегии этапе.
- Code Review: проверка кода перед принятием запроса на слияние.
- Инсталляционные проверки: первичные и итоговые проверки установки с отдельным отчетом.
Общая информация о системе
- Название и назначение
- ЗаполнитеУкажите систему, ее функции и решаемые задачи.
- Класс критичности
- ЗаполнитеУкажите класс по принятой в организации классификации.
- Стадия эксплуатации
- ЗаполнитеУкажите текущую стадию жизненного цикла системы.
- Пространство задач
- ЗаполнитеУкажите проект системы в трекере задач.
- База знаний
- ЗаполнитеУкажите раздел базы знаний с документацией системы и релизов.
- Проект тестирования
- ЗаполнитеУкажите проект с тест-кейсами и результатами проверок.
- График обновлений
- ЗаполнитеПриложите календарь плановых обновлений и порядок его актуализации.
Что может повлиять на релиз
Для каждого риска создайте запись в паспорте рисков. Ответственный за риск определяет меры реагирования, релиз-менеджер фиксирует их вместе с описанием риска.
- Название
- ЗаполнитеКратко обозначьте риск.
- Причина
- ЗаполнитеОпишите, почему риск может реализоваться.
- Последствия
- ЗаполнитеУкажите последствия реализации риска.
- Меры реагирования
- ЗаполнитеОпишите план устранения или компенсирующие меры.
Карта коммуникаций
Для каждой роли укажите исполнителя, команду и контакт. Если исполнителей несколько, распределите между ними работу. Укажите, кто замещает релиз-менеджера.
- Бизнес-заказчик или владелец системы
- ЗаполнитеУкажите представителя бизнеса, который согласует требования и перенос минорных дефектов, а для срочного релиза — обоснование срочности.
- Тимлид
- ЗаполнитеУкажите руководителя каждой команды.
- Бизнес-аналитик
- ЗаполнитеУкажите исполнителя, который готовит и актуализирует бизнес-требования.
- Системный аналитик
- ЗаполнитеУкажите исполнителя, который описывает системные требования, логику и интерфейсы, определяет затронутое поведение и интеграционные зависимости.
- Разработчик
- ЗаполнитеУкажите исполнителей разработки и участников Code Review — проверки кода перед принятием запроса на слияние.
- Релиз-менеджер
- ЗаполнитеУкажите координатора релиза и его заместителя. Релиз-менеджер сообщает даты контрольных точек, собирает согласования и фиксирует решения.
- Менеджер по качеству
- ЗаполнитеУкажите участника, который планирует и координирует тестирование, организует оценку качества и готовит заключение о готовности по результатам проверок.
- Тестировщик
- ЗаполнитеУкажите исполнителей, которые готовят тест-кейсы и данные, проверяют покрытие требований, актуализируют регрессионную модель, проводят функциональные и регрессионные проверки, фиксируют результаты и дефекты.
- Инженер по нагрузочному тестированию
- ЗаполнитеУкажите исполнителя, который готовит профиль и сценарии нагрузки, проводит нагрузочное тестирование и оформляет результаты.
- Ответственный за подготовку среды
- ЗаполнитеУкажите участника, который организует подготовку и обновление контуров, и его зону ответственности относительно DevOps.
- DevOps
- ЗаполнитеУкажите исполнителей установки сборок и инсталляционных проверок.
- Сопровождение
- ЗаполнитеУкажите участников согласования работ и проверки системы после внедрения.
- Другие участники
- ЗаполнитеУкажите ответственного за техническую документацию. При необходимости добавьте участников других видов тестирования и дополнительных согласующих.
Контуры системы
Заполните перечень контуров своей системы. Для каждого укажите реквизиты, ответственного за контур и ответственного за установку. Ниже приведены пять типовых контуров; адаптируйте перечень под свою систему.
dev
Разработка- Реквизиты контура
- ЗаполнитеУкажите адреса сервисов, идентификатор стенда или инфраструктурного ресурса и ссылку на описание контура.
- Ответственный за контур
- ЗаполнитеУкажите сотрудника или команду, отвечающих за контур, и контакт для связи.
- Ответственный за установку
- ЗаполнитеУкажите сотрудника или команду, выполняющих установку сборок на этот контур, и контакт для связи.
test
Функциональные и регрессионные проверки- Реквизиты контура
- ЗаполнитеУкажите адреса сервисов, идентификатор стенда или инфраструктурного ресурса и ссылку на описание контура.
- Ответственный за контур
- ЗаполнитеУкажите сотрудника или команду, отвечающих за контур, и контакт для связи.
- Ответственный за установку
- ЗаполнитеУкажите сотрудника или команду, выполняющих установку сборок на этот контур, и контакт для связи.
LT
Нагрузочное тестирование- Реквизиты контура
- ЗаполнитеУкажите адреса сервисов, идентификатор стенда или инфраструктурного ресурса и ссылку на описание контура.
- Ответственный за контур
- ЗаполнитеУкажите сотрудника или команду, отвечающих за контур, и контакт для связи.
- Ответственный за установку
- ЗаполнитеУкажите сотрудника или команду, выполняющих установку сборок на этот контур, и контакт для связи.
preprod
Приемочные и инсталляционные проверки- Реквизиты контура
- ЗаполнитеУкажите адреса сервисов, идентификатор стенда или инфраструктурного ресурса и ссылку на описание контура.
- Ответственный за контур
- ЗаполнитеУкажите сотрудника или команду, отвечающих за контур, и контакт для связи.
- Ответственный за установку
- ЗаполнитеУкажите сотрудника или команду, выполняющих установку сборок на этот контур, и контакт для связи.
production
Промышленная эксплуатация- Реквизиты контура
- ЗаполнитеУкажите адреса сервисов, идентификатор стенда или инфраструктурного ресурса и ссылку на описание контура.
- Ответственный за контур
- ЗаполнитеУкажите сотрудника или команду, отвечающих за контур, и контакт для связи.
- Ответственный за установку
- ЗаполнитеУкажите сотрудника или команду, выполняющих установку сборок на этот контур, и контакт для связи.
Процесс и правила работы с ветками
Релиз-менеджер планирует состав и контрольные точки. Команда фиксирует сборку и проводит предусмотренные стратегией функциональные, интеграционные и регрессионные проверки. После согласования работ DevOps устанавливает сборку на production. Релиз-менеджер организует оценку внедрения и закрытие релиза.
- Планирование
- Фиксация сборки и ФТ / ИФТ
- Приемка релиза
- Внедрение
- Оценка
- Закрытие
На схеме фиксация сборки и ФТ / ИФТ объединены. В стратегии укажите их порядок, допустимые возвраты и исключения.
- Начало разработки
- ЗаполнитеОт какой ветки создается ветка доработки (feature) и в каких случаях выбирается другая база.
- Запрос на слияние
- ЗаполнитеИсходная и целевая ветки, участники Code Review и условия принятия запроса на слияние (Merge Request).
- Сборка к выпуску
- ЗаполнитеИз какой ветки собирается версия и когда устанавливается тег релиза.
- После установки
- ЗаполнитеВ какой ветке фиксируется код установленной на production версии и как туда попадают изменения.
- Срочное исправление
- ЗаполнитеОткуда создается ветка срочного исправления (hotfix), куда она возвращается и когда применим выборочный перенос коммитов (cherry-pick).
Проверьте описание веток перед согласованием
Если для feature допускаются разные базовые ветки, укажите условия выбора каждой. Для релизной сборки проверьте весь путь изменений: от рабочей ветки через запрос на слияние до ветки сборки и тега выпуска.
Для hotfix опишите, куда возвращаются изменения после установки. Если используете выборочный перенос коммитов, укажите, в каких случаях он допустим.
Версионирование и нумерация релизов
- Правила версионирования
- ЗаполнитеОпишите формат версии системы и правила изменения ее частей.
- Нумерация релиза
- ЗаполнитеОпишите, как присваивается номер релиза и как он соотносится с версией сборки и тегом.
Укажите правила, действующие для вашей системы. Формат номера релиза может отличаться от формата версии сборки; опишите их связь.
Плановый релиз
Для каждого этапа проверьте условия начала и окончания, ответственных и документы. Если релиз затрагивает смежные системы, выполните также интеграционные критерии этапа.
Планирование
Для каждого релиза
Критерии начала
Команда создала задачи в трекере, указала их типы и приоритеты.
Команда декомпозировала и оценила задачи, для которых это требуется, и заполнила поле «Планируется в версии».
Релиз-менеджер добавил версию в реестр трекера.
Дата выпуска определена согласно графику плановых обновлений.
Создана задача типа «Релиз», установлен статус «Планирование».
Критерии окончания
Релиз-менеджер определил контрольные точки этапов и сообщил участникам их даты.
Релиз-менеджер создал паспорт релиза и рассчитал его емкость.
Релиз-менеджер включил задачи в состав релиза с учетом емкости, оценок и приоритетов и заполнил поле «Исправить в версии».
Создан паспорт рисков.
Релиз-менеджер внес в паспорт рисков выявленные риски и меры, которые подготовили ответственные за них.
Разработка
Для задач с разработкой
Критерии начала
Если нужны бизнес-требования, бизнес-аналитик подготовил или актуализировал их. Бизнес-заказчик и тестировщик согласовали требования в своих зонах ответственности.
Системный аналитик подготовил или актуализировал техническое задание либо описание. Документ согласован, в том числе тестировщиком со стороны тестирования.
Дизайн готов, если требуется.
Задача назначена разработчику.
Критерии окончания
Дизайн интерфейса прошел проверку (Design Review), если она требуется.
Разработчики провели Code Review; запрос на слияние (Merge Request) принят.
Исполнитель закрыл подзадачи «Разработка», если они создавались.
Релиз-менеджер внес в паспорт рисков выявленные риски и меры, которые подготовили ответственные за них.
Интеграционные задачи и смежные системы
Критерии начала
Если нужны интеграционные бизнес-требования, бизнес-аналитик актуализировал их с учетом смежной системы и согласовал отсутствие противоречий.
Системный аналитик актуализировал интеграционное техническое задание или описание вместе со смежной системой. В документе описаны переключатели функциональности и откат.
Если требуется согласование со смежной системой, системный аналитик подтвердил с ее представителями отсутствие противоречий в техническом задании.
Системный аналитик связал задачи со смежной системой по правилам стратегии и описал порядок установки ее изменений в User Story или комментариях к ней.
Критерии окончания
Релиз-менеджер сообщил об интеграционной задаче релиз-менеджеру, менеджеру по качеству, системному аналитику и тестировщику смежной системы. Состав задач указан в паспорте релиза.
Функциональное и интеграционное тестирование
ФТ / ИФТ
Критерии начала
Если для этапа предусмотрен feature freeze, новые функциональные изменения в релизную ветку не вносятся. Исключение допускается после анализа доработки и согласования с релиз-менеджером и менеджером по качеству.
Тестировщик подготовил тест-кейсы; менеджер по качеству согласовал набор проверок для этапа.
Тестировщик проверил полноту покрытия технического задания тест-кейсами.
Актуальные сетевые схемы, техническая документация и инструкции переданы ответственному за среду и DevOps.
Тестовая среда подготовлена на основании документации разработки и архитекторов.
Тестовая сборка успешно установлена на стенд.
Менеджер по качеству подтвердил готовность к началу ФТ и, для интеграционных задач, ИФТ.
Участники уведомлены о старте ФТ / ИФТ; задача релиза в статусе «ФТ / ИФТ».
Критерии окончания
Тестировщик выполнил ФТ и применимые ИФТ и сохранил результаты.
Исполнитель закрыл подзадачи «Тестирование», если они создавались. Задача переведена в статус «Готова к внедрению».
Обнаруженные ошибки зарегистрированы.
Тестировщик подтвердил отсутствие ошибок, блокирующих релиз. Менеджер по качеству проверил результаты; релиз-менеджер учел их при проверке готовности этапа.
Релиз-менеджер внес в паспорт рисков выявленные риски и меры, которые подготовили ответственные за них.
Интеграционные задачи и смежные системы
Критерии начала
Релиз-менеджер передал перечень интеграционных задач релиз-менеджерам, менеджерам по качеству, системным аналитикам и тестировщикам участвующих систем.
Для каждой системы созданы задачи на тестирование. Системный аналитик определил затронутое поведение и интеграционные зависимости; тестировщик подготовил по этой информации интеграционные тест-кейсы.
Системный аналитик и тестировщик согласовали интеграционные тест-кейсы с участниками смежной системы: аналитик уточнил поведение и зависимости, тестировщик проверил состав проверок.
Менеджер по качеству согласовал план тестирования с порядком установки систем.
Ответственный за среду организовал обновление тестового контура. Технические условия и документацию предоставляет системный аналитик или разработка, условия проверок — тестировщик; менеджер по качеству координирует подготовку к тестированию.
Сборка успешно установлена на тестовые стенды каждой системы в согласованном порядке.
В каждой участвующей системе подготовлены тестовые данные для ИФТ.
Зафиксирован состав интеграционных задач.
Критерии окончания
Тестировщики участвующих систем выполнили ФТ и ИФТ и сохранили результаты.
Регрессионное тестирование
РТ
Критерии начала
Если для этапа предусмотрен feature freeze, новые функциональные изменения в релизную ветку не вносятся. Исключение допускается после анализа доработки и согласования с релиз-менеджером и менеджером по качеству.
Сборка для РТ подготовлена и успешно установлена на соответствующий контур.
Среда подготовлена к регрессионному тестированию.
Тестировщик актуализировал модель РТ.
Задача релиза в статусе «Приемка релиза»; участники уведомлены о старте РТ.
Критерии окончания
Тестировщик выполнил проверки по модели РТ и сохранил результаты.
Тестировщик подтвердил отсутствие блокирующих и критичных ошибок; менеджер по качеству проверил результаты.
Тестировщик указал минорные дефекты, предлагаемые к переносу. Менеджер по качеству оценил их влияние на готовность релиза. Релиз-менеджер зафиксировал согласование переноса с бизнес-заказчиком.
Релиз-менеджер внес в паспорт рисков выявленные риски и меры, которые подготовили ответственные за них.
Интеграционные задачи и смежные системы
Критерии начала
Сборка установлена на стенд РТ каждой системы в согласованном порядке.
Критерии окончания
Тестировщики участвующих систем выполнили регрессионное тестирование.
Нагрузочное тестирование
НТ, при необходимости
Критерии начала
Введен code freeze: внесение изменений в код не допускается.
Инженер по нагрузочному тестированию актуализировал профиль нагрузки.
Сборка для НТ подготовлена и успешно установлена на контур.
Среда подготовлена к нагрузочному тестированию.
Участники уведомлены о старте НТ.
Критерии окончания
Инженер по нагрузочному тестированию выполнил проверки и сохранил результаты.
Инженер по нагрузочному тестированию подтвердил отсутствие блокирующих и критичных ошибок; менеджер по качеству проверил результаты.
Инженер по нагрузочному тестированию указал минорные дефекты, предлагаемые к переносу. Менеджер по качеству оценил их влияние на готовность релиза. Релиз-менеджер зафиксировал согласование переноса с бизнес-заказчиком.
Релиз-менеджер внес в паспорт рисков выявленные риски и меры, которые подготовили ответственные за них.
Интеграционные задачи и смежные системы
Критерии начала
Ответственный за среду организовал обновление тестового контура. Технические условия и документацию предоставляет системный аналитик или разработка, условия проверок — тестировщик; менеджер по качеству координирует подготовку к тестированию.
Сборка установлена на нагрузочный стенд каждой системы в согласованном порядке.
Критерии окончания
Системный аналитик определил затронутые зависимости, включая смежную систему. Инженер по нагрузочному тестированию подготовил и выполнил соответствующие нагрузочные сценарии. Тестировщик выполнил smoke-проверки, если они входят в выбранный по оценке влияния объем.
Приемочные и инсталляционные проверки
При необходимости и при наличии условий для выполнения проверок
Критерии начала
Сборка установлена на preprod для приемочных и инсталляционных проверок.
Критерии окончания
Выполнены первичные и итоговые инсталляционные проверки.
Системный аналитик определил затронутое поведение; тестировщик выбрал и выполнил целевые проверки (sanity check) по этой информации.
Тестировщик выполнил приемочные проверки и сохранил результаты.
Релиз-менеджер внес в паспорт рисков выявленные риски и меры, которые подготовили ответственные за них.
Интеграционные задачи и смежные системы
Критерии начала
Ответственный за среду организовал обновление тестового контура. Технические условия и документацию предоставляет системный аналитик или разработка, условия проверок — тестировщик; менеджер по качеству координирует подготовку к тестированию.
Сборка установлена на preprod каждой системы в согласованном порядке.
Критерии окончания
Системный аналитик определил затронутое поведение смежных систем; тестировщик выбрал и выполнил sanity check для приемки.
Менеджер по качеству каждой участвующей системы подготовил заключение о готовности к установке по результатам проверок тестировщика. Заключение учитывается при согласовании внедрения по установленному маршруту.
Внедрение
Выход на production
Критерии начала
План внедрения сформирован и согласован.
Запрос на проведение работ согласован.
Все задачи переведены в статус «Оценка» или «Закрыта».
Релиз-менеджер уведомил участников о работах и при необходимости подготовил описание изменений (release notes).
Задача релиза в статусе «Внедрение».
Критерии окончания
Релиз установлен на production; чек-лист в плане внедрения заполнен.
Сопровождение, дополнительный согласующий 3 и бизнес-заказчик выполнили проверки и подтвердили корректную работу системы.
Интеграционные задачи и смежные системы
Критерии начала
Сформирован и согласован план внедрения, учитывающий задачи смежных систем.
Пострелиз
Оценка результата и завершение
Критерии начала
Менеджер по качеству подвел итоги проверок, релиз-менеджер — итоги выпуска.
Менеджер по качеству проанализировал дополнительные материалы, если они есть. Их состав указан в стратегии.
Релиз-менеджер направил участникам опрос о работе релизного процесса.
Задача релиза в статусе «Оценка».
Критерии окончания
Релиз-менеджер оценил качество внедрения.
Подготовлен дайджест релиза с выбранной периодичностью: по релизу или по кварталу.
Проведена ретроспектива; сформированы поручения и задачи на улучшение по ее итогам.
Задача релиза в статусе «Закрыта».
Срочный релиз
Бизнес-заказчик оформляет и согласует обоснование срочности. Релиз проходит отдельный маршрут согласования. Регрессионные и smoke-проверки, дайджест и ретроспектива выполняются при необходимости; остальные критерии приведены по этапам ниже.
Планирование
Для каждого релиза
Критерии начала
Команда создала задачи в трекере, указала их типы и приоритеты.
Команда декомпозировала и оценила задачи, для которых это требуется, и заполнила поле «Планируется в версии».
Релиз-менеджер добавил версию в реестр трекера.
Дата выпуска определена по принятому в стратегии правилу для срочных обновлений.
Создана задача типа «Релиз», установлен статус «Планирование».
Критерии окончания
Релиз-менеджер определил контрольные точки этапов и сообщил участникам их даты.
Релиз-менеджер создал паспорт релиза и рассчитал его емкость.
Релиз-менеджер включил задачи в состав релиза с учетом емкости, оценок и приоритетов и заполнил поле «Исправить в версии».
Создан паспорт рисков.
Релиз-менеджер внес в паспорт рисков выявленные риски и меры, которые подготовили ответственные за них.
Разработка
Для задач с разработкой
Критерии начала
Если нужны бизнес-требования, бизнес-аналитик подготовил или актуализировал их. Бизнес-заказчик и тестировщик согласовали требования в своих зонах ответственности.
Системный аналитик подготовил или актуализировал техническое задание либо описание. Документ согласован, в том числе тестировщиком со стороны тестирования.
Дизайн готов, если требуется.
Задача назначена разработчику.
Критерии окончания
Дизайн интерфейса прошел проверку (Design Review), если она требуется.
Разработчики провели Code Review; запрос на слияние (Merge Request) принят.
Исполнитель закрыл подзадачи «Разработка», если они создавались.
Релиз-менеджер внес в паспорт рисков выявленные риски и меры, которые подготовили ответственные за них.
Интеграционные задачи и смежные системы
Критерии начала
Если нужны интеграционные бизнес-требования, бизнес-аналитик актуализировал их с учетом смежной системы и согласовал отсутствие противоречий.
Системный аналитик актуализировал интеграционное техническое задание или описание вместе со смежной системой. В документе описаны переключатели функциональности и откат.
Если требуется согласование со смежной системой, системный аналитик подтвердил с ее представителями отсутствие противоречий в техническом задании.
Системный аналитик связал задачи со смежной системой по правилам стратегии и описал порядок установки ее изменений в User Story или комментариях к ней.
Критерии окончания
Релиз-менеджер сообщил об интеграционной задаче релиз-менеджеру, менеджеру по качеству, системному аналитику и тестировщику смежной системы. Состав задач указан в паспорте релиза.
Функциональное и интеграционное тестирование
ФТ / ИФТ
Критерии начала
Если для этапа предусмотрен feature freeze, новые функциональные изменения в релизную ветку не вносятся. Исключение допускается после анализа доработки и согласования с релиз-менеджером и менеджером по качеству.
Тестировщик подготовил тест-кейсы; менеджер по качеству согласовал набор проверок для этапа.
Тестировщик проверил полноту покрытия технического задания тест-кейсами.
Актуальные сетевые схемы, техническая документация и инструкции переданы ответственному за среду и DevOps.
Тестовая среда подготовлена на основании документации разработки и архитекторов.
Тестовая сборка успешно установлена на стенд.
Менеджер по качеству подтвердил готовность к началу ФТ и, для интеграционных задач, ИФТ.
Участники уведомлены о старте ФТ / ИФТ; задача релиза в статусе «ФТ / ИФТ».
Критерии окончания
Тестировщик выполнил ФТ и применимые ИФТ и сохранил результаты.
Исполнитель закрыл подзадачи «Тестирование», если они создавались. Задача переведена в статус «Готова к внедрению».
Обнаруженные ошибки зарегистрированы.
Тестировщик подтвердил отсутствие ошибок, блокирующих релиз. Менеджер по качеству проверил результаты; релиз-менеджер учел их при проверке готовности этапа.
Релиз-менеджер внес в паспорт рисков выявленные риски и меры, которые подготовили ответственные за них.
Интеграционные задачи и смежные системы
Критерии начала
Релиз-менеджер передал перечень интеграционных задач релиз-менеджерам, менеджерам по качеству, системным аналитикам и тестировщикам участвующих систем.
Для каждой системы созданы задачи на тестирование. Системный аналитик определил затронутое поведение и интеграционные зависимости; тестировщик подготовил по этой информации интеграционные тест-кейсы.
Системный аналитик и тестировщик согласовали интеграционные тест-кейсы с участниками смежной системы: аналитик уточнил поведение и зависимости, тестировщик проверил состав проверок.
Менеджер по качеству согласовал план тестирования с порядком установки систем.
Ответственный за среду организовал обновление тестового контура. Технические условия и документацию предоставляет системный аналитик или разработка, условия проверок — тестировщик; менеджер по качеству координирует подготовку к тестированию.
Сборка успешно установлена на тестовые стенды каждой системы в согласованном порядке.
В каждой участвующей системе подготовлены тестовые данные для ИФТ.
Зафиксирован состав интеграционных задач.
Критерии окончания
Тестировщики участвующих систем выполнили ФТ и ИФТ и сохранили результаты.
Регрессионное тестирование и smoke
При необходимости; выберите виды и объем проверок для срочного релиза
Критерии начала
Если для этапа предусмотрен feature freeze, новые функциональные изменения в релизную ветку не вносятся. Исключение допускается после анализа доработки и согласования с релиз-менеджером и менеджером по качеству.
Сборка для выбранных регрессионных или smoke-проверок подготовлена и успешно установлена на соответствующий контур.
Среда подготовлена к регрессионному тестированию.
Тестировщик актуализировал модель выбранных регрессионных или smoke-проверок.
Задача релиза в статусе «Приемка релиза»; участники уведомлены о старте выбранных регрессионных или smoke-проверок.
Критерии окончания
Тестировщик выполнил проверки по модели выбранных регрессионных или smoke-проверок и сохранил результаты.
Тестировщик подтвердил отсутствие блокирующих и критичных ошибок; менеджер по качеству проверил результаты.
Тестировщик указал минорные дефекты, предлагаемые к переносу. Менеджер по качеству оценил их влияние на готовность релиза. Релиз-менеджер зафиксировал согласование переноса с бизнес-заказчиком.
Релиз-менеджер внес в паспорт рисков выявленные риски и меры, которые подготовили ответственные за них.
Интеграционные задачи и смежные системы
Критерии начала
Сборка установлена на стенд выбранных регрессионных или smoke-проверок каждой системы в согласованном порядке.
Критерии окончания
Тестировщики выполнили выбранные по оценке влияния регрессионные или smoke-проверки, включая смежные системы, и сохранили результаты. Если выбрано НТ, инженер по нагрузочному тестированию выполнил его и представил результаты.
Нагрузочное тестирование
НТ, при необходимости
Критерии начала
Введен code freeze: внесение изменений в код не допускается.
Инженер по нагрузочному тестированию актуализировал профиль нагрузки.
Сборка для НТ подготовлена и успешно установлена на контур.
Среда подготовлена к нагрузочному тестированию.
Участники уведомлены о старте НТ.
Критерии окончания
Инженер по нагрузочному тестированию выполнил проверки и сохранил результаты.
Инженер по нагрузочному тестированию подтвердил отсутствие блокирующих и критичных ошибок; менеджер по качеству проверил результаты.
Инженер по нагрузочному тестированию указал минорные дефекты, предлагаемые к переносу. Менеджер по качеству оценил их влияние на готовность релиза. Релиз-менеджер зафиксировал согласование переноса с бизнес-заказчиком.
Релиз-менеджер внес в паспорт рисков выявленные риски и меры, которые подготовили ответственные за них.
Интеграционные задачи и смежные системы
Критерии начала
Сборка установлена на нагрузочный стенд каждой системы в согласованном порядке.
Критерии окончания
Системный аналитик определил затронутые зависимости, включая смежную систему. Инженер по нагрузочному тестированию подготовил и выполнил соответствующие нагрузочные сценарии. Тестировщик выполнил smoke-проверки, если они входят в выбранный по оценке влияния объем.
Приемочные и инсталляционные проверки
При необходимости и при наличии условий для выполнения проверок
Критерии начала
Сборка установлена на preprod для приемочных и инсталляционных проверок.
Критерии окончания
Выполнены первичные и итоговые инсталляционные проверки.
Системный аналитик определил затронутое поведение; тестировщик выбрал и выполнил целевые проверки (sanity check) по этой информации.
Тестировщик выполнил приемочные проверки и сохранил результаты.
Релиз-менеджер внес в паспорт рисков выявленные риски и меры, которые подготовили ответственные за них.
Интеграционные задачи и смежные системы
Критерии начала
Сборка установлена на preprod каждой системы в согласованном порядке.
Критерии окончания
Системный аналитик определил затронутое поведение смежных систем; тестировщик выбрал и выполнил sanity check для приемки.
Менеджер по качеству каждой участвующей системы подготовил заключение о готовности к установке по результатам проверок тестировщика. Заключение учитывается при согласовании внедрения по установленному маршруту.
Внедрение
Выход на production
Критерии начала
План внедрения сформирован и согласован.
Запрос на выпуск срочного релиза с обоснованием срочности оформлен и согласован.
Запрос на проведение работ согласован.
Все задачи переведены в статус «Оценка» или «Закрыта».
Релиз-менеджер уведомил участников о работах и при необходимости подготовил описание изменений (release notes).
Задача релиза в статусе «Внедрение».
Критерии окончания
Релиз установлен на production; чек-лист в плане внедрения заполнен.
Сопровождение, дополнительный согласующий 3 и бизнес-заказчик выполнили проверки и подтвердили корректную работу системы.
Интеграционные задачи и смежные системы
Критерии начала
Сформирован и согласован план внедрения, учитывающий задачи смежных систем.
Пострелиз
Оценка результата и завершение
Критерии начала
Менеджер по качеству подвел итоги проверок, релиз-менеджер — итоги выпуска.
Менеджер по качеству проанализировал дополнительные материалы, если они есть. Их состав указан в стратегии.
Релиз-менеджер направил участникам опрос о работе релизного процесса.
Задача релиза в статусе «Оценка».
Критерии окончания
Релиз-менеджер оценил качество внедрения.
Дайджест релиза подготовлен при необходимости.
При необходимости проведена ретроспектива и сформированы задачи на улучшение по ее итогам.
Задача релиза в статусе «Закрыта».
История изменений стратегии
После каждой правки стратегии укажите дату, содержание изменения и автора.
- Дата
- ЗаполнитеДата изменения вашей стратегии.
- Изменения
- ЗаполнитеКакие правила или разделы изменены.
- Автор
- ЗаполнитеКто внес изменение.