Управление релизами: какие решения для разработчиков есть на российском рынке?
09.02.2024
Релизный цикл включает множество процессов. К ним относится, например, координация работы команд, поставляющих инкременты. В сложных релизах могут участвовать несколько коллективов разработки, что требует качественной оркестрации и хореографии. Например, интеграционный релиз может состоять из определения списка задач в релизе, синхронизации поставок, определения состава тестовых сред, проведения системного тестирования, согласования проектных артефактов и пр. Полный комплект этих процессов должна пройти каждая команда разработки, а менеджер релиза – все эти работы организовать.
Также в релизный цикл должны входить DevOps-работы по передаче поставок, по настройке или донастройке сред. После того как код написан и скомпилирован, сборка начинает путешествовать по так называемым тестовым средам, пока не дойдет до промышленной среды (ее называют пром, или prod). При этом количество промежуточных сред и процесс перемещения релизной сборки в каждой компании свои. Релиз сопровождается соответствующей документацией (release notes), состав которой тоже определяется зрелостью и регламентами компании.
Таким образом, установка релиза на пром — это полноценный проект, который должен быть четко структурирован и спланирован. При этом все этапы процесса могут быть автоматизированы, для того чтобы обеспечить качество и своевременность поставки.
Да, разница в небольших компаниях и в корпоративном сегменте очевидная. В зрелом бизнесе каждый из этапов отдельно планируется, и в них задействуются различные команды. Сначала поставку ведет команда развития, затем ее подхватывает команда внедрения, которая может дополнительно ее конфигурировать и наращивать функциональность; далее подключаются первая и вторая линии сопровождения и так далее.
В небольшой команде, которая только начинает управлять своей разработкой, релизный процесс может ограничиваться автоматизированным перемещением поставки между средами.
Большое значение имеет операционная деятельность компании. Например, в компаниях, работающих с персональными данными или финансовой информацией, данные предпрод- и прод-сред недоступны командам развития ПО. В подобных случаях в релизный процесс дополнительно включают обезличивание данных или генерацию больших массивов синтетических данных.
Подобные инструменты делятся на два класса. Во-первых, управленческие, или менеджерские. К ним относятся, например, наши разработки «Сфера. Релизы» и «Сфера. Контрольные точки». Во-вторых, — инженерные инструменты, автоматизирующие сам процесс сборки: запуск, формирование дистрибутива, перевод из одной среды в другую или тестирование. И они у нас тоже есть: «Сфера. Код», «Сфера. CI/CD», «Сфера. Дистрибутивы и библиотеки».
В небольших компаниях автоматизацию начинают с внедрения инженерных инструментов, не занимаясь при этом глубокой регламентацией процесса. Кажется, все просто: поставка автоматически собралась, переехала из одной среды в другую, но из-за того, что не проверили документацию, не обучили пользователей, не проверили, соответствует ли содержимое сборки тому, что обещала команда развития, может возникнуть много недоразумений и бизнес-рисков. Один из самых банальных и распространенных — функциональность предложенного решения не соответствует документации, так как менеджеры релиза не владеют информацией, что именно разработчики изменили в процессе.
Да. Но классы инструментов разделяются по уровням зрелости: от того, на каком уровне находятся процессы в компании, зависит то, какие ей нужны инструменты.
На начальной стадии компания оцифровывает постановку задач разработке. Проблема среднего и малого бизнеса в том, что он часто зависает на этой стадии и считает, что таск-трекеров для управления задачами и инженерных инструментов автоматизации достаточно.
Но дальнейшая эволюция разработки требует полноценного управления релизами. В таком случае все мероприятия, включая подготовку документации, обучение пользователей, перемещение продуктов между средами, тестирование, анонсы, синхронизацию релизов смежных систем, пострелизную активность, проходят внутри релизного управления. Среди наших продуктов этим задачам отвечает инструмент «Сфера. Релизы».
На этом развитие систем разработки не останавливается. На третьем уровне возникает необходимость в управлении контрольными точками или quality gates. У нас за него отвечает «Сфера. Контрольные точки». Этот продвинутый инструмент рекомендован крупным компаниям, в которых не менее 100 разработчиков, или 8–10 команд работают над разными системами или разными участками одной большой системы, и весь этот сложный процесс нужно контролировать и автоматизировать.
Необходимость в управлении релизами возникает в тот момент, когда срок вывода продукта на рынок (Time-to-Market или T2M) становится конкурентным преимуществом. Тогда становится важным выдерживать ритм поставок и доставки ценностей, управлять пред- и пострелизными активностями (не только технической и инженерной, но и организационной составляющей релиза).
В сегменте инструментов по управлению релизным циклом прямых отечественных конкурентов на сегодняшний день у «Сферы. Релизы» и «Сфера. Контрольные точки» нет. Это объясняется тем, что рынок в большей степени ориентирован на замещение инструментов первого этапа, предназначенных для эффективного управления задачами.
Несмотря на то, что заметных рыночных инструментов по управлению релизами и тем более контрольными точками на российском рынке сейчас нет, ряд крупных компаний вели собственную разработку или заказывали создание таких продуктов под свои процессы. Это и есть главный показатель востребованности подобных решений: компании готовы инвестировать десятки, а то и сотни миллионов рублей в устранение этого дефицита. Мы же даем более доступный инструмент, который подходит и корпорациям, и сегменту МСБ.
Если говорить о зарубежных аналогах, то плагины для релизного управления использовались в Jira. Целостный конвейер, который закрывал весь процесс, включая инженерные контрольные точки, был реализован в Microsoft AzureDevOps. Он стал бенчмарком и многие идеи для своих продуктов мы черпали у зарубежных коллег.
Как мы уже говорили, частично релизным процессом можно управлять в качественном таск-трекере. Он позволяет сконфигурировать сущности «поставка» и «релиз» и работать с ними. Но функциональность инструмента ограничена, а попытка «расшить» ее собственными силами — это большая методологическая и инженерная работа. Одно дело — внедрить готовый инструмент, который сформирует календарь релизов, напомнит, что нужно учесть, чтобы релиз состоялся, и так далее. И другое — реализовать все то же самое на таск-трекере. Теоретически можно, практически и методологически — довольно сложно.
«Сфера. Релизы» — специализированный инструмент управления релизным циклом, который позволяет фиксировать и контролировать их состав. Он же показывает, все ли пользовательские истории закрыты, прежде чем передавать поставку в сборку. Еще одна его функция — отображение статуса готовности разрабатываемого ПО и планов релизных активностей в календарном представлении. Кроме того, инструмент позволяет координировать любые активности между командами. Его особенность в том, что он может работать в связке с таск-трекером любого вендора.
«Сфера. Контрольные точки» — инструмент для более зрелых компаний, которые ведут одновременно множество релизов. С его помощью бизнес получает возможность в автоматическом режиме отслеживать объекты контроля и стадии выполнения задач: текущее состояние, результаты тестирование, закрытие дефектов. Скажем, у нас есть некая User Story, которая должна войти в поставку. Смотря на карточку каждой истории, мы видим прогресс ее выполнения. Как только контрольная точка достигает 100%, это значит, что эту User Story можно включать в состав поставки. После этого начинается расчет контрольных точек уже для самой поставки. Когда состав поставки достигнет 100%, это будет означать, что ее можно отправлять дальше.
Помимо процессных контрольных точек есть инженерные, которые позволяют оперативно выявить технические ошибки в сборке — ИТ-система просто не пропустит релиз на программно-аппаратном уровне, пока абсолютно все дефекты не будут устранены.
Во многом мы ориентировались на потребности наших собственных команд разработки внутри «Холдинга Т1» и запросы наших крупных заказчиков, для которых создавались подобные продукты. Мы увидели, какая функциональность требуется большому бизнесу, и уже на основе этого создавали наш универсальный и гибко конфигурируемый инструмент. Кстати, достаточно большой спрос на Сфера. Контрольные точки — это большой комплимент отечественному рынку разработки, так это как служит показателем зрелости компаний.
Приоритетных направлений два. Первое — наращивать гибкость и возможность конфигурации системы под задачи заказчика. Второе — расширять поддержку смежных систем. Не секрет, что лучше всего эти инструменты работают в связке с другими продуктами платформы «Сфера». При этом мы понимаем, что далеко не все заказчики готовы менять уже используемые системы на наши, поэтому расширяем возможности интеграции с той же Jira, с которой далеко не все готовы расстаться, с конкурирующими отечественными системами. Мы не ломаем уже имеющиеся системы или процессы, мы подстраиваемся под них. Своей ключевой задачей мы видим легкость внедрения наших инструментов в любой конвейер по производству высокотехнологичных решений.
Источник фото: © vska / Фотобанк Фотодженика