СПОСОБ И СИСТЕМА АВТОМАТИЗИРОВАННОГО УПРАВЛЕНИЯ РЕЛИЗАМИ ПРИЛОЖЕНИЙ Российский патент 2024 года по МПК G06F8/71 G06F21/57 

ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

[002] Из уровня техники известны различные решения, направленные на диагностику программного кода.

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

[004] Также известны способ и система выявления эксплуатируемых уязвимостей в программном коде на основе машинного обучения, описанные в патенте RU 2790005 C1, опубл. 14.02.2023. Способ и система основаны на поэтапном получении данных об уязвимостях в коде, последующем построении вектора атаки на основе этих данных, типизации уязвимости в исходном коде с последующим 1 преобразованием в AST-дерево, далее анализатор производит поиск элемента вектора атаки по координатам в AST-дереве, фиксирует пути между найденными элементами, далее из элементов пути формируется векторное представление и производится машинное обучение (МО) данному пути (векторному представлению) для того, чтобы выявить почерк эксплуатируемых уязвимостей. Цели, которых достигает решение - значительное сокращение ручных трудозатрат, повышение точности выявления за счет автоматизации анализа способом МО и сокращение ошибок ручной работы (человеческого фактора).

[005] Однако, известное решение не способно выявить проблемы системного характера, такие как понижение производительности/прерывания работоспособности для конечных пользователей, стилистические отклонения в написании кода, влекущие за собой потерю соответствия стандартам и потерю гибкости изменения/масштабирования вследствие отклонения от стандартов, т.е. не заложено управление качеством. В способе также не заложен подход к реализации ускоренной диагностики проблем безопасности кода комплексно, в составе интеграции/релиза на основе метрик (только проводится анализ кода на наличие уязвимостей), использует другой метод анализа (МО). Кроме того, способ не выявляет потенциальных проблем и сбоев с облачным биллингом на платформе, вследствие чего Компания может понести репутационные риски и финансовый ущерб как собственный, так и одновременно сразу большого числа своих Клиентов.

[006] Известен способ поддержки процессов организационной системы, раскрытый в патенте RU 2725779 C1, опубл. 06.07.2020. Метод, описываемый в данном документе, построен на автоматическом формировании данных о допустимых и фактических показателях противодействующих процессов и автоматического управления сдерживанием их негативного влияния на процессы организационной системы, путем сличения показателей и реагирования по заранее предопределенным сценариям, путем уведомления и путем передачи данных в ответственные организационные подразделения (нотификация и инструктаж на исполнение). Значительным недостатком данного метода является то, что если данные о фактических показателях процессов организационной системы ниже данных соответствующих допустимых показателей, при этом заложенных заранее сценариев выполнения работ сдерживания негативного влияния противодействующих процессов нет, то метод передает данные о фактических и допустимых показателях в подразделения организационной системы для разработки новых сценариев сдерживания. Это является недочетом автоматического способа, переходом на ручной уровень разработки нового сценария, что может занять значительное время.

[007] Известные решения, в целом, не обеспечивают комплексный и автоматизированный подход к решению проблем управления уровнем качества, безопасности и надежности релизов, предлагая автоматизацию/анализируя отдельные этапы, например, только набор сценариев, эталонных метрик и свойств артефактов на входе, без учета влияния свойств на уже работающей системе и контроля свойств (качества, безопасности и надежности работы) системы в любой момент времени. В известных решениях для анализа используют только отдельный аспект анализируемого объекта(ов) - кодовой базы или вектора атаки, не предоставляя при этом совокупного результата в виде замеров и метрик интеграционного тестирования (производительности, безопасности, надежности, соответствия эталонам и стандартам кодовой базы) релиза, жизненных показателей поведения платформы до и после релиза, в целом. Конечные результаты также носят или информирующую, или инструктирующую функцию, без описания какого-либо технического решения, результатом которого было бы или реакция самой системы в реальном мире, или комплексный набор очевидных преимуществ по сравнению с предшествующими уровнями техники.

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

СУЩНОСТЬ ТЕХНИЧЕСКОГО РЕШЕНИЯ

[009] Технической проблемой или задачей, поставленной в данном техническом решении, является создание простого и надежного способа и системы автоматизированного управления релизами приложений.

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

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

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

- формируют новую версию приложения в соответствии с внесенными изменениями;

- определяют значение метрики качества кодовой базы приложения (Solidarity);

- сравнивают значение метрики Solidarity с допустимыми значениями метрики, причем если значение метрики Solidarity не соответствует допустимым значениям, то направляют команду для отклонения запроса на внесение изменений, а если значение метрики Solidarity соответствует допустимым значениям, то выполняют сборку новой версии приложения с внесенными изменениями в релиз;

- размещают новую версию приложения в сервисе приложений.

[0012] В одном из частных примеров осуществления способа этап определения метрики Solidarity содержит этапы, на которых:

- извлекают настройки по меньшей мере одного репозитория;

- сравнивают настройки репозитория с допустимыми значениями параметров репозиториев и на основе результатов сравнения определяют значение подметрики, характеризующее корректность настроек репозитория (GitFlow);

причем метрика Solidarity определяется с учетом значения подметрики GitFlow.

[0013] В другом частном примере осуществления способа этап определения метрики Solidarity содержит этапы, на которых:

- извлекают список зависимостей пакетов приложения, сохраненный по меньшей мере в одном репозитории;

- определяют форму зависимости «shouldBeStrict»: строгая форма зависимости или нестрогая форма зависимости;

- на основе формы зависимости «shouldBeStrict» определяют значение подметрики shouldBeStrict;

- извлекают данные о зависимости с пакетами, сохраненными во внешних хранилищах;

- определяют, находятся ли данные о зависимости с пакетами, сохраненными во внешних хранилищах, в соответствующих разделах;

- на основе информации о расположении упомянутых данных о зависимости определяют значение подметрики «shouldBeDevDeps»;

- извлекают данные о зависимости с пакетами, сохранными во внутренних репозиториях;

- определяют, находятся ли данные о зависимости с пакетами, сохраненными во внутренних репозиториях, в соответствующих разделах;

- на основе информации о расположении упомянутых данных о зависимости определяют значение подметрики «shouldBeDeps»;

- извлекают данные, характеризующие версию зависимости, и сравнивают со списком актуальных версий зависимостей;

- на основе результатов сравнения определяют значение подметрики «should BeUpdated»;

- извлекают данные о зависимости и сравнивают их со списком запрещенных зависимостей;

- на основе результатов сравнения определяют значение подметрики «shouldNotBellsed»;

- определяют, описана ли зависимость как превью и на основе результатов определения назначают значение подметрики «previewPackages»;

- осуществляют поиск в наборе файлов приложения файла с названием «renovate» и на основе наличия файла или отсутствия файла назначают значение подметрики корректности файлов;

- на основе значений подметрик «shouldBeStrict», «shouldBeDevDeps», «shouldBeDeps», «shouldBellpdated», «shouldNotBeUsed» и корректности файлов определяют подметрику Dependencies;

причем метрика Solidarity определяется с учетом значения подметрики Dependencies.

[0014] В другом частном примере осуществления способа этап определения метрики Solidarity содержит этапы, на которых:

- извлекают конфигурацию пайплайна;

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

- извлекают список переменных окружения для каждого репозитория;

- сравнивают список переменных окружения с допустимыми значениями переменных для определения значения подметрики качества переменных репозитория;

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

- на основе подметрики корректности конфигурации пайплайна, подметрики корректности использования переменных окружения и подметрики развертывания приложения определяют значение подметрики CI/CD;

причем метрика Solidarity определяется с учетом значения подметрики CI/CD. [0015] В другом частном примере осуществления способа этап определения метрики Solidarity содержит этапы, на которых:

- извлекают из по меньшей мере одного репозитория параметры маршрутизации пакетов;

- сравнивают параметры маршрутизации пакетов с допустимыми значениями параметров пакетов;

- на основе результатов сравнения назначают значение подметрики Routing;

причем метрика Solidarity определяется с учетом значения подметрики Routing.

[0016] В другом частном примере осуществления способа этап определения метрики Solidarity содержит этапы, на которых:

- определяют версии заданных пакетов;

- сравнивают версии заданных пакетов с допустимыми значениями версий пакетов;

- на основе результатов сравнения назначают значение подметрики Environments;

причем метрика Solidarity определяется с учетом значения подметрики Environments.

[0017] В другом частном примере осуществления способа этап определения метрики Solidarity содержит этапы, на которых:

- проверяют наличие файлов package.json и.gitlab/CODEOVVNERS;

- проверяют наличие в файлах информации о владельце кода, владельце продукта, техническом лидере;

- на основе наличия или отсутствия упомянутой информации назначают значение подметрики CODEOWNERS;

причем метрика Solidarity определяется с учетом значения подметрики CODEOWNERS.

[0018] В другом частном примере осуществления способа этап определения метрики Solidarity содержит этапы, на которых:

- анализируют код посредством инструмента ESLint;

- определяют количество значений «warning» в результатах анализа;

- на основе количества значений «warning» определяют значение подметрики CodeStyle;

причем метрика Solidarity определяется с учетом значения подметрики CodeStyle.

[0019] В другом частном примере осуществления способа этап определения метрики Solidarity содержит этапы, на которых:

- извлекают настройки helm и название проекта, а также название приложения в репозитории;

- сравнивают название приложения в извлеченных данных и на основе результатов сравнения назначают значение подметрики Gitlab Structure;

причем метрика Solidarity определяется с учетом значения подметрики Gitlab Structure.

[0020] В другом частном примере осуществления способа метрика Solidarity определяется на основе подметрик GitFlow, Dependencies, CI/CD; Routing, Environments, CODEOWNERS, CodeStyle, Gitlab Structure и коэффициентов значимости каждой подметрики

[0021] В другом частном примере осуществления способа дополнительно выполняют этапы, на которых:

- извлекают информацию о количестве проведенных юнит-тестов и сквозного тестирования;

- на основе количества тестов определяют для приложения QA-метрику;

- сравнивают значение QA-метрики с допустимыми значениями метрики, причем если значение QA-метрики не соответствует допустимым значениям, то направляют команду для отклонения запроса на внесение изменений, а если значение QA-метрики соответствует допустимым значениям, то выполняют сборку новой версии приложения с внесенными изменениями в релиз.

[0022] В другом частном примере осуществления способа дополнительно выполняют этапы, на которых:

- в процессе работы приложения, размещенного в сервисе приложений, регистрируют события, связанные с работой приложения;

- определяют количество обработанных исключений или необработанных исключений определенного типа за единицу времени;

- определяет отношение количества обработанных исключений или необработанных исключений к количеству событий заданного для них типа за заданное время;

- сравнивают упомянутое отношение с допустимыми значениями;

- определяют, что упомянутое отношение превышает допустимые значения;

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0024] Признаки и преимущества настоящего изобретения станут очевидными из приводимого ниже подробного описания изобретения и прилагаемых чертежей, на которых:

На Фиг. 1 - представлен пример реализации системы автоматизированного управления релизами приложений.

На Фиг. 2 - представлена примерная схема способа автоматизированного управления релизами приложений.

На Фиг. 3 - представлен пример общего вида вычислительного устройства.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

[0025] Ниже будут описаны понятия и термины, необходимые для понимания данного технического решения.

[0026] В данном техническом решении под системой подразумевается, в том числе компьютерная система, ЭВМ (электронно-вычислительная машина), ЧПУ (числовое программное управление), ПЛК (программируемый логический контроллер), компьютеризированные системы управления и любые другие устройства, способные выполнять заданную, четко определенную последовательность операций (действий, инструкций).

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

[0028] Устройство обработки команд считывает и выполняет машинные инструкции (программы) с одного или более устройств хранения данных. В роли устройства хранения данных могут выступать, но не ограничиваясь, жесткие диски (HDD), флеш-память, ПЗУ (постоянное запоминающее устройство), твердотельные накопители (SSD), оптические приводы.

[0029] В соответствии со схемой, приведенной на фиг. 1, система автоматизированного управления релизами приложений, в частном варианте ее реализации, содержит соединенные каналами связи по меньшей мере одно устройство 10 разработчика, сервис 20 приложений, устройство 30 пользователя приложения, сервис 100 анализа метрик, по меньшей мере три репозитория 101, 103 и устройство 200 диспетчеризации и сервис 300 обработки live-метрик приложения.

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

[0031] В соответствии с заданным расписанием блок 1011 анализа метрик осуществляет сбор метрик данных о репозиториях сервисов. В частности, блок 1011 собирает настройки репозиториев 101, 102, 103, а также данные о по меньшей мере одном приложении, посредством которого предоставляется по меньшей мере один сервис.Упомянутое приложение может представлять собой набор файлов, содержащих программный код приложения, размещенных в репозиториях 101, 102, 103.

[0032] Например, приложение может быть предназначено для предоставления сервиса управления ключами, причем:

- репозиторий 101 может содержать первый набор файлов с клиентским программным кодом приложения;

- репозиторий 102 может содержать второй набор файлов с библиотекой визуальных компонентов, например, с параметрами кнопки, в соответствии с которыми она будет отображена в интерфейсе пользователю сервиса,

- репозиторий 103 может содержать третий набор файлов с программным кодом, описывающим способ доставки программного кода из контейнера до пользователя. [0033] После того, как упомянутые данные собраны, блок 1011 переходит к определению метрики качества кодовой базы приложения (Solidarity). Метрика Solidarity может быть определена на основе подметрик, характеризующих:

- корректность настроек репозитория (GitFlow);

- уровень стабильности зависимостей пакетов (Dependencies) (см., например, статью «Stable Dependencies», размещенную в Интернет по адресу: https://deviq.com/principles/stable-dependencies);

- корректность параметров развертывания переменных окружения приложения (CI/CD);

- корректность маршрутизации (Routing);

- корректность файлов конфигурации окружения (Environments);

-корректность файла для указания владельцев кода (CODEOWNERS);

- корректность стиля программного кода (CodeStyle);

- корректность структуры программного кода (Gitlab Structure).

[0034] Например, для определения подметрики GitFlow блок 1011 может сравнить настройки репозиториев, в которых хранится приложение, с допустимыми значениями параметров репозиториев. Для получения настроек блок 1011 может направить запрос, например, в формате HTTP в блок хранения данных каждого репозитория, к котором хранятся настройки репозитория и которой в ответ на упомянутый запрос осуществляет поиск файла с настройками репозитория, извлекает из памяти информацию о настройках репозитория, например, в формате JSON, и направляет их в блок 1011.

[0035] Полученные настройки репозитория блок 1011 сравнивает с допустимыми значениями настроек и на основе результатов сравнения определяет подметрики Gitflow. Например, из полученных настроек блок 1011 может извлечь значения, приведенные в полях «default_branch», «merge_method», «squash_option», и сравнить их с допустимыми значениями настроек «master», «fast_forward» и «never» соответственно, заданными в блоке 1012 хранения данных. Если значения настроек репозитория совпали с допустимыми значениями настроек, то блок 1011 назначает максимальное значение подметрики GitFlow, например, 100%. Если значения настроек репозитория не совпали с допустимыми значениями настроек, то блок 1011 назначает минимальное значение подметрики GitFlow, например, 0%. Если с допустимыми значениями настроек совпала только часть значений настроек репозитория, то в качестве подметрики GitFlow блоком 1011 может быть назначено значение, характеризующее отношение между количеством значений параметров репозитория, которые совпали с допустимыми значениями, к количеству всех возможных параметров репозитория.

[0036] Далее блок 1011 переходит к этапу определения подметрики Dependencies. Для определения упомянутой подметрики блок 1011 может быть оснащен парсером программного кода и API файлов репозитория, посредством которых блок 1011 осуществляет поиск файла package.json в блоке хранения данных каждого репозитория и анализ программного кода упомянутого файла, например, семантического анализа для поиска полей dependencies и devDependencies, в которых приведен список зависимостей пакетов приложения.

[0037] Например, список зависимостей может содержать информацию, указывающую на наличие зависимости пакета из первого набора файлов, сохраненного в репозитории 101, с по меньшей мере одним пакетом из второго набора файлов, сохраненных в репозитории 102, содержащего параметры кнопки, в соответствии с которыми она будет отображена в интерфейсе пользователю сервиса.

[0038] Список зависимостей, сохраненный в репозитории 101, может содержать следующие данные:

{

dependencies: {

button-102: 0.0.1,

form-102: 0.0.1-assbfabd,

modal-102: ^Л0.0.1,

eslint: 0.0.1,

buttonBlackList-102: 0.0.1

}.

devDependencies: {

link-102: 0.0.1

}

}

где «button» - ID пакета (например, имя пакета), идентификатор «102» указывает на то, что пакет «button» приходит из репозитория 102.

[0039] После того, как список зависимостей извлечен, блок 1011 определяет форму зависимости «shouldBeStrict», например, посредством сопоставления символов указанной зависимости. Зависимость «shouldBeStrict» представлена в указанном выше примере как «modal-102: ^Л0.0.1». Соответственно, если блоком 1011 определено, что зависимость «shouldBeStrict» указана в нестрогой форме, например, указанная зависимости содержит галочку (^Л), то блок 1011 назначает минимальное значение подметрики shouldBeStrict, например, 0%. Если блоком 1011 определено, что зависимость «shouldBeStrict» указана в строгой форме, т.е. галочка (^Л) отсутствует, то блок 1011 назначает максимальное значение подметрики shouldBeStrict, например, 100%.

[0040] Дополнительно блок 1011 определяет подметрику зависимости «shouldBeDevDeps», характеризующую корректность размещения данных о зависимости с пакетами, сохраненными во внешних хранилищах, в соответствующих разделах. Поскольку зависимость «shouldBeStrict» представлена в указанном выше примере как «eslint 0.0.1» и поскольку упомянутая зависимость не связана с репозиториями 101, 102 или 103, то она должна находиться в разделе devDependencies. Соответственно, если зависимость «shouldBeDevDeps» (в частности, «eslint 0.0.1») не находится в разделе devDependencies, то блок 1011 назначает минимальное значение подметрики «shouldBeDevDeps», например, 0%. Если зависимость «shouldBeDevDeps» находится в разделе devDependencies, то блок 1011 назначает максимальное значение подметрики «shouldBeDevDeps», например, 100%

[0041] Дополнительно блок 1011 определяет подметрику зависимости shouldBeDeps, характеризующую корректность размещения данных о зависимости с пакетами, сохраненными во внутренних репозиториях (в частности, в репозиториях 101, 102, 103), в соответствующих разделах. Зависимость shouldBeDeps представлена в указанном выше примере как «link-102: 0.0.1» и должна находиться в разделе dependencies, поскольку имеет связь с нашим внутренним репозиторием 102. Соответственно, если зависимость «shouldBeDeps» (в частности, «link-102: 0.0.1») не находится в разделе dependencies, то блок 1011 назначает минимальное значение подметрики «shouldBeDeps», например, 0%. Если зависимость «shouldBeDeps» находится в разделе dependencies, то блок 1011 назначает максимальное значение подметрики «shouldBeDeps», например, 100%.

[0042] Дополнительно блок 1011 определяет подметрику зависимости shouldBeUpdated, характеризую корректность версии зависимости. Для определения упомянутой подметрики в блок 1012 может быть заранее загружен список актуальных версий зависимостей, содержащий ID зависимости и ее номер актуальной версии. Соответственно, блок 1011 извлекает данные, характеризующие версию зависимости, например, «0.0.1» из поля button-102, и сравнивает со списком актуальных версий зависимостей. Если данные, характеризующие версию зависимости, совпадают с актуальной версией, то блок 1011 назначает максимальное значение подметрики «shouldBeUpdated», например, 100%. Если данные, характеризующие версию зависимости, не совпадают с актуальной версией (например, актуальная версия 0.0.2), то блок 1011 назначает минимальное значение подметрики «shouldBellpdated», например, 0%. [0043] Дополнительно блок 1011 определяет подметрику зависимости shouldNotBeUsed, характеризующую безопасность используемых зависимостей. Для определения упомянутой подметрики в блок 1012 может быть заранее загружен список запрещенных зависимостей, в котором может быть указана, например, зависимость «buttonBlackList-102» и ее версия. Соответственно, блок 1011 извлекает из пакета данные о зависимости и сравнивает их со списком запрещенных зависимостей. Если данные о зависимости пакета содержат запрещенную зависимость, в частности «buttonBlackList-102», то блок 1011 назначает минимальное значение подметрики «shouldNotBeUsed», например, 0%. Если данные о зависимости пакета не содержат запрещенную зависимость, то блок 1011 назначает максимальное значение подметрики «shouldNotBeUsed», например, 100%.

[0044] Дополнительно блок 1011 может определить, что зависимость описана как превью и на основе данной информации назначить значение подметрики «previewPackages». Например, блок 1011 может извлечь зависимость «form-102: 0.0.1-assbfabd» и определить, что указанная зависимость содержит в версии буквенный постфикс и принять решение о том, что зависимость описана как превью, после чего назначить минимальное значение подметрики «previewPackages», например, 0%. Соответственно, если зависимость не содержит в версии буквенный постфикс, то блок 1011 назначает максимальное значение подметрики «previewPackages», например, 100%.

[0045]Также блок 1011 осуществляет поиск в наборе файлов, сохраненных в репозитории, файла с названием «renovate». Если упомянутый файл отсутствует в наборе фалов, то блок 1011 назначает минимальное значение подметрики корректности файлов, например, 0%. Если упомянутый файл присутствует в наборе фалов, то блок 1011 назначает максимальное значение подметрики корректности файлов, например, 100%.

[0046] После того, как подметрики «shouldBeStrict», «shouldBeDevDeps», «shouldBeDeps», «shouldBellpdated», «shouldNotBellsed» и корректности файлов определены, блок 1011 определяет коэффициент значимости метрики (например, от 0 до 10), определяющий долю участия подметрики в итоговом значении подметрики Dependencies. Итоговая подметрика Dependencies рассчитывается как сумма упомянутых подметрик, помноженная на соответствующий коэффициент значимости подметрки.

[0047] Далее блок 1011 переходит к определению подметрики CI/CD. Для определения упомянутой подметрики блок 1011 запрашивает у блока хранения данных каждого репозитория конфигурацию пайплайна, например, в виде файла gitlab-ci.yaml из репозитория 101. Например, конфигурация пайплайна в упомянутом файле может быть представлена в виде программного кода: include:

- project: cp/infrastructure/devops

ref: master

file: /gitlab-ci/entries/front.yaml

[0048] В упомянутом файле gitlab-ci.yaml хранятся ссылки на файлы из репозитория 103, содержащие способ доставки программного кода до пользователя.

[0049] Полученная конфигурация пайплайна сравнивается с заданной допустимой конфигурацией для определения значения подметрики корректности конфигурации пайплайна. Например, данные о допустимой конфигурации могут указывать на то, что конфигурация пайплайна должна содержать поля «project» «ref» «file» со значениями «ср/infrastructure/devops», «master», «/gitlab-ci/entries/front.yaml» соответственно. Если по меньшей мере одно поле или значение отсутствует в конфигурации пайплайна или значение поля не совпадает с допустимыми, то блок 1011 назначает наименьшее значение подметрики корректности конфигурации пайплайна, например, 0%. Если конфигурации пайплайна совпадают с допустимой конфигурацией, то блок 1011 назначает наивысшее значение подметрики корректности конфигурации пайплайна, например, 100%.

[0050] Дополнительно блок 1011 может быть выполнен с возможностью определения корректности использования переменных окружения для каждого репозитория. Переменные окружения - это набор значений, которые определяют поведение и настройки операционной системы, а также других программ, работающих в этой среде (см., например, статью «Что такое переменные окружения и как их использовать», размещенную в Интернет по адресу: https://skv.pro/media/chto-takoe-peremennye-okruzheniya-i-kak-ih-ispolzovat/). Для определения упомянутой подметрики блок 1011 запрашивает у блока хранения данных каждого репозитория список переменных посредством соответствующего запроса, в ответ на который направляется список переменных для репозитория. Далее полученный список переменных репозитория сравнивается блоком 1011 с заданными допустимыми значениями переменных. Например, блок 1011 может проанализировать упомянутый список и определить наличие в упомянутом списке информации по меньшей мере об одной переменной и назначить наименьшее значение подметрики качества переменных репозитория, например, 0%. В то же время если список переменных пуст, т.е. отсутствует информация о переменных, то блок 1011 может назначить высокое значение подметрики корректности использования переменных репозитория, например, 100%.

[0051] Дополнительно блок 1011 может быть выполнен с возможностью определения подметрики развертывания приложения. Для определения упомянутой подметрики блок 1011 определяет статус приложения, указывающий на то, было ли приложение размещено по меньшей мере в одной вычислительной среде, например, среде «development» или «production». При размещении приложения в вычислительную среду в программном коде приложения формируется соответствующая информация, описывающая идентификатор вычислительной среды, время размещения, информация об успешном размещении приложения в вычислительной среде и прочее. Например, упомянутая информация может быть представлена в следующем виде:

{

"id": 371551,

"iid": 498,

"ref: "refs/merge-requests/68/head",

"sha": "1dccc79c78c084391d61d67e333bf8ec33b05661",

"created_at": "2023-10-25T16:02:11.939+03:00", "updated_at": "2023-10-25716:10:33.708+03:00",

"environment": {

"id": 258,

"name": "develop",

"slug": "develop",

"created_at": "2021-11-20T17:45:54.930+03:00", "updated_at": "2023-10-09T16:19:04.008+03:00" }, "status": "success" }

[0052] Соответственно, блок 1011 запрашивает у блока 1012 хранения данных репозитория указанную выше информацию, извлекает информацию о статусе приложения и если упомянутый статус указывает на то, что приложение было размещено в вычислительной среде, т.е. в поле «status» указано «success», то блок 1011 может назначить высокое значение подметрики развертывания приложения, например, 100%. Если статус указывает на то, что приложение не было размещено в вычислительной среде, то блок 1011 может назначить наименьшее значение подметрики развертывания приложения, например, 0%.

[0053] Далее на основе подметрики корректности конфигурации пайплайна, подметрики корректности использования переменных окружения и по меньшей мере одной подметрики развертывания приложения блок 1011 определяет подметрику CI/CD. Например, в качестве подметрики CI/CD может быть назначено блоком 1011 значение, характеризующее процент подметрик, характеризующих высокое значение подметрик, по отношению к общему числу подметрик. Дополнительно блок 1011 может определить подметрику Routing.

[0054] Для определения упомянутой подметрики блок 1011 запрашивает у блока хранения данных каждого репозитория параметры маршрутизации пакетов, которые могут быть представлены в файле package.json, например, в виде имен пакетов. Полученные параметры маршрутизации пакетов сравниваются блоком 1011 с заданными в блоке 1012 допустимыми значениями параметрами пакетов, например, с допустимыми именами пакетов, причем если параметры маршрутизации пакетов соответствуют упомянутым допустимым значениям, то блок 1011 назначает высокое значение метрики, например, 100%. Если параметры маршрутизации пакетов не соответствуют упомянутым допустимым значениям, то блок 1011 назначает минимальное значение метрики, например, 0%.

[0055] Также дополнительно в блоке 1012 может быть сохранен список требуемых параметров маршрутизации пакетов и список недопустимых параметров маршрутизации. Например, в качестве требуемых параметров маршрутизации пакетов может быть задано имя пакета «@sbercloud/ft-router», а в качестве недопустимых параметров маршрутизации - имена «react-router- dom, found, @reach/router». Соответственно, если блоком 1011 определено, что параметры маршрутизации пакетов не содержат требуемые параметры или содержат недопустимые параметры, блок 1011 назначает минимальное значение метрики, например, 0%. В ином случае блок 1011 назначает максимальное значение метрики, например, 100%.

[0056] Дополнительно блок 1011 может быть выполнен с возможностью определения подметрики Environments. Для определения упомянутой подметрики блок 1011 запрашивает у блока хранения данных каждого репозитория версии заданных пакетов, по аналогии с метрикой Dependencies, которые в свою очередь, предназначены для проверки версий файлов package.json и.nmprc, и сравнивает их с допустимыми значениями версий пакетов. Например, версии пакетов могут быть указаны в полях npm, node-js на соответствие заданным допустимым значениям версий пакета. Список пакетов, которые проверяются в рамках подметрики Environments (проверяются, что они используются в проекте и их версии актуальные, не меньше каких-то предзаданных): @sbercloud/ft-config-docker @sbercloud/ft-all-linters-pack @sbercloud/ft-config-tsconfig @sbercloud/ft-config-webpack-spa @sbercloud/ft-config-spa-entry.

[0057] Если версия пакета не соответствует допустимым значениям версий или в полученном ответе содержится файл.nmprc, то блок 1011 назначает минимальное значение подметрики Environments, например, 0%. Если версия пакета соответствует допустимым значениям версий и в полученном ответе не содержится файл.nmprc, то блок 1011 назначает максимальное значение подметрики Environments, например, 100%.

[0058] Дополнительно блок 1011 может быть выполнен с возможностью определения подметрики CODEOWNERS. Для определения упомянутой подметрики блок 1011 обращается к полученному ранее файлу package.json, а также файлу.gitlab/CODEOWNERS, проверяет их наличие, проверяет наличие информации о владельце кода, владельце продукта, техническом лидере, которые могут быть указаны, например, в полях «codeOwners», «productowner» и «techLead». Также дополнительно может быть проверено поле «pid» на наличие идентификатора проекта. Если информация о владельце кода или ID проекта отсутствует, то блок 1011 назначает минимальное значение подметрики CODEOWNERS, например, 0%. Если информация о владельце кода и ID проекта присутствует в файле package.json, то блок 1011 назначает максимальное значение подметрики CODEOWNERS, например, 100%.

[0059] Дополнительно блок 1011 может быть выполнен с возможностью определения подметрики CodeStyle. Для определения упомянутой подметрики блок 1011 запускает анализатор кода, реализованный на базе инструмента ESLint, который извлекает из блоков хранения данных репозиториев программный код приложения и выполняет его анализ известными методами. По результату анализа анализатор кода формирует файл с результатами анализа, после чего блок 1011 выполняет анализ упомянутого файла с результатами для определения количества сообщений, в поле которых содержится значение «warning». Далее на основе определенного количества сообщений блок 1011 определяет подметрику CodeStyle. Например, для 30 сообщений может быть назначено минимальное значение подметрики CodeStyle, например, 0%, а для 0 сообщений - максимальное значение подметрики CodeStyle, например, 100%.

[0060] Дополнительно блок 1011 может быть выполнен с возможностью определения подметрик Gitlab Structure. Для определения упомянутой подметрики блок 1011 запрашивает у блока 1012 хранения данных настройки helm и название проекта, а также название приложения в репозитории. Если название в настройках helm совпадает с названием приложения в репозитории, а также в них содержится информация о названии проекта, то блок 1011 назначает максимальное значение подметрики Gitlab Structure, например, 100%. Если название в настройках helm не совпадает с названием приложения в репозитории или название приложения или название проекта отсутствует, то блок 1011 назначает минимальное значение подметрики Gitlab Structure, например, 0%.

[0061] Далее блок 1011 на основе по меньшей мере одной подметрики или всех подметрик GitFlow, Dependencies, CI/CD; Routing, Environments, CODEOWNERS, CodeStyle, Gitlab Structure определяет значение метрики Solidarity. Для определения значения метрики Solidarity блок 1011 определяет коэффициент значимости каждой подметрики, заранее заданный в блоке 1012 в зависимости от ее важности, после чего на основе по меньшей мере одной подметрики и коэффициента значимости определяется значение метрики Solidarity, например, посредством перемножения по меньшей мере одной подметрики и коэффициента значимости.

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

[0063] В альтернативном варианте реализации представленного решения значение метрики Solidarity может быть определено как наименьшее значение из подметрик GitFlow, Dependencies, CI/CD; Routing, Environments, CODEOWNERS, CodeStyle, Gitlab Structure.

[0064] Далее блок 1011 направляет значение метрики Solidarity и подметрики в блок 201 обработки данных устройства 200 диспетчеризации, который сохраняет их в хранилище 203, а также сравнивает с допустимыми значениями метрик Solidarity. Если значение метрики Solidarity соответствует допустимым значениям, то блок 201 данных завершает свою работу до поступления новых данных от блока 1011. Если значение метрики Solidarity не соответствует допустимым значениям, то блок 201 формирует уведомление на устройство разработчика для оповещения о необходимости внести изменения в настройки репозитория или программный код приложения. Также блок 201 по истечению заданного времени формирует команду в каждый репозиторий, в котором хранится приложение, на их блокировку.

[0065] Дополнительно блок 1011 может быть выполнен с возможностью определения QA-метрики - меры, позволяющей получить численное значение, характеризующее качество работы программного кода приложения. Для определения упомянутой метрики блок 1011 может обратиться к области памяти блока хранения данных каждого репозитория, в которой хранятся отчеты о запущенных юнит-тестах и сквозном тестировании (е2е-тестах). Юнит-тесты и е2е- тесты могут быть выполнены анализатором кода, реализованным на базе инструментов vitest и test-cafe, например, после загрузки приложения в репозитории, после внесений изменений в программный код приложения или согласно установленному разработчиком расписанию.

[0066] Из упомянутых отчетов блок 1011 извлекает информацию о количестве проведенных упомянутых тестов, после чего на основе количества тестов определяет для приложения QA-метрику.

[0067] Например, блок 1011 может определить, что был проведен один юнит-тест и два е2е-теста. Далее блок 1011 обращается к памяти, в которой может быть задано минимальное значение количества тестов, например, 20 юнит-тест и 20 е2е-теста, после чего блок 1011 на основе количества проведенных текстов и минимального значения тестов определяет подметрику юнит-теста и подметрику е2е-теста, на основе значений которых определяет QA-метрику, например, QA-метрика может быть определена как среднее значение упомянутых подметрик.

[0068] Например, блоком 1011 может быть определено, что в отношении приложения выполнены 1 юнит-тест и 2 е2е-теста. Соответственно, для минимального значение количества тестов 20 подметрика юнит-теста будет равна 5%, а подметрика е2е-теста - 10%. Таким образом, QA-метрика приложения будет определена как 7.5%. Также может быть определена QA-метрика репозитория как среднее значение всех QA-метрик приложений.

[0069]Далее блок 1011 направляет значение QA-метрики приложения и/или репозитория в блок 201 обработки данных устройства 200 диспетчеризации, который сохраняет их в хранилище 203, а также сравнивает с допустимыми значениями QA-метрик. Если значение QA-метрики приложения и/или репозитория соответствует допустимым значениям, то блок 201 данных завершает свою работу до поступления новых данных от блока 1011. Если значение QA-метрики приложения или репозитория не соответствует допустимым значениям, то блок 201 формирует запрос на устройство 10 разработчика для внесения изменений в настройки репозитория или программный код приложения.

[0070] В процессе работы системы обработки информации посредством устройства 10 разработчика может быть направлен запрос (см. Фиг 2, позиция 400) на внесение изменений в программный код приложения, например, сохраненного в репозитории 101. В частности, запрос на внесение изменений может содержать по меньшей мере одно из:

- скорректированный программный код приложения;

- скорректированный список зависимостей пакетов;

- уточненные параметры развертывания приложения и переменные окружения;

- уточненные параметры маршрутизации;

- скорректированные файлы сетевого окружения;

- скорректированные файлы для указания владельцев кода.

[0071] Упомянутый запрос поступает в блок 1013 обработки запросов, который формирует (401) в блоке 1012 новую версию приложения в соответствии с данными упомянутого запроса. После того, как новая версия приложения была сформирована, запускается блок 1011 анализ метрик, который описанный ранее способом определяет (402) подметрики GitFlow, Dependencies, CI/CD, Routing, Environments, CODEOWNERS, CodeStyle, Gitlab Structure определяет общее значение метрики Solidarity, а также QA-метрику.

[0072] Далее блок 1011 направляет значение метрики Solidarity новой версии приложения, подметрики и QA-метрику в блок 201 обработки данных устройства 200 диспетчеризации, который сохраняет их в хранилище 203, а также сравнивает (403) с допустимыми значениями упомянутых метрик. Если значение метрики Solidarity или QA-метрики не соответствует допустимым значениям, то блок 201 формирует команду в блок 1013 для отклонения запроса на внесение изменений и направления соответствующего уведомления к устройству 10 разработчика.

[0073] Если значения метрики Solidarity и QA-метрики соответствует допустимым значениям, то блок 201 формирует команду в блок 1013 для внесения изменений программный код приложения, после чего блок 1013 направляет команду в блок 1014 сборки приложения для сборки новой версии приложения в релиз (404). В частности, блок 1014 извлекает данные о приложении, сохранном в репозиториях, и размещает их в сервисе 20 приложений, после чего пользователь посредством устройства 30 может подключиться к сервису 20 и скачать приложение.

[0074] Также дополнительно блок 201 может сравнить метрики Solidarity и QA- метрики новой версии приложения с указанными метриками предыдущей/текущей версии приложения и в случае, если упомянутые метрики нового приложения будут меньше метрик предыдущей/текущей версии приложения, блок 201 формирует команду в блок 1013 для отклонения запроса на внесение изменений описанным ранее способом.

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

[0076] В процессе работы приложения, находящегося в продуктивной среде после проведения сборки и релиза, сервис 20 известными методами регистрирует различные типы событий, связанных с работой приложения. Методы регистрации упомянутых событий, например, раскрыты в статье «Поймай меня, если сможешь: руководство по обработке исключений в Python», опубликованной в Интернет по адресу https://habr.com/ru/companies/wunderfund/articles/736526/, причем событиями могут быть: легирование данных, вывод сообщения, попытка восстановить работу программы после возникновения ошибки и пр. Данные о событиях направляются сервисом 20 в сервис 300 обработки и хранения live-метрик приложения, в частности, в блок 301 обработки, который для каждого типа события определяет Live-метрику, характеризующую количество событий (связанных с работой приложения) определенного типа в единицу времени.

[0077] Например, live-метрика может характеризовать количество запросов страницы интерфейса приложения за единицу времени, где запрос страницы интерфейса является конкретными типом события.

[0078] Также live-метрика может характеризовать количество ошибок (обработанных исключений) определенного типа за единицу времени. Например, live-метрика может характеризовать количество неверно указанной пользователем даты в интерфейсе приложения, запущенного при помощи сервиса 20, которая может быть зарегистрирована упомянутым сервисом под именем «ОшибкаДанныхДата».

[0079] Дополнительно live-метрика может характеризовать количество неопознанных ошибок за единицу времени, т.е. необработанных исключений, зарегистрированных известными методами (см., например, статью «Необработанные исключения C++», размещенную в Интернет по адресу: https://learn.microsoft.com/ru-ru/cpp/cpp/unhandled-cpp-exceptions?view=msvc-170).

[0080] Дополнительно live-метрика может характеризовать количество вызовов API за единицу времени, например, количество вызовов метода API «api/address». Дополнительно live-метрика может характеризовать количество определенного типа действий пользователей за единицу времени, связанных с работой приложения, например, успешно отправленных сообщений посредством интерфейса приложения.

[0081] Далее блок 301 определяет отношение количества обработанных исключений и/или необработанных исключений к количеству событий заданного (например, в хранилище 302) для них типа за заданное время. Например, для количества неверно указанной пользователем даты может быть задан тип события - количество успешно обработанных событий, например, запросов страницы интерфейса за 10 мин., а для необработанных исключений может быть задан тип событий - успешно отправленные сообщения за 10 мин. Полученное значение отношения количества обработанных исключений или необработанных исключений к количеству событий заданного для них типа за заданное время сравнивается допустимыми значениями, заданными в хранилище 302, и если упомянутое значение отношений превышает допустимое, то блок 301 формирует в диспетчере 200 команду на отмену изменений приложения.

[0082] Обработку таких метрик может осуществлять специализированный инструмент, например, Prometheus. В перечень его функциональных возможностей входит вызов заранее указанного стороннего api в случае достижения каких-либо значений по каким-либо метрикам или их производным (блок 301). Например, в хранилище 302 сервиса 300 обработки live-метрик может быть установлено, что необходимо вызывать api отката релиза приложения в диспетчере 200, в случае если количество ошибок, в частности обработанных исключений, за последние, например, 10 минут, превышает 1% (допустимое значение) от общего количества запросов страницы интерфейса.

[0083] Блок 201 диспетчера 200 после получения команды на отмену изменений приложения формирует запрос на изменение по меньшей мере в один репозиторий, в котором хранится приложение, например, в виде реверс-коммита, который содержит в себе отмену последних изменений, т.е. вывода в релиз предыдущей версии приложения. Также, диспетчер направляет на устройство 10 разработчика уведомление о том, что live-метрики работы приложения содержат отклонения.

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

[0085] В общем виде (см. фиг. 3) вычислительное устройство содержит объединенные общей шиной информационного обмена один или несколько процессоров (501), средства памяти, такие как ОЗУ (502) и ПЗУ (503), интерфейсы ввода/вывода (504), устройства ввода/вывода (505), и устройство для сетевого взаимодействия (506).

[0086] Процессор (501) (или несколько процессоров, многоядерный процессор и т.п.) может выбираться из ассортимента устройств, широко применяемых в настоящее время, например, таких производителей, как: Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK™, Qualcomm Snapdragon™ и т.п. Под процессором или одним из используемых процессоров в устройстве (500) также необходимо учитывать графический процессор, например, GPU NVIDIA или Graphcore, тип которых также является пригодным для полного или частичного выполнения способа, а также может применяться для обучения и применения моделей машинного обучения в различных информационных системах.

[0087] ОЗУ (502) представляет собой оперативную память и предназначено для хранения исполняемых процессором (501) машиночитаемых инструкций для выполнения необходимых операций по логической обработке данных. ОЗУ (502), как правило, содержит исполняемые инструкции операционной системы и соответствующих программных компонент (приложения, программные модули и т.п.). При этом, в качестве ОЗУ (502) может выступать доступный объем памяти графической карты или графического процессора.

[0088] ПЗУ (503) представляет собой одно или более устройств постоянного хранения данных, например, жесткий диск (HDD), твердотельный накопитель данных (SSD), флэш-память (EEPROM, NAND и т.п.), оптические носители информации (CD-R/RW, DVD-R/RW, BlueRay Disc, MD) и др.

[0089]Для организации работы компонентов устройства (500) и организации работы внешних подключаемых устройств применяются различные виды интерфейсов В/В (504). Выбор соответствующих интерфейсов зависит от конкретного исполнения вычислительного устройства, которые могут представлять собой, не ограничиваясь: PCI, AGP, PS/2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRS/Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232 и т.п.

[0090] Для обеспечения взаимодействия пользователя с устройством (500) применяются различные средства (505) В/В информации, например, клавиатура, дисплей (монитор), сенсорный дисплей, тач-пад, джойстик, манипулятор мышь, световое перо, стилус, сенсорная панель, трекбол, динамики, микрофон, средства дополненной реальности, оптические сенсоры, планшет, световые индикаторы, проектор, камера, средства биометрической идентификации (сканер сетчатки глаза, сканер отпечатков пальцев, модуль распознавания голоса) и т.п.

[0091] Средство сетевого взаимодействия (506) обеспечивает передачу данных посредством внутренней или внешней вычислительной сети, например, Интранет, Интернет, ЛВС и т.п. В качестве одного или более средств (506) может использоваться, но не ограничиваться: Ethernet карта, GSM модем, GPRS модем, LTE модем, 5G модем, модуль спутниковой связи, NFC модуль, Bluetooth и/или BLE модуль, Wi-Fi модуль и др.

[0092] Дополнительно могут применяться также средства спутниковой навигации в составе устройства (500), например, GPS, ГЛОНАСС, BeiDou, Galileo. Конкретный выбор элементов устройства (500) для реализации различных программноаппаратных архитектурных решений может варьироваться с сохранением обеспечиваемого требуемого функционала.

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

Изобретение относится к вычислительной технике. Технический результат заключается в повышении надежности и безопасности работы устройств пользователей приложения. Способ автоматизированного управления релизами приложений, выполняемый вычислительным устройством и содержащий этапы, на которых: получают запрос на внесение изменений в программный код приложения; формируют новую версию приложения; определяют значение метрики качества кодовой базы приложения (Solidarity), причем метрика Solidarity определяется с учетом значения подметрики CI/CD; сравнивают значение метрики Solidarity с допустимыми значениями метрики; и размещают новую версию приложения в сервисе приложений. 2 н. и 10 з.п. ф-лы, 3 ил.

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

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

- формируют новую версию приложения в соответствии с внесенными изменениями;

- определяют значение метрики качества кодовой базы приложения (Solidarity), причем этап определения метрики Solidarity содержит этапы, на которых:

• извлекают конфигурацию пайплайна;

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

• извлекают список переменных окружения для каждого репозитория;

• сравнивают список переменных окружения с допустимыми значениями переменных для определения значения подметрики качества переменных репозитория;

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

• на основе подметрики корректности конфигурации пайплайна, подметрики корректности использования переменных окружения и подметрики развертывания приложения определяют значение подметрики CI/CD;

причем метрика Solidarity определяется с учетом значения подметрики CI/CD;

- сравнивают значение метрики Solidarity с допустимыми значениями метрики, причем если значение метрики Solidarity не соответствует допустимым значениям, то направляют команду для отклонения запроса на внесение изменений, а если значение метрики Solidarity соответствует допустимым значениям, то выполняют сборку новой версии приложения с внесенными изменениями в релиз;

- размещают новую версию приложения в сервисе приложений.

2. Способ по п. 1, характеризующийся тем, что этап определения метрики Solidarity содержит этапы, на которых:

- извлекают настройки по меньшей мере одного репозитория;

- сравнивают настройки репозитория с допустимыми значениями параметров репозиториев и на основе результатов сравнения определяют значение подметрики, характеризующее корректность настроек репозитория (GitFlow);

причем метрика Solidarity определяется с учетом значения подметрики GitFlow.

3. Способ по п. 1, характеризующийся тем, что этап определения метрики Solidarity содержит этапы, на которых:

- извлекают список зависимостей пакетов приложения, сохраненный по меньшей мере в одном репозитории;

- определяют форму зависимости «shouldBeStrict»: строгая форма зависимости или нестрогая форма зависимости;

- на основе формы зависимости «shouldBeStrict» определяют значение подметрики shouldBeStrict;

- извлекают данные о зависимости с пакетами, сохранными во внешних хранилищах;

- определяют, находятся ли данные о зависимости с пакетами, сохранными во внешних хранилищах, в соответствующих разделах;

- на основе информации о расположении упомянутых данных о зависимости определяют значение подметрики «shouldBeDevDeps»;

- извлекают данные о зависимости с пакетами, сохранными во внутренних репозиториях;

- определяют, находятся ли данные о зависимости с пакетами, сохранными во внутренних репозиториях, в соответствующих разделах;

- на основе информации о расположении упомянутых данных о зависимости определяют значение подметрики «shouldBeDeps»;

- извлекают данные, характеризующие версию зависимости, и сравнивают со списком актуальных версий зависимостей;

- на основе результатов сравнения определяют значение подметрики «shouldBeUpdated»;

- извлекают данные о зависимости и сравнивают их со списком запрещенных зависимостей;

- на основе результатов сравнения определяют значение подметрики «shouldNotBeUsed»;

- определяют, описана ли зависимость как превью, и на основе результатов определения назначают значение подметрики «previewPackages»;

- осуществляют поиск в наборе файлов приложения файла с названием «renovate» и на основе наличия файла или отсутствия файла назначают значение подметрики корректности файлов;

- на основе значений подметрик «shouldBeStrict», «shouldBeDevDeps», «shouldBeDeps», «shouldBeUpdated», «shouldNotBeUsed» и корректности файлов определяют подметрику Dependencies;

причем метрика Solidarity определяется с учетом значения подметрики Dependencies.

4. Способ по п. 1, характеризующийся тем, что этап определения метрики Solidarity содержит этапы, на которых:

- извлекают из по меньшей мере одного репозитория параметры маршрутизации пакетов;

- сравнивают параметры маршрутизации пакетов с допустимыми значениями параметров пакетов;

- на основе результатов сравнения назначают значение подметрики Routing;

- причем метрика Solidarity определяется с учетом значения подметрики Routing.

5. Способ по п. 1, характеризующийся тем, что этап определения метрики Solidarity содержит этапы, на которых:

- определяют версии заданных пакетов;

- сравнивают версии заданных пакетов с допустимыми значениями версий пакетов;

- на основе результатов сравнения назначают значение подметрики Environments;

причем метрика Solidarity определяется с учетом значения подметрики Environments.

6. Способ по п. 1, характеризующийся тем, что этап определения метрики Solidarity содержит этапы, на которых:

- проверяют наличие файлов package.json и .gitlab/CODEOWNERS;

- проверяют наличие в файлах информации о владельце кода, владельце продукта, техническом лидере;

- на основе наличия или отсутствия упомянутой информации назначают значение подметрики CODEOWNERS;

причем метрика Solidarity определяется с учетом значения подметрики CODEOWNERS.

7. Способ по п. 1, характеризующийся тем, что этап определения метрики Solidarity содержит этапы, на которых:

- анализируют код посредством инструмента ESLint;

- определяют количество значений «warning» в результатах анализа;

- на основе количества значений «warning» определяют значение подметрики CodeStyle;

причем метрика Solidarity определяется с учетом значения подметрики CodeStyle.

8. Способ по п. 1, характеризующийся тем, что этап определения метрики Solidarity содержит этапы, на которых:

- извлекают настройки helm и название проекта, а также название приложения в репозитории;

- сравнивают название приложения в извлеченных данных и на основе результатов сравнения назначают значение подметрики Gitlab Structure;

причем метрика Solidarity определяется с учетом значения подметрики Gitlab Structure.

9. Способ по п. 1, характеризующийся тем, что метрика Solidarity определяется на основе подметрик GitFlow, Dependencies, CI/CD; Routing, Environments, CODEOWNERS, CodeStyle, Gitlab Structure и коэффициентов значимости каждой подметрики.

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

- извлекают информацию о количестве проведенных юнит-тестов и сквозного тестирования;

- на основе количества тестов определяют для приложения QA-метрику;

- сравнивают значение QA-метрики с допустимыми значениями метрики, причем если значение QA-метрики не соответствует допустимым значениям, то направляют команду для отклонения запроса на внесение изменений, а если значение QA-метрики соответствует допустимым значениям, то выполняют сборку новой версии приложения с внесенными изменениями в релиз.

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

- в процессе работы приложения, размещенного в сервисе приложений, регистрируют события, связанные с работой приложения;

- определяют количество обработанных исключений или необработанных исключений определенного типа за единицу времени;

- определяют отношение количества обработанных исключений или необработанных исключений к количеству событий заданного для них типа за заданное время;

- сравнивают упомянутое отношение с допустимыми значениями;

- определяют, что упомянутое отношение превышает допустимые значения;

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

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