Что такое релиз в программировании
Перейти к содержимому

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

  • автор:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

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

Релиз

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

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

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

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

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

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

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

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

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

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

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

  1. Отсечение: начинается 1-й день.
  2. Внутреннее тестирование версий альфа/UAT: Три дня.
  3. Поэтапное развертывание [1%] Представление на ревью.
  4. Продолжительность ревью: 3 дня.
  5. Один день при 20% пользователей.
  6. Один день при 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 предоставляют разработчикам приложений возможность отвечать на отзывы, что может быть невероятно полезным инструментом для получения дополнительной информации о проблемах с приложением от пользователей. Отзывы могут выявить проблемы, с которыми сталкиваются пользователи при работе с вашим приложением, и проинформировать о будущих изменениях.

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

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

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

image

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

  • Курс по DevOps
  • Обучение профессии Data Science
  • Обучение профессии Data Analyst
  • Курс «Python для веб-разработки»

Eще курсы

  • Профессия Веб-разработчик
  • Frontend-разработчик
  • Профессия Этичный хакер
  • C++ разработчик
  • Продвинутый курс «Machine Learning Pro + Deep Learning»
  • Курс по Machine Learning
  • Курс «Математика и Machine Learning для Data Science»
  • Разработчик игр на Unity
  • Курс по JavaScript
  • Профессия Java-разработчик
  • Курс по аналитике данных
  • Профессия iOS-разработчик с нуля
  • Профессия Android-разработчик с нуля

IT для неайтишников: Управление релизами, когда и зачем нужно?

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

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи МегаБокс/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).

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

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

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

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

Делаем непонятное понятным

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

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

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

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

Стенд разработки

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

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

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

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

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

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

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

Маркетолог спрашивает программиста: в чём сложность поддержки большого проекта?

Программист: ну, представь, что ты писатель и поддерживаешь проект «Война и мир». У тебя ТЗ — написать главу как Наташа Ростова гуляла под дождём по парку. Ты пишешь «шёл дождь», сохраняешь, вылетает сообщение об ошибке «Наташа Ростова умерла, продолжение невозможно». Почему умерла? Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение «Поручик Ржевский умер.» Выясняется, что он в следующей главе облокачивается о столб, которого уже нет.

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

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

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

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

Вторая проблема решается через управление релизами, третья через системы контроля версий. Сначала решим третью проблему, потом вернёмся ко второй.

Система контроля версий

Что такое система контроля версий? Представьте, что вам с кем-то нужно совместно работать над документом. Вы берете текущее состояние документа и делаете от него «ветку», в которую вносите изменения. То есть получаете свою версию документа. А потом у вас есть возможность слить несколько веток изменений в одну, то есть получить итоговый документ.

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

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

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

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

Теперь возвращаемся ко второй проблеме.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внедрение релиза

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

Еще нужно описывать состав релиза. Хотя бы какие изменения в него вошли и какие недоработки в рамках него исправляются. Такой документ называют Release Notes (записка к релизу). По таким документам можно восстановить историю релизов.

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

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

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

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

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

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

Эксплуатация релиза

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

Например, номер релиза 2.5.14 говорит, что нам понадобилось 14 сверхсрочных внедрений, скорее всего часть из них была связанна с аварийными ситуациями. Много это либо мало зависит от частоты средних по масштабам изменений. Если они происходят раз в год, то скорее всего внедрялись небольшие, но важные для бизнеса изменения. Если они происходят раз в месяц либо раз в неделю, то в пору задуматься о качестве релиза. Скорее всего, процесс тестирования сломан и не работает. А еще можно почитать Release Notes для каждого релиза, чтобы понять, в чем было дело.

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

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

Подводя итоги

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

Если в компании много разработчиков, управление становится непростой и напряжённой работой. У всех планы, сроки, лишение премий и прочие. Люди пытаются договориться, надавить, обмануть наконец. Например, внедрить новый функционал под видом исправления ошибок. Бывают курьёзы, когда разработчиков спрашивают, почему для исправления опечатки в одном слове (должна поменяться 1 строка кода), пришлось изменить 2 тысячи строк кода? Иногда ответы на этот вопрос поражают своей изворотливостью.

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

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

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

Если не смотреть за метриками, то будет не понятно нужно было ли вносить какие-то изменения либо нет. А раз так, то вообще зачем что-то разрабатывать и вносить. Возможно, просто делается какая-то бесполезная работа. Кстати, анализ Realese Notes тоже помогает выявить работу ради работы.

Иногда процесс управления релизами неверно считают частью процесса обеспечения качества (QA), хотя он больше относится к процессу управления изменениями. Такое делать нельзя, теряется контроль за метриками и управление информационным продуктом. Метрики и инциденты возникают на продуктиве, а не на стендах тестирования.

Если вы дочитали до конца, и написанное было для вас полезным, то спасибо вам.

Полезные материалы по теме:

  • IT для неайтишников: Зачем оно нужно?
  • IT для неайтишников: Какими бывают IT-шники? Часть 1
  • IT для неайтишников: Какими бывают IT-шники? Часть 2
  • IT для неайтишников: Какими бывают IT-шники? Часть 3
  • IT для неайтишников: Какими бывают IT-шники? Часть 4
  • IT для неайтишников: Какими бывают IT-шники? Часть 5
  • IT для неайтишников: Какими бывают IT-шники? Часть 6
  • IT для неайтишников: Какими бывают IT-шники? Часть 7
  • IT для неайтишников: Какими бывают IT-шники? Часть 8
  • IT для неайтишников: Куда исчезают программисты после 40 лет?
  • IT для неайтишников: Срывают сроки, что делать бизнес-заказчику?
  • IT для неайтишников: Технический долг или почему теперь всё так долго?
  • IT для неайтишников: Осторожно — JSDD (Бизнес в заложниках у IT)
  • IT для неайтишников: Инженеры в заложниках у бизнеса
  • IT для неайтишников: Потеряли ключи от IT, что делать?
  • Как писать код, чтобы тебя не уволили? (про JSDD — Job Safety Driven Development)
  • Процессы в ИТ: Долго, дорого и не то
  • Саморегуляция в ИТ: минимально допустимая эффективность работы
  • Telegram-канал Записки ITBP (короткие сообщения)
  • Канал на Дзен Записки ITBP (статьи среднего размера)

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *