Как организовать релиз по

Как организовать релиз

Релизить продукт — это самая важная часть работы любой софтверной компании. Но если вы боитесь делать релиз, то возможно вы что-то делаете не так. Я расскажу как обычно организовываю релиз. Данная статья не претендует на исчерпывающее руководство поскольку в индустрии разработки программного обеспечения все индивидуально.

Как готовиться к релизу?

Выбрать ответственного человека

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

Настроить календарь

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

Сделать таблицу в вики

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

Release notes

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

Внутренний анонс

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

Во время релиза

Создать релизный бранч

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

Отправить уведомление

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

Сделать тэг

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

Сделать сам релиз

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

Релиз одной кнопкой

Мифический. Безусловно, чем меньше человеческого фактора участвует в релизе, тем лучше. Но это нормально, если не все получается автоматизировать.

Если все пошло не так, как планировалось

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

После релиза

Мониторить

Не забывайте мониторить ошибки, нагрузку на сервера. Также стоит обратить внимание на KPI: если вы сделали релиз и у вас упало DAU, то, возможно, что-то работает не так хорошо, как должно было, либо сломаны сами средства мониторинга. Любую подозрительную активность стоит проверить.

Сообщить об успехах и неудачах

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

Провести ретроспективу

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

Заказать пиццу и отпраздновать

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

Начать подготовку к следующему релизу

Мне очень нравится идея Release train, когда каждый релиз проходит регулярно в четко обозначенные даты. Благодаря этому механизм релиза отлаживается командой. Как я писал выше, не обязательно делать релиз на 100% пользователей: можно выкатить на небольшую группу людей.

Как проводят релиз другие компании?

Spotify

Спотифай релизит часто, основываясь на практике Release train. Как намекает название этой практики, релиз очень похож на поезд: кто не успел закончить свою работу, ждет следующего релиза. Плюсы такого подхода в том, что не успевающая команда не задерживает доставку продукта и не пытается втолкнуть недоделанные таски. И как следствие, у девопсов ночами не разрываются телефоны, а дежурная команда на утро не появляется на работе с мешками под глазами. Безусловно такой подход не подойдет аутсорсинговой компании: клиент не станет платить за недоделанную работу. Скажу прямо: мне нравится культура компании, советую посмотреть видео (https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) о том, как она работает.

Booking

Эти ребята тоже очень крутые. Релизы у них основаны на A/B тестах. Допустим, есть текущая стабильная версия — версия А, и есть версия, которую только что закончил разработчик, — версия B. Если в версии B KPI лучше, то стоит увеличить процент пользователей для этой версии. Если же версия B хуже, то тут есть два варианта: версия B просто не стабильна или просто фича никому не нужна. Такой подход подойдет компании, которая бережно относится к своему работающему продукту, но революции она скорее всего не сделает. Если вам интересно узнать больше про бережливое производство, прочтите книгу Lean Startup (http://theleanstartup.com/).

• релиз
• релиз-менеджмент

Управлять релизом просто: правила и этапы release management

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

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

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

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

Хорошо подготовленный релиз — это не только предоставление доступа к новым техническим возможностям продукта. Это конечная дата, когда ваша команда может предоставить новый пользовательский опыт, поддержать и развить взаимодействие с ним.

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

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

Продуктовым командам стоит тщательно планировать релизы, поскольку они являются новым предложением, которое ожидают клиенты.

Что включает процесс управления релизом?

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

Процесс управления релизом может включать следующие этапы:

• Планирование. Весь путь продукта начинается с его планирования и стратегии, а планирование релиза позволяет рассчитывать и определять количество спринтов или итераций. На этом этапе происходит начальная приоритезация, предварительная оценка затрат и анализ взаимозависимостей. К планированию привлекаются аналитики и заказчик. Планирование включает ожидания серьезных изменений в продукте, которые могут быть отражены в дорожной карте (product roadmap).
• Согласование. На этом этапе получается подтверждение ресурсов от исполнителей и заказчиков, происходит оценка бюджета релиза. Содержание релиза финально согласуется со всеми заинтересованными сторонами.
• Документирование. Этот процесс закрепления и систематизации всех процедур, где отражены, например, последние данные о новых фичах.
• Коммуникация и поддержка. Для каждого менеджера продукта очень важно не только успешно выпустить продукт или обновление, но и обеспечить налаженное взаимодействие с командой поддержки.
• Статусы готовности. Статус релиза отражается в актуальном состоянии вашего плана. Актуализация статуса помогает снизить риски и обеспечить связь с заинтересованными сторонами.
• Тестирование/Корректировки. В процессе управления релизом не обойтись без регулярных проверок и корректировок, которые помогают достигать порядка и достижения финальной цели.
• Развертывание. На этом этапе изменения передаются в эксплуатацию. Выходит новая версия продукта или сам конечный продукт.

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

Product manager и Project Manager

Менеджеры продуктов и менеджеры проектов несут основную ответственность за релиз. Функционал product manager project и manager отличается, но миссия у них одна — выпустить продукт и представить его клиентам в идеальном виде.

Разбработчики

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

Маркетинг

Маркетологи всегда должны “держать руку на пульсе” и быть в курсе того, чем живут конкуренты. В управлении релизом им важно тесно отрудничать с sales-менеджерами для получения новых и удержания существующих клиентов.

Тестировщики

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

Служба поддержки

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

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

Почему нужно внедрять процесса управления релизам?

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

Что такое Release Notes в процессе управления релизом?

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

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

Когда используются примечания к релизу?

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

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

Вот как выглядит страница с примечаниями к релизу у Firefox:

Как писать примечания к релизу?

Содержание документа зависит от типа релиза. Вот пример основных пунктов:

• Заголовок с названием продукта, датой релиза и его номером, версией примечания.
• Краткая информация — обзор продукта и изменений.
• Ссылки на инструкции по установке, руководство для пользователя, архив, если необходимо.
• Цели — краткий обзор целей примечаний к релизу с перечислением нового в этой версии (исправления ошибок и новые функции).
• Резюме — краткое описание ошибок и проблем.
• Шаги по устранению ошибок.
• Решение — оптимизация, которая была сделана для исправления ошибок.
• Влияние пользователей и поддержки, если необходимо.
• Примечания — все примечания относительно установки продукта, его обновлений и документации.
• Юридическая информация — лицензии, гарантии, отказ от ответственности и т.д.
• Контакты — контактная информация службы поддержки продукта.

Заключение

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

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

Если вы хотите детальнее разобраться в теме release management и отыскать интересные инсайты разных компаний, следующие книги будут полезными: (на английском языке)

• релиз
• релиз-менеджмент
• управление проектом
• управление продуктами
• управление задачами

• Блог компании Hygger
• Высокая производительность
• Управление разработкой
• Управление проектами
• Управление продуктом

Три ингредиента идеальных релизов ПО

Соедините одну часть архитектуры с двумя частями командной работы. Добавьте автоматизацию и перемешайте.

Автор: Dan Radigan

Просмотр тем

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

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

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

Идеальный релиз программного обеспечения начинается с модульной архитектуры

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

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

Идеальные релизы программного обеспечения строятся на взаимопонимании

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

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

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

Следующие рекомендации будут полезными для операционных команд, сотрудничающих с разработчиками.

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

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

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

Автоматизация, автоматизация и еще раз автоматизация!

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

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

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

Идеальные релизы программного обеспечения — отличная штука!

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

Как это делается

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

Поскольку мы являемся разработчиками ПО, на первом плане нашего цикла инновации должен находиться релиз ПО. С кодом, который мы написали, будут взаимодействовать клиенты, и они будут делиться своими впечатлениями. Круто! Если выпуск версий станет вашим привычным занятием в рабочие дни, вам будет проще выводить код в рабочую среду и с гордостью произносить: «Это мой код!»

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

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

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

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

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

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

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

Подсистема управления релизами

Подсистема реализует процесс управления релизами. Для работы с подсистемой необходимо перейти в соответствующий раздел «Управление релизами». В управляемом интерфейсе с помощью команд панели навигации можно осуществить отбор по закрытым и открытым релизам.

Подсистема включает в себя:

• справочники «Типы релиза», «Состояния релизов», «Уровни релиза», «Коды закрытия релизов»;
• документ «Релиз»;
• отчет «Реестр релизов».

Справочник «Типы релиза»

Справочник предназначен для хранения типов релизов, которые детализируют сведения о составе релиза. Справочник доступен по ссылке «Типы релиза» панели навигации раздела «Управление релизами».

В системе предлагается следующее разделение по типам релиза:

• «Дельта-релиз» — включаются только измененные аппаратные и программные средства;
• «Полный релиз» — распространение полного комплекта ПО, включая неизмененные модули;
• «Пакетный релиз» — комплект более мелких релизов, обеспечивает пользователям длительные периоды стабильной работы.

Справочник используется при заполнении документа «Релиз».

Справочник «Типы релиза»

Справочник «Состояния релизов»

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

Справочник «Состояния релизов»

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

• «Код» — системный код состояния;
• «Наименование» — наименование состояния, которое будет отображаться во всех списках;
• «Комментарий» — пользовательский комментарий к состоянию;
• «Признак закрытия релиза» — если флаг для состояния установлен, то с переходом релиза в данное состояние происходит расчет времени закрытия документа «Релиз»;
• «Отправлять уведомление пользователю» — если флаг установлен, то при переходе в данное состояние пользователю будет отправляться уведомление по предопределенному шаблону;
• «Сделать поле «Код закрытия» обязательным для заполнения» — если флаг установлен, в данном состоянии поле «Код закрытия» в документе «Релиз» будет обязательным для заполнения;
• «Код закрытия по умолчанию» — код закрытия для данного состояния, который будет установлен по умолчанию (выбирается из справочника «Коды закрытия релизов»).

На вкладке «Правила перехода» формируется матрица перехода релиза по состояниям. Подробнее о формировании матрицы переходов см. раздел «Настройка матрицы переходов состояний документов».

Справочник «Состояния релизов» используется при заполнении документа «Релиз».

Форма элемента справочника «Состояния релизов»

Справочник «Уровни релиза»

Справочник предназначен для хранения уровней релизов, которые детализируют сведения о размере релиза и/или его функциональности. Справочник доступен по ссылке «Уровни релиза» панели навигации раздела «Управление релизами».

В системе предлагается следующее разделение по уровням релиза.

• «Значительные релизы» — крупномасштабное развертывание новых аппаратных и программных средств, обычно со значительно расширенными функциональными возможностями. Такие релизы часто помогают в устранении ряда известных ошибок, включая известные обходные решения и быстрые исправления.
• «Малые программные релизы и модернизация аппаратного обеспечения (апгрейды)» — эти релизы обычно представляют собой незначительные усовершенствования и исправления известных ошибок. Среди них могут быть изменения, которые внедрялись ранее в виде срочных исправлений и теперь окончательно проработанных и включенных в данный релиз. За счет такого релиза обеспечивается обновление прежнего состояния, являющегося отправной точкой для всех испытаний.
• «Срочные исправления» — обычно внедряются как быстрые исправления проблем и известных ошибок.

Справочник используется при заполнении документа «Релиз».

Справочник «Уровни релиза»

Справочник «Коды закрытия релизов»

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

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

• «Код» — системный код кода закрытия;
• «Наименование» — наименование кода закрытия, которое будет отображаться во всех списках;
• «Описание» — детализированное описание кода закрытия.

Справочник используется при заполнении документа «Релиз».

Справочник «Коды закрытия релизов»

Документ «Релиз»

Документ «Релиз» предназначен для контроля над процессом запуска и внедрения новых версий (релизов) конфигурационных единиц. Документ доступен по ссылке «Все» панели навигации раздела «Управление релизами».

На форме документа размещены следующие реквизиты.

• «Номер» — номер релиза.
• «Дата» — дата создания релиза.
• «Клиент» — клиент, которому принадлежит конфигурационная единица, для которого производится релиз.
• «Оповещать» — пользователи, которым будут отправляться уведомления при изменении состояния релиза.
• «Описание» — описание изменений, которые включены в релиз.
• «Приоритет» — приоритет релиза.
• «Состояние» — состояние релиза, которое выбирается из справочника «Состояния релизов».
• «Код закрытия» — код, сообщающий признак закрытия релиза. Выбирается из справочника «Коды закрытия релизов».
• «Ответственный» и «Рабочая группа» — сотрудник, ответственный за данный релиз, и рабочая группа, в которую он входит. Ответственным лицом можно назначить не только сотрудника из справочника «Сотрудники», но также группу сотрудников из справочника «Рабочие группы» (выбор осуществляется нажатием значка «лупа»). Если в поле «Рабочая группа» выбрать не конкретного сотрудника, а всю группу, то в поле «Ответственный» будет автоматически проставлена эта группа, поля обязательны для заполнения.
• «Категория» — наименование категории релиза, выбирается из справочника «Категории документов».
• «Уровень релиза» — классификационный признак, детализирующий сведения о размере и/или функциональности релиза, выбирается из справочника «Уровни релизов».
• «Тип релиза» — классификационный признак, описывающий состав включенных в релиз изменений, выбирается из справочника «Типы релиза».
• «План возврата» — любой документ, например, MSWord, в котором будет содержаться информация для отката релиза.
• «Параметры релиза» — содержится информация о количестве обращений по этому релизу, количестве прикрепленных релизов, плановых и фактических трудозатратах по нарядам, а также перерасходе трудозатрат по нарядам.

Документ «Релиз»

«Общение по документу»

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

Для того чтобы участнику общения отправилось уведомление, необходимо указать соответствующий шаблон в поле «Уведомлять о новых сообщениях в общении по обращению» в обработке «Параметры системы» (ссылка «Администрирование»/«Параметры системы»/«Уведомления» панели навигации раздела «Администрирование и настройки»).

В левой части формы отображается документ, по которому ведется общение, а в правой части формы само общение. Добавление сообщения в общение по документу недоступно, если документ в состоянии с признаком закрытия.

Вкладка «Внутреннее общение»

Общение, которое ведется на вкладке «Внутреннее общение» не доступно инициатору документа. В списке сообщений внутреннего общения, сообщения, написанные инициатором, выделяются особым цветом.

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

Уведомления по данному общению по умолчанию получают: ответственный сотрудник и подписанные на внутреннее общение лица.

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

Вкладка «Общение с инициатором»

Общение на данной вкладке видят все пользователи, которым доступна видимость общения по данному документу. Уведомления по данному общению по умолчанию получают: инициатор, ответственные лица и лица, подписанные на внутреннее общение. Инициатор обращения видит только вкладку «Общение с инициатором», вкладку «Внутреннее общение» инициатор не видит.

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

Блок по умолчанию раскрыт, но его можно скрыть, нажав на «Написать». Содержит вкладки «Общение» и «Файлы» и кнопки:

• «Цитировать» — кнопка позволяет добавить текст из общения, выделенный ранее, в поле для написания сообщения. Текст будет выделен специальными символами, которые указывают на то, что текст был процитирован.
• «Добавить» — кнопка позволяет добавить текст, который содержится в поле «Текст сообщения» в общение по документу.
• «Очистить» — кнопка позволяет одним кликом удалить все, что ранее было добавлено в поле «Текст сообщения».

Содержит поле «Текст сообщения», для написания сообщения, а также кнопки форматированного описания.

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

Шаблон, по которому осуществляется отправка о новом сообщении в общении по документу, можно найти в разделе «Параметры системы» — «Уведомления».

Вкладка «Общее» содержит следующие реквизиты.

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

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

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

На данной вкладке находятся следующие реквизиты:

• табличная часть «Изменения» — изменения, входящие в состав релиза;
• табличная часть «Обращения» — обращения, входящие в состав релиза.

Вкладка «Работы» документа «Релиз»