Программные продукты и системы

Введение. Разработка ПО проходит в условиях максимальной автоматизации жизненного цикла, включая проектирование инфраструктуры, написание программного кода, процессы сборки, тестирования, версионирования, достав- ки и развертывания приложений в продуктивных и тестовых средах. Современные подходы к разработке опираются на гибкие методологии Agile, Scrum [1] и DevOps, которые обеспечивают автоматизацию и стандартизацию клю- чевых этапов [2, 3]. Гибкость Agile-подходов  позволяет адаптировать процесс разработки  к постоянно меняющимся условиям и требованиям, а их сочетание с методологией DevOps  и практиками CI/CD способствует повышению управляемости и надежности разработки за счет автоматизации ключевых процессов [4].

Применение подходов CI/CD и построение на их основе конвейеров [5, 6] обеспечивает повторяемость, прозрачность процессов разработки и снижение нагрузки на команду, позволяя существенно сократить время между внесением изменений и их доставкой в рабочую среду. Автоматизация сборки, тестирования  и доставки приводит к уменьшению количества ошибок конфигурации, к повышению надежности и скорости разработки программных продуктов. При этом за счет применения методологий тестирования, анализа ключевых показателей кода и валидации результатов важ- ное значение приобретает контроль качества  и производительности программного кода [7, 8].

В то же время методологии DevOps и практики CI/CD пока применяются ограниченно  в таких специализированных проектах, как разработка приложений для высокопроизводительных вычислений (High-Performance Com- puting, HPC). Это связано с рядом особенностей: небольшие команды, редкие релизы, необходимость кроссплатформенной сборки, развертывание на различных архитектурах (включая суперкомпьютеры), необходимость обеспечения одновременной поддержки библиотек под несколько операционных систем. Тем не менее применение подходов CI/CD может быть эффективно для подобных задач,  поскольку ключевые этапы (сборка на разных целевых платформах и контроль ее воспроизводимости, автоматизация тестирования, оцен- ка качества кода) остаются такими же по общей структуре, что упрощает сопровождение и ус- коряет выпуск новых версий ПО [3, 6].

С учетом описанных характеристик типового проекта в области HPC для его реализации было принято решение применить подход CI/CD и сопутствующие инструменты, которые полностью покрывают необходимый функционал: систему контроля версий, кроссплатформенную сборку кода, контейнерезированную среду для обеспечения изоляции и гибкой конфигурации, автоматизированное тестирование, статический анализ качества и безопасности программного кода, систему хранения артефактов, инструменты сокрытия чувствительных данных [7, 9]. Выбор решений обусловлен необходимостью обеспечить поддержку кроссплатформенной сборки приложений и библиотек для различных архитектур вычислительных систем, поддержкой сборки под операционные системы Windows и Linux. Применение подобных решений также позволяет масштабировать и гибко конфигурировать содержание задач и этапов конвейера без полного перепроектирования, предоставляет механизмы интеграции средств автоматической проверки соответствия требованиям к ПО [9, 10].

В процессе работы создается проект гибкой и масштабируемой архитектуры CI/CD-конвей- ера, адаптированной к автоматизации процессов в области разработки ПО для высокопроизводительных вычислений.

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

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

Архитектура CI/CD-конвейеров  и структура проекта

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

Современные методологии, такие как Git Flow, Trunk-Based Development [13], фреймвор- ки Scrum и Kanban в рамках гибких подходов управления разработкой проектов, а также инструменты Test-Driven Development [14], Code Review, CI/CD, DevOps позволяют формализовать процессы организационного взаимодействия и технической реализации. Жизненный цикл разработки ПО включает в себя следующие этапы: планирование, проектирование, разработка, тестирование, внедрение [15]. Для возможности автоматизации процессов разработки предъявляются специальные требования, лежащие в основе проектирования CI/CD-кон- вейера. Он включает в себя отслеживание  изменений в репозитории проекта, кроссплатформенную сборку, тестирование, анализ кода, управление версионированием и артефактами сборки, публикацию и развертывание, поддержку ветвлением и слиянием.

Процесс проектирования CI/CD-конвейера превращает абстрактную модель разработки  в конкретную техническую архитектуру, реали- зующую автоматизацию и воспроизводимость. Пристальное внимание уделяется особенностям кроссплатформенной сборки для разных операционных систем. Пример спроектированной архитектуры (рис. 1) отражает декомпозицию ключевых этапов разработки и дает возможность точечно определять источники ошибок и оптимизировать процесс. Такая конструкция конвейера позволяет гибко конфигурировать каждую задачу из этапов, например, использование пользовательских образов (Docker) с необходимыми пакетами ПО, что облегчает  и ускоряетсборку. Разработанную модель также можно адаптировать для различных CI/CD-инструментов (GitLab CI, GitHub Actions, Jen- kins), и языков программирования.

При реализации CI/CD-конвейеров необходимо обеспечить безопасную обработку чувствительных данных (пароли, токены, ключи, сертификаты), требующих особого подхода  к хранению и управлению. С этой целью большинство CI-платформ предоставляют встроенные механизмы. Для работы с чувствительными данными подходит, например, инструмент HashiCorp Vault [12], который предлагает централизованное шифрованное хранилище, гибкое разграничение прав доступа, поддержку временных токенов и интеграцию с большинством популярных CI-инструментов.

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

Другим важным аспектом является организация структуры проекта в хранилище репозиториев. При автоматизации сборки и развертывании ПО необходимо организовать структуру хранения конфигурационных файлов. Есть несколько подходов, первый – хранение всех конфигураций внутри основного проекта в отдельной директории , где они разделены  на этапы сборки и развертывания и группированы по средам (dev, stg, prod и пр.). Такой подход прост и удобен при малом числе сред, но усложняет сопровождение при масштабировании из-за дублирования параметров и увеличения сложности структуры проекта. Альтернативой является выделение отдельного проекта для хранения конфигураций развертывания. Второй подход обеспечивает лучшую читаемость, масштабируемость  и возможность централизованного управления общими параметрами, однако требует дополнительных усилий: настройка отдельного конвейера развертывания, передача артефактов  и синхронизация версий. Его применение предпочтительно для крупных систем с большим количеством приложений (например, при микросервисной архитектуре) и с высокими требованиями к стандартизации инфраструктуры.

Реализация и применение CI/CD-конвейера для проекта приложения

На основе архитектуры (рис. 1) на базе GitLab CI был реализован CI/CD-конвейер, выполняющий сборку приложения для прове- дения высокопроизводительных вычислений. В процессе осуществлена реорганизация проекта, предварительно зафиксирован тег ветки до применения изменений, добавлены директории конфигурационных файлов сборки под целевые платформы и ключевой конфигурацион- ный файл конвейера gitlab-ci.yml. Основные конфигурационные файлы конвейера хранятся в отдельном проекте pipelines для удобства их изменений и возможности применения в других проектах. Общая структура проектов в хранилище репозиториев показана на рисунке 2, результат запуска спроектированного конвейера отображен на рисунке 3.

Организация процесса сборки в рамках CI/CD-конвейера требует учета особенностей целевых платформ и воспроизводимости на всех этапах. В проекте реализована сборка приложений под Linux с использованием GCC,  а также кросс-компиляция под Windows с помо- щью MinGW-w64, что позволяет собирать .exe-файлы из Linux-среды. Сборка выполняется  в задачах build:hpc, build:linux, build:windows, build_lib:linux и build_lib:windows с использованием make-файлов, Docker-образов и настроек статической линковки, что минимизирует зависимости и повышает переносимость артефактов. Особое внимание уделено специфике суперкомпьютерной среды: для нее реализован алгоритм сборки и запуска, интегрированный  в задачу build:hpc (рис. 4), которая использует систему управления прохождением параллель- ных задач (СУППЗ) для выполнения програм- мы [16]. В результате формируются артефакты (исполняемые файлы) и библиотеки для Linux и Windows, а также результаты сборки и тести- рования в HPC-среде. Такой подход обеспечивает гибкость, масштабируемость и надежность CI/CD-сборки.

Статический анализ кода – важный элемент обеспечения качества в автоматизированном CI/CD-конвейере. В отличие от динамическоготестирования, он позволяет выявлять ошибки, уязвимости, нарушение стиля и дублирование кода без выполнения программы, что критично при кроссплатформенной разработке. В проекте анализ интегрирован через задачу static_ analysis, использующую sonar-scanner и файл sonar-project.properties [12]. Процесс запускается автоматически при каждом коммите или merge request, а вся среда анализа упакована  в Docker-образ для удобства и воспроизводимости.

Платформа SonarQube обеспечивает визуализацию ключевых метрик (рис. 5): безопасность (Security), надежность (Reliability), под- держиваемость (Maintainability), покрытие кода тестами (Coverage), количество строк нового кода (New Code) и дублирование кода (Dupli- cations), которого обнаружилось всего 0.4 %. Отчеты отображаются в веб-интерфейсе, a Secu- rity Hotspots помогают локализовать потенциальные риски.

Регулярное выполнение статического анализа в рамках автоматизированного процесса сборки является эффективным средством обеспечения качества ПО. В случае разрабатываемого приложения, предназначенного для выполнения в средах высокопроизводительных вычислений, это позволяет заранее исключить ошибки, которые могут проявиться только  в условиях многопроцессорного исполнения или при кросс-компиляции под операционные системы и платформы. Дополнительно данный инструмент можно усилить различными вида- ми тестирования (модульное, системное, интеграционное, регрессионное), их интеграция имеет ряд инфраструктурных и программных особенностей [13–15].

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

Вначале определяется функционал, подлежащий реализации, после чего создается ветка разработки вида dev- , где – числовойидентификатор, номер задачи или хэш коммита. Если над одним функционалом работает несколько разработчиков, каждый из них создает отдельную ветку feature-, в которой ведется разработка отдельных функций. При коммите и отправке изменений в удаленный репозиторий создается тег в формате <текущая версия>-feature-. После завершения разра- ботки в feature-ветках формируются запросы на слияние с веткой dev. Ответственный за разработку feature инициирует проверку кода (code review). После успешного прохождения проверки ветки feature объединяются с веткой dev. По окончании разработки в ветке dev формируется новый тег в формате <текущая версия>.<минорная версия>-dev-, например,из 0.1.0-dev-ids становится 0.2.0-dev-das. Далее разработчик инициирует слияние ветки dev- с основной веткой main и назначает проверяющего. После проверки код объединяется  с main, и создается тег с префиксом -rc (release candidate), например 0.1.0-rc обновляется до 0.2.0-rc. Этот тег фиксируется для последующего использования.

При необходимости релиз-кандидат может быть преобразован в готовый релиз с новым номером версии, например из 0.2.0-rc в 1.0.0. При формировании тегов релиз-кандидатов  и релизов требуется указание списка внесенных изменений. В релизы включаются все артефакты проекта: бинарные файлы, пакеты, документация и образы. В процессе эксплуатации релиза могут выявляться ошибки, которые требуют немедленного исправления. Для этого от ветки main создается ветка hotfix-<текущая версия>, в которой фиксируются ошибки. После  исправления создается тег багфикс с увеличени- ем патч-версии, например 1.1.0 становится 1.1.1.

Для автоматизации данного алгоритма разработано консольное приложение version.py на языке Python. Программа реализует ключевые команды: вывод текущей ветки, коммита и тега, вывод последнего тега проекта, расчет нового тега, проверку необходимости публикации тега, создание релиза и релизной ветки. Приложение поддерживает проекты на платформах GitHub и GitLab. Для работы с GitLab необходимо установить переменные окружения в сек- ретах CI: CI_PROJECT_ID (идентификатор проекта), URL (адрес репозитория) и API_ACCESS_ TOKEN (токен доступа к API). Разработанное приложение может не только использоваться вручную локально, но и интегрироваться  в CI/CD-процессы GitLab CI. После создания тега запускается задача публикации собранного артефакта в объектное хранилище с присвоением соответствующего тега.

Оценка эффективности  применения автоматизации  процессов разработки

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

После внедрения CI/CD-конвейера общее время от коммита до получения готового исполняемого артефакта значительно сократилось по сравнению с ручным циклом, уско- рился процесс проверки изменений. Использование контейнеризированных сборочных сред (Docker) и автоматизированного управления зависимостями позволило устранить влияние различий в окружениях и обеспечить высокую воспроизводимость сборок как для Linux, так  и для Windows, а также сборку и тестирование на суперкомпьютере, которые раньше полностью выполнялись вручную.

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

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

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

Заключение

Результатом работы является спроектированный и реализованный прототип CI/CD-конвейера, направленный на автоматизацию этапов разработки ПО с использованием методологии DevOps и подходов CI/CD. Особое внимание было уделено поддержке разработки ПО на языке С++ для приложений высокопроизводительных вычислений с возможностью кроссплатформенной сборки и удаленному автоматическому тестированию на суперкомпьютере с использованием СУППЗ.

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

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

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

Список литературы

1.     Алексеев А.Л. Эволюция и анализ моделей жизненного цикла разработки программного обеспечения // Вестн. науки. 2024. Т. 4. № 7. С. 239–242.

2.     Глазунова Е.З., Андирякова О.О., Сафиуллин Д.Ф. Особенности использования гибких методов разработки проектов // Индустриальная экономика. 2022. Т. 6. № 5. С. 541–546.

3.     Лотов К.А., Андиева Е.Ю. Эволюция DevOps: роль CI/CD в ускорении цикла разработки программного обеспечения // Вестн. науки. 2025. Т. 4. № 4. С. 683–688.

4.     Forsgren N., Humble J., Kim G. Accelerate: The science of lean software and DevOps: building and scaling high performing technology organizations. Portland, 2018, 288 p.

5.     Deepak P., Tiwari N., Sharma A., Verma S. EduDevOps: The ultimate CI/CD corporate DevOps pipeline project. IJSREM, 2025, vol. 09, no. 05, pp. 1–5. doi: 10.55041/IJSREM47302.

6.     Дьяченко Н.И., Забродин А.В. Автоматическая генерация пайплайнов CI/CD на основе метаданных проекта: новый подход к ускорению разработки программного обеспечения // Интеллектуальные технологии на транспорте. 2025. № 1. С. 74–82. doi: 10.20295/2413-2527-2025-141-74-82.

7.     Alamin Z., Dahlan, Khaeruddin, Ramadhan S. Evolving DevOps practices in modern software engineering: Trends, challenges, and impacts on quality and delivery performance. Journix: J. of Informatics and Computing, 2025, vol. 1,  no. 1, pp. 21–29. doi: 10.63866/journix.v1i1.4.

8.     Sánchez J.-M., Mayo D.F.J., Oriol X., Crespo J.F., Benavides D., Teniente E. A performance evaluation model for DevOps practices on open source software projects. 2023, 22 p. URL: https://ssrn.com/abstract=4605131 (дата обращения: 19.12.2024). doi: 10.2139/ssrn.4605131.

9.     Gouni R. Automating compliance in DevOps pipelines. IJCESEN, 2025, vol. 11, no. 2, pp. 2078–2091.  doi: 10.22399/ijcesen.991.

10.  Garg N. Optimizing DevOps for critical systems. Asian J. of Research in Comput. Sci., 2025, vol. 18, no. 5,  pp. 544–553. doi: 10.9734/ajrcos/2025/v18i5673.

11.  Rangineni S., Bhardwaj A.K. Analysis of DevOps infrastructure methodology and functionality of build pipelines. EAI Endorsed Transactions on Scalable Information Systems, 2024, vol. 11, no. 4. doi: 10.4108/eetsis.4977.

12.  Fakokunde A., Kolawole I. Improving software development with continuous integration and deployment for agile DevOps in engineering practices. Int. J. of Comput. Applications Technology and Research, 2024, vol. 14, no. 01, pp. 25–39. doi: 10.7753/IJCATR1401.1002.

13.  Jia Yi T., Ripin Z.M., Ridzwan M.I.Z. et al. Development and validation of an automated Trunk Impairment Scale 2.0 scoring system using rule-based classification. The J. of Engineering in Medicine, 2025, vol. 239, no. 2, pp. 212–226. doi: 10.1177/09544119251317614.

14.  Liu X., Sun X., Bo L., Ye, Z. et al. Evaluating the test adequacy of benchmarks for LLMs on code generation. J.  of Software: Evolution and Process, 2025, vol. 37, no. 7, art. e70034. doi: 10.1002/smr.70034.

15.  Thant K.S., Tin H.H.K. The impact of manual and automatic testing on software testing efficiency and effectiveness. IJSR, 2023, vol. 3, no. 3, pp. 88–93.

16.  Баранов А.В., Киселёв Е.А Интеграция систем управления заданиями SLURM и СУППЗ // Тр. НИИСИ РАН. 2019. Т. 9. № 5. С. 29–35. doi: 10.25682/NIISI.2019.5.0004.

References 

1. Alekseev, A.L. (2024) ‘Evolution and analysis of software development lifecycle models’, Vestnik Nauki, 4(7), pp. 239–242 (in Russ.).
2. Glazunova, E.Z., Andiryakova, O.O., Safiullin, D.F. (2022) ‘Features of using agile project development’, Industrial Economy, 6(5), pp. 541–546 (in Russ.).
3. Lotov, K.A., Andieva, E.Yu. (2025) ‘Evolution of DevOps: the role of CI/CD in accelerating the software development cycle’, Vestnik Nauki, 4(4), pp. 683–688 (in Russ.).
4. Forsgren, N., Humble, J., Kim, G. (2018) Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. Portland, 288 p.
5. Deepak, P., Tiwari, N., Sharma, A., Verma, S. (2025) ‘EduDevOps: The ultimate CI/CD corporate DevOps pipeline project’, IJSREM, 09(05), pp. 1–5. doi: 10.55041/IJSREM47302.
6. Dyachenko, N.I., Zabrodin, A.V. (2025) ‘Automatic generation of CI/CD pipelines based on project metadata: a new approach to accelerating software development’, Intelligent Technologies in Transport, (1), pp. 74–82 (in Russ.). doi: 10.20295/2413-2527-2025-141-74-82.
7. Alamin, Z., Dahlan, Khaeruddin, Ramadhan, S. (2025) ‘Evolving DevOps Practices in modern software engineering: Trends, challenges, and impacts on quality and delivery performance’, Journix: J. of Informatics and Computing, 1(1), pp. 21–29. doi: 10.63866/journix.v1i1.4.
8. Sánchez, J.-M., Mayo, D.F.J., Oriol, X., Crespo, J.F., Benavides, D., Teniente, E. (2023) ‘A performance evaluation model for DevOps practices on open source software projects’, 22 p., available at: https://ssrn.com/abstract=4605131 (acecessed December 19, 2024). doi: 10.2139/ssrn.4605131.
9. Gouni, R. (2025) ‘Automating compliance in DevOps pipelines’, IJCESEN, 11(2), pp. 2078–2091. doi: 10.22399/ijcesen.991.
10. Garg, N. (2025) ‘Optimizing DevOps for critical systems’, Asian J. of Research in Comput. Sci., 18(5), pp. 544–553. doi: 10.9734/ajrcos/2025/v18i5673.
11. Rangineni, S., Bhardwaj, A.K. (2024) ‘Analysis of DevOps infrastructure methodology and functionality of build pipelines’, EAI Endorsed Transactions on Scalable Information Systems, 11(4). doi: 10.4108/eetsis.4977.
12. Fakokunde, A., Kolawole, I. (2024) ‘Improving software development with continuous integration and deployment for agile DevOps in engineering practices’, Int. J. of Comput. Applications Technology and Research, 14(01), pp. 25–39. doi: 10.7753/IJCATR1401.1002.
13. Jia, Yi T., Ripin, Z.M., Ridzwan, M.I.Z. et al. (2025) ‘Development and validation of an automated Trunk Impairment Scale 2.0 scoring system using rule-based classification’, The J. of Engineering in Medicine, 239(2), pp. 212–226. doi: 10.1177/09544119251317614.
14. Liu, X., Sun, X., Bo, L., Ye, Z. (2025) ‘Evaluating the test adequacy of benchmarks for LLMs on code generation’. J. of Software: Evolution and Process, 37(7), art. e70034. doi: 10.1002/smr.70034.
15. Thant, K.S., Tin, H.H.K. (2023) ‘The impact of manual and automatic testing on software testing efficiency and effectiveness’, IJSR, 3(3), pp. 88–93.
16. Baranov, A.V., Kiselev, E.A. (2019) ‘Integration of job management systems SLURM and SUPPZ’, Proc. of SRISA RAS, 9(5), pp. 29–35 (in Russ.). doi: 10.25682/NIISI.2019.5.0004.