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

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

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

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

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

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

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

Release notes

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

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

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

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

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

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

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

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

Сделать тэг

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

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

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

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

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

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

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

После релиза

Мониторить

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

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

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

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

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

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

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

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

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

Управление релизами (Release management) по ITIL

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

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

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

Что такое управление релизами

Релизами называют запланированные изменения, которые вносят в программное или аппаратное обеспечение.

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

Зачем автоматизировать процесс управления релизами

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

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

Из каких этапов состоит процесс управления релизами

Ключевые этапы процесса управления релизами

1. Планирование

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

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

2. Сборка релиза

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

3. Тестирование

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

4. Развертывание

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

5. Контроль качества

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

Как ITSM 365 решает проблему управления релизами

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

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

Всë, что вам нужно знать об управлении релизами

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

Что это такое управление релизом?

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

Планирование релиза
Сборка релиза
Приемочное пользовательское тестирование
Подготовка релиза
Развертывание релиза.

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

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

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

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

Отсечение: начинается 1-й день.
Внутреннее тестирование версий альфа/UAT: Три дня.
Поэтапное развертывание [1%] Представление на ревью.
Продолжительность ревью: 3 дня.
Один день при 20% пользователей.
Один день при 50% пользователей, в тот же день рост до 100% пользователей.

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

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

Сроки
Сроки поставки
Требования
Общий масштаб проекта

Как только план утверждается и окончательно оформляется, начинается самое интересное!

Важные аспекты планирования релизов

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

Релиз-менеджер управляет релизом и координирует его.
Мы принимаем только код с проведенным ревью и протестированный код.
В процессе есть этап внедрения.
Мы мониторим выпущенную версию приложения.

Построение релиза

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

В определённый день и время (скажем, в понедельник, в 15:00) происходит замораживание/отсечение кода. До этого момента команды успевают посмотреть, протестировать и смержить фичи в ветку разработки, которая должна быть частью трейн-релиза. В 15:00 релиз-менеджер создаст из ветки разработки ветку релиза. Этот шаг автоматизирован с помощью Jenkins.

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

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

Релиз веток и контроль версий

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

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

Каждая ветвь может развиваться независимо от другой. В этом случае одна копия — ветка релиза — остаётся замороженной на том месте, где вы завершили разработку. Это то, что мы называем отсечённой веткой. Другая ветка (ветка разработки) может быть изменена новым кодом и исправлениями ошибок, не затрагивая ветку релиза вообще. Если ошибка найдена в релиз-кандидате, исправление может быть разработано и добавлено в ветку релиза. Таким образом, следующая сборка, которую вы снова соберёте из ветки выпуска, может быть идентична первой, за исключением исправления одной ошибки. Таким образом, вы можете минимизировать риск появления новых ошибок в выпуске и изолировать баги от нового кода. Исправление также применяется к ветке разработки, чтобы гарантировать, что та же самая ошибка не попадёт в следующий релиз. Другое преимущество релиз-ветвления состоит в том, что как только вы действительно публикуете код, у вас есть «замороженная» ветка, которая представляет собой точную копию опубликованной кодовой базы. Вы можете вернуться к этому коду в любое время для справки.

Пользовательское приемочное тестирование

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

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

Могут ли пользователи работать с приложением?
Соответствует ли поведение приложения ожиданиям?
Решает ли приложение проблему пользователей?

Pro Tip: всегда включайте внутреннее тестирование в планирование UAT!

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

Подготовка и релиз

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

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

Развертывание релиза

Наконец-то настал важный день, когда окупилась вся тяжелая работа нашей команды. Пришло время выпустить наш продукт в дикую природу продакшна. Помимо простой отправки сборки в производственную среду, стадия внедрения также содержит обучение работе с продуктом как конечного пользователя, так и компании в целом. Например, пользователи должны быть уведомлены об изменениях в релизе, и именно здесь на появляется в поле зрения «What’s New» (Что нового). У нас есть автоматизированный процесс на Jenkins, содержащий такие шаги:

Создание окончательной сборки [с указанием ветки и названия версии].
Добавление «What’s New» в релизе.
Добавление процента развертывания.
У каждого этапа есть ручной ввод сигналов (красный/зеленый) от каждой из команд [UAT, бенчмарк, производительность, автоматизация].

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

Если ошибка становится заметной в 1%, у команды есть шанс отреагировать на проблему и решить, нужно ли исправлять ее быстро. Если это так, то трейн-релиз не должен достигнуть следующего шага развертывания в 5%. Вместо этого проблема решается для 1% пользователей. Как только проблема устраняется и решение проверено, трейн-релиз может перейти на стадию 5%.

Как и в простой версии трейн-релиза, только релиз-инженер или команда релиза заботится о процессе релиза после замораживания кода. Все остальные команды продолжают «нормальную» разработку.

Анализ после релиза

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

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

Подведем итоги

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

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

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

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

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

Мой доклад будет построен следующим образом.

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

О компании

Иркутская нефтяная компания – одна из крупнейших независимых нефтегазодобывающих компаний в России.

Она насчитывает более 8000 сотрудников, и по прогнозам через пять лет нас будет уже не менее 15 тысяч.
Деятельность компании представлена в Восточной Сибири. Это – Иркутская область, республика Саха, Якутия, а также Красноярский край.
Количество информационных баз, используемых в режиме промышленной эксплуатации, исчисляется десятками. В них работает более 1000 пользователей, и это число постоянно растет. Также есть крупные базы на платформе 1С, которые включают в себя несколько функциональных блоков.

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

В департаменте информационных систем есть три отдела:

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

Система Service Desk

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

Теперь механизм управления релизами реализован в нашей системе «Service Desk». Но обо всём по порядку!

В далёком 2014-м году проблем с релизами у нас не было, компания была намного меньше и баз было не более 5.

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

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

В пустой конфигурации на платформе 1С мы быстренько накидали требуемый функционал, который состоял из одного документа «Обращение» и назвали систему «Service Desk».

Система быстро стала популярной в компании, и с тех пор её функционал нами расширялся и совершенствовался.

На данный момент в этой системе реализован механизм управления релизов.

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

Сначала в систему «Service Desk» поступает обращение от пользователя по вопросам работы в той или иной системе.
Если вопрос на 1-ой линии не решился и выявлена необходимость внесения изменений в алгоритмы работы системы, то вопрос передаётся на вторую линию для формирования постановки задачи на разработку и, собственно, самой разработки. На этом этапе создаётся документ «Доработка».
В конечном итоге доработки объединяются в релиз, который устанавливается на рабочую базу.

Формирование релиза

Расскажу о процессе формирования релиза более подробно.

Документ «Обращение» – очень простой, в нем нет ничего сложного:

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

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

У каждой информационной системы есть два хранилища. Мы их называем «Тестовое» и «Релизное».

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

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

Перейдем к документу «Доработка». Этот документ намного более функционален, чем документ «Обращение», и создается на его основании.

Изначально документ «Доработка» создается в статусе «Зарегистрировано», и с ним начинают работать консультанты по внедрению информационной системы. В результате на вкладке «Описание» формируется описание задачи непосредственно на техническом языке для разработчика.
После того как консультант поставил задачу разработчику, он отправляет документ «Доработка» в статус «В разработке», и тогда уже исполнителем по доработке становится непосредственно программист. Разработчик вносит изменения в свою тестовую базу и помещает их в тестовое хранилище. Как я говорила ранее, структура тестового хранилища выгружается в систему Service Desk.
В процессе своей работы программист на вкладке «Измененные объекты» галочками отмечает те объекты конфигурации, которые он изменил в процессе доработки. Это некий организационный момент – разработчик должен вручную поставить эти галочки. Кроме галочек он может указать комментарий – например, в какую процедуру или функцию вносились изменения, а также любую другую информацию.
А также есть правило – когда разработчик вносит в конфигурацию изменения кода, он обязательно комментирует, и комментарий содержит номер доработки, в рамках которого происходит изменение, и также автора, который внес эти изменения.
И при помещении в тестовое хранилище измененных объектов также в комментарии обязательно указывается номер доработки. Вся эта информация значительно облегчает сбор релизов в дальнейшем. Сейчас я скажу, как.
После того, как разработчик внес изменения в конфигурацию, он передает доработку в тестирование консультанту.
Вообще с документом «Доработка» по очереди работают консультант и программист, гоняя его по разным статусам – «В уточнении», «В тестировании», снова «В разработке». Чаще всего документ принимает статус «В разработке» несколько раз, и каждый раз при изменении объектов разработчик дозаполняет вкладку «Измененные объекты» новыми объектами, которые он меняет. Таким образом, доработка хранит в себе всю информацию об измененных объектах конфигурации в ходе ее выполнения.

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

Вкладка «Информация о релизе» содержит три раздела:

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

После того, как консультант заполнит всю необходимую информацию о доработке, он переводит доработку в статус «К помещению в рабочую базу».

Как только доработка попала в этот статус, исполнителем по ней снова становится разработчик. Но он не работает дальше с документом «Доработка» до тех пор, пока эта доработка не попадет в документ «Релиз».

Таким образом, мы с вами подошли к главному документу моего сегодняшнего доклада – документу «Релиз».

В зависимости от типа релиза он появляется разными способами:

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

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

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

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

На вкладке «Измененные объекты» есть вся информация об измененных объектах всех доработок, которые вошли в документ «Релиз». Эта вкладка имеет два представления.

Первое представление, которое вы видите на экране (со снятой галочкой «По доработкам») – это представление, которое показывает изменения в разрезе структуры конфигурации:

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

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

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

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

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

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

Эффекты от внедрения

Что мы получили благодаря реализованному механизму?

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

Раньше у нас каждый раз после выпуска планового релиза, особенно на крупных базах, просто валом несколько дней подряд шли срочные релизы, потому что обязательно где-то кто-то что-то зацепил, либо наоборот, не обновил какой-то нужный объект. И в итоге на рабочие базы попадала либо непротестированная функциональность, либо туда не попадало что-то нужное. Был большой негатив со стороны пользователей, и выпуск исправительных релизов – даже в обеденное время – только усиливал этот негатив. А благодаря этому механизму мы практически свели к нулю установку исправительных релизов.
Также мы получили удобный инструмент сборки релизов, который подскажет разработчику – какие объекты ему нужно обновлять полностью, а какие с осторожностью, так как они также были изменены его коллегами.
Несмотря на то, что разработчикам и консультантам приходится вносить много данных в документ «Доработка», количество трудозатрат на подготовку релизов у нас снизилось. Это произошло за счет того, что значительно снизилось именно количество этих исправительных срочных релизов, что дало огромный выигрыш по трудозатратам сотрудников на подготовку обновлений в целом – сама длительность сборки релиза не сильно изменилась.
Руководители отдела разработки и внедрения получили инструмент для контроля дисциплины своих сотрудников.
В частности, начальник отдела внедрения может контролировать, как консультанты обновляют инструкции, как они качественно оповещают об изменениях пользователей – всех ли пользователей они оповещают об этом.
Руководитель отдела разработки имеет механизм, который дает ему возможность в случае возникновения каких-то ошибок разобраться, почему это произошло, кто допустил ошибку. Он может контролировать исполнительскую дисциплину в плане заполнения данных в документе «Доработка».
Теперь у нас нет проблем с актуальностью инструкций. Инструкции актуальны всегда, они обновляются вместе с релизом – поэтому проблем о том, кто и когда обновит инструкцию – чуть раньше или позже – у нас никогда не возникает.
Также мы ушли от ручной установки релиза. Раньше у нас разработчики не спали, ночью обновляли вручную базы, утром консультанты первым делом должны были как можно быстрее отправить уведомления пользователям об установке релиза и обновить все инструкции. Если вдруг кто-то отвлекся, забыл, проспал – недовольство в наш адрес было обеспечено. Сейчас мы готовимся к обновлениям заблаговременно, в рабочее время. Ночью все спокойно спят. Этот процесс упорядочен.

Перспективы развития

В описанной мною функциональности меня устраивает практически все, за исключением одного – разработчикам приходится ручками вручную отмечать измененные объекты, которые он помещает в хранилище конфигурации в документах «Доработка» системы Service Desk. Это своего рода «двойной ввод». Но пока мы не решили, что с этим можно сделать. Мы бы хотели, чтобы:

при помещении разработчиком изменений в хранилище – информация об определенных объектах, которые он туда помещает, приходила бы в систему Service Desk;
так как разработчик при помещении в хранилище указывает в комментарии номер доработки, хотелось бы, чтобы в этой доработке все эти объекты автоматически отмечались на вкладке «Измененные объекты»;
при этом если есть добавленные объекты, сначала обновлялась информация о конфигурации тестового хранилища в Service Desk, а потом также отмечались все измененные или добавленные объекты.

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

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

Если вдруг у кого-то будут какие-то идеи на этот счет – поделитесь, пожалуйста, я буду очень признательна!

У меня все. Спасибо за внимание!

Вопросы

При обновлении релиза иногда требуется не только внесение изменений в конфигурацию, но и обновление данных – добавили реквизит, поменяли тип, нужно перенести данных. Это должно произойти в момент выкатки новой конфигурации. Включены ли в вашу процедуру каким-либо образом еще и изменения данных помимо изменений инструкций и кода?
В самом механизме этого нет. У нас есть механизм, который позволяет не устанавливать обращение в статус «Выполнено» и информировать консультанта с помощью определенных настроек о том, что конфигурация обновилась, и в нее нужно внести какие-то данные. Т.е. эти настройки консультант сам для себя заранее формирует, чтобы система ему потом об этом напомнила.
Получается, что консультант это сделает уже с утра, когда пользователи могут начать работать с неверными данными?
Такое бывает нечасто, и консультанты про это сами знают. Если что-то нужно сделать действительно быстро – бывает, что консультант может это делать ночью или рано утром, когда еще пользователей нет.
Какое количество у вас разработчиков и как часто вы выпускаете релизы?
У нас шесть разработчиков, пять из них – разработчики 1С. По поводу количества релизов – мы стараемся сократить количество релизов, мы их пытаемся упорядочить. И раз в две недели выпускаем плановый релиз. Это получается достаточно крупный, тяжелый релиз. Но у нас бывают проектные релизы, которые мы устанавливаем тоже по регламентам – по понедельникам, например. И, к сожалению, бывают срочные релизы – когда нужно исправить какую-то ошибку в системе, либо пользователю эта функциональность нужна срочно.
Экстренные релизы вы тоже заносите в систему и отражаете (если сломалось, и нужно обновить прямо сейчас)?
Да, срочные релизы мы также проводим через эту систему. Обычно мы стараемся, конечно, дотянуть время, например, до обеда – пока меньше пользователей будет работать. И также планируем установку релиза – готовим его заранее за пару часов, и он устанавливается в обед автоматически.
Каким образом вы тестируете релиз? Как вы проверяете работоспособность при сборке?
Тестирование релизов происходит консультантами, они свою базу обновляют из тестового хранилища. И, соответственно, тестируют в ней функциональность вручную. Автоматического тестирования у нас пока нет.
А каким образом осуществляется приемка функциональности? Есть задача, ее выполняют разработчики, дальше эта функциональность принимается. В какой момент это происходит?
Консультант принимает функциональность от разработчика. Если у него нет никаких замечаний, его полностью устраивает реализация, он переводит доработку в статус «К помещению в рабочую базу». Тем самым он подтверждает готовность функциональности для промышленной базы.
Это происходит уже в релизном хранилище?
Консультант делает это в системе Service Desk, и только после этого доработка попадает в документ «Релиз», и только потом ее переносят уже сами разработчики – тот, кто ее разрабатывал – в релизное хранилище.
Как происходит работа с документацией (с инструкциями)? Как они доставляются до конечных пользователей? И ведется ли версионирование?
Да, версионирование инструкций ведется. Сами инструкции также находятся в системе Service Desk – все находится в одном месте. И когда консультант во вкладке «Подготовка к релизу» указывает текущий раздел инструкции и прикрепляет к нему вордовский файл, содержанием которого должна замениться инструкция при обновлении. И таким образом инструкция в момент установки релиза становится свежей.
А как она к пользователю попадает?
Пользователь заходит в систему, и там есть все инструкции. Мы инструкции не рассылаем пользователям. Пользователям мы просто рассылаем краткое уведомление о том, что изменилось в системе и что работает теперь по-другому. А детальные инструкции находятся в Service Desk – все пользователи знают, где они находятся, и ими пользуются.
Вы думали как-то поделиться с сообществом эти практиками? Или это останется вашим внутренним достижением?
Мы думали об этом – нужно ли это кому-то, кроме нас, у всех своя специфика. Возможно.
Насколько часто вы выпускаете релизы?
Конечно, одна неделя на другую не похожа, но в среднем 5-6 релизов в неделю вполне может быть.
Тогда рассматривали ли вы вопрос внедрения практик DevOps?
Я знаю, что сейчас есть различные механизмы, системы, которыми можно пользоваться, но сейчас мы пользуемся этим механизмом – он разработан под нас, нам с ним удобно, и пока что мы от него отказываться не хотим. Возможно, в дальнейшем – жизнь не стоит на месте, и мы перейдем на что-то более современное.
Просто по поводу того, что вы сказали – ручной ввод информации по измененным объектам конфигурации – дело в том, что когда разработчик помещает в хранилище свои изменения – по этим изменениям можно сформировать отчет. А отчет в текстовом формате можно сохранить и распарсить и те же изменения получить в вашу систему.
Да, отчет мы тоже формируем. Но у нас именно в чем удобство – в том, что мы можем посмотреть, для чего это изменение было сделано – у нас оно привязано непосредственно к доработке и к обращению пользователя. Мы можем отследить, кто это запросил.
Но вы говорите, что когда разработчик помещает свои изменения в хранилище, он помечает их номером задачи. Соответственно, когда вы формируете отчет по измененным объектам конфигурации в хранилище, там же можно их сформировать по номеру задачи. Таким образом автоматизировать ввод изменений в вашу систему.
Просто в конфигураторе нет возможности запустить событие при помещении в хранилище.
Но вы же можете эти изменения регламентными заданиями выгружать – если вы будете рассматривать для себя практику DevOps, там это можно организовать.
Спасибо большое за совет.
Если я правильно понял, у вас у каждого разработчика есть своя тестовая база, в которой он ведет разработку, а потом изменения закидывает в тестовое хранилище. А у вас бывают ситуации, когда двое разработчиков работают над одним и тем же объектом и первый разработчик закидывает свои изменения сегодня, а второй – завтра, и когда второй разработчик закидывает изменения, он стирает изменения первого?
Если первый вносил изменения, он захватил объект, и его изменять никто не может в тестовом хранилище. После того, как он его доработал, он его помещает в тестовое хранилище, и там уже есть все изменения. И второй разработчик при захвате уже получает объект с изменениями. Конечно, теоретически может быть, что он нечаянно сотрет изменения другого разработчика. Но у нас в хранилище вся информация сохраняется, и потом, в случае возникновения каких-то проблем, мы можем это отследить, найти, скорректировать действия разработчика.
У нас проблема, что когда второй разработчик захватывает объект и получает изменения, он закидывает свою версию и модуль объекта меняется.
Именно поэтому мы требуем от разработчиков, чтобы их тестовые базы были подключены к этому хранилищу и чтобы они обновляли их оттуда, не отключали от хранилища, не вносили туда изменения и потом хранилище не обновляли своими конфигурациями.
Ваши релизы устанавливаются многим клиентам? Или все доработки делаются под одного клиента?
Нет, релиз привязан к информационной базе. Есть базы, где очень много функциональных блоков – часть из них между собой связана. И когда мы формируем релиз, туда входят все доработки, которые относятся к этой информационной базе. Там много заказчиков и разработчиков работают над этим релизом. Т.е. релиз не для одного заказчика – релиз для базы.
У вас в задаче была закладка «Описание для релиза». Это творческое описание, которое может отличаться от описания задачи, потому что мы туда добавляем какие-то слова для пользователя. Кто занимается этими красивыми описаниями?
Описания вносит консультант, который понимает, что именно дорабатывается, он сам ставит задачу разработчику. И задача консультанта – как можно более понятно пользователю сформировать это описание.

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.

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