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