Морозов А.О.
ПРИМЕНЕНИЕ НЕПРЕРЫВНОЙ ИНТЕГРАЦИИ И ДОСТАВКИ В ХОДЕ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ СИСТЕМ АВТОМАТИЧЕСКОГО УПРАВЛЕНИЯ ТЕХНОЛОГИЧЕСКИМИ ПРОЦЕССАМИ *
Аннотация:
в данной статье рассматривается вопрос применения непрерывной интеграции в процессе разработки программного обеспечения для систем автоматизированного управления технологическими процессами. Поднимаются проблемы, которыми обладает данный тип программ. Далее в целях демонстрации принципов построения данной системы проектируется инфраструктура непрерывной интеграции и непрерывной доставки, в которой дополнительно приводятся примеры готовых программных решений, используемых в подобных инфраструктурах. В завершении статьи приведены метрики, которые используются анализа качества системы
Ключевые слова:
информационная безопасность, непрерывная интеграция, непрерывная доставка
Проблемы ПО АСУ ТП. Программное обеспечение автоматизированной системы управления технологическими процессами (ПО АСУ ТП) – крайне важная область информатики. В XXI веке она играет ключевую роль в автоматизации технологических процессов на производствах, обеспечивая непрерывный рост темпов выпуска той или иной продукции, и именно благодаря ей современный потребитель имеет такой богаты выбор различных товаров: от пластиковых игрушек, до графических адаптеров для персональных компьютеров. Однако ПО АСУ ТП, как программный продукт, имеет ряд характерных проблем:– Проблема безопасности. В век развития информационных технологий, кибер-атаки становятся всё изощрённее с каждым годом, а борьба с ними всё труднее. ПО АСУ ТП - крайне уязвимый тип программ, цена дыры в защите которого может иметь очень высокую цену: любой сбой грозит нарушением или остановкой работы предприятия, или, что ещё хуже, повреждением стратегические важной инфраструктуры. Многие решают эту проблему крипто-шифрованием, но оно потребляет лишние ресурсы вычислительной техники, что сказывается на быстродействии и КПД системы. [1]– "Баги". Ошибки в исходном коде программ для ПО АСУ ТП - не редкость. Та или иная часть программного кода может функционировать не так как задумано, с меньшей эффективностью, чем могла бы, или просто не работать из-за простой ошибки невысвобожденной памяти. Любой разработчик — это, в первую очередь человек, а человеку свойственно ошибаться [2]– Несоответствие стандартам. Поскольку ПО АСУ ТП читается и анализируется большим количеством людей, то встаёт вопрос соответствия стандартам. Если каждый разработчик будет программировать в "уникальном", удобном ему одному стиле, то данный продукт будет крайне тяжело поддерживать: любой другой, кто возьмётся за работу с данным кодом, будет вынужден тратить время на то, чтобы разобраться в манере написания кода. Отсутствие единого подхода к разработке усложнит анализ качества кода (или "код ревью") и поиск вышеупомятуных "багов", что скажется на скорости выхода продукта [3],– Трата времени на анализ качества кода. К сожалению классический подход к разработке ПО АСУ ТП в виде "код ревью" отнимает крайне много времени и замедляет разработку: разработчики вынуждены брать паузу и демонстрировать свои наработки ведущим специалистам в то время, как они могли в это время продолжать работать. При этом, без анализа не обойтись: иначе как можно быть уверенным в работоспособности программы [4]– Отсутствие автоматического тестирования. Для проверки функциональности программы разработчики ПО АСУ ТП создают отдельные программы, обращающиеся к небольшим частям исходного кода, проверяя их функциональность - тесты. Однако зачастую запуск тестов разработчики вынуждены делать вручную, что, как и в случае с «код ревью» замедляет разработку [5]- Отсутствие автоматического развёртывания изменений. Любые изменения, которые сделал разработчик, вручную доставляются в рабочее окружение: разработчик вручную должен подключиться к цеховой среде, остановить работающие программы и загрузить обновления. Данный подход малоэффективен, т.к. отнимает время и связан с риском допустить ошибки [6]Непрерывная интеграция и доставка - как подход к решению основных проблем. Решить все вышеупомянутые проблемы поможет непрерывная интеграция и непрерывная доставка - система, известная в западной IT-индустрии, как «CI/CD», что можно перевести как как непрерывная интеграция и непрерывная доставка (continuous integration / continuous delivery). «CI/CD» — это спектр практик, направленный на автоматизацию ряда процессов, требуемых при разработке, что значительно повышает качество продукта и скорость выпуска обновлений, связанных с новым функционалом и безопасностью. В основе непрерывной интеграции и доставки лежит система контроля версий (СКВ), выступающая в роли хранилища актуальной версии кода программы. Разработчик отправляет в СКВ изменения, сделанные локально на его устройстве, где они при помощи алгоритмов слияния объединяются с изменениями, сделанными другими разработчикамиПри получении изменений СКВ запускает конвейер - последовательность программных операций, направленных на анализ полученных изменений. В ходе данных операций весь код программного продукта при помощи специального агента будет разворачивается либо в изолированном программном контейнере, либо в оболочке операционной системы, где далее анализируется различными программными средствами:– Средствами для статического анализа, которое проверяет исходный код на наличие уязвимостей и ошибок,– Средствами для композиционного анализа, которое проверяет, не находятся ли используемые приложением библиотеки и модули в реестре уязвимых программных компонент,– Средствами для динамического анализа, которые запускают программу и оценивают её безопасность через доступный пользователю функционал,– Средствами для синтаксического анализа, которые проверяют исходный код на соответствие стандартам в синтаксисе того или иного языка,– Средствами для автоматического тестирования, которые самостоятельно запускают написанные разработчиками тесты,– Средствами для поиска "секретов" - нескрытых паролей или токенов.По окончании работы конвейер формирует набор отчётов, которые содержат подробные сведения о найденных уязвимостях, а также стилистических и синтаксических ошибках. Данные отчёты будут доступны разработчикам для просмотра в виде статических веб-страниц, и будут храниться на отдельном защищенном сервере. Таким образом складывается процесс непрерывной интеграции.Процесс непрерывного развёртывания также подразумевает под собой автоматизацию. Как только качество программного кода будет удовлетворять требованиям, выдвигаемым разработчиками к своему продукту, лидер команды разработки может одним нажатием кнопки мыши отправить изменения в рабочее окружение, где продукт будет функционировать. Данные системы показывают крайнюю эффективность и постепенно внедряются в процесс разработки любого программного обеспечения [7].Как следствие, данная система решает все проблемы, которыми обладает ПО АСУ ТП: статический, динамический и композиционный анализ решают вопросы безопасности и поиска "багов", синтаксический анализатор кода поможет решить проблему соответствия стандартам, а также вовсе избавиться от процесса "код ревью", а автоматический запуск тестов избавит разработчиков от необходимости запускать их вручную. Пример создания инфраструктуры непрерывной интеграции и доставки. Для внедрения системы непрерывной интеграции и доставки на предприятие требуется настроенная защищенная локальная сеть между разработчиками. Одним из узлов данной сети будет сервер непрерывной интеграции и доставки. Данный сервер будет принимать запросы, связанные непосредственно с непрерывной интеграцией и распределять их между виртуальными машинами. В качестве операционной системы подойдёт «Linux Ubuntu», т.к. она является наиболее универсальной и обладает обширной документацией. В качестве гипервизора для виртуальных машин (ВМ) будет использоваться «QEMU/KVM» - доступная для данного дистрибутива по умолчанию. Всего в кластере будет задействовано четыре виртуальные машины:1. Первая ВМ будет содержать систему контроля версий и иметь выход в локальную сеть предприятия. В качестве системы контроля версий будет использоваться «GitLab». Кроме того, именно с данной ВМ изменения могут быть отправлены напрямую в рабочее окружение, если заказчика устроит готовый продукт.2. Вторая ВМ будет являться средой для работы «Docker»-контейнеров, в которых будет выполняться анализ кода. При отправке команды с СКВ агент будет запускать контейнеры и разворачивать в них программный код для анализа. Образы контейнеров будут созданы заранее и будут храниться на данной ВМ. Каждый образ будет содержать, по два программных средства на каждый вид анализа, чтобы обеспечить максимальную точность анализа. Контейнеры для статического анализа будут использовать «SonarCube» и «Semgrep», контейнеры для динамического анализа - «АК-ВС-3» и «PT Application Inspector», контейнеры для композиционного анализа «Dependency check» и «Trivy», средство, которое используют контейнеры для тестов будет зависеть от используемого языка – например, для языка Python подойдёт «Pytest», для C# «MSTest» и т.д., Контейнеры для поиска секретов: «Trivy», «Semgerp». Важно отметить, что некоторые средства подходят могут специализироваться более чем на одном виде анализа: к примеру «Trivy» может выполнять как композиционный анализ, так и поиск секретов.По окончании анализа агент будет отправлять в СКВ сообщения об успешном/неуспешном прохождении того или иного этапа конвейера, а после отправлять подробный отчет анализа на отдельный веб-сервер на соседней ВМ и в "архив".3. Третья ВМ - веб сервер. На данный сервер будут отправляться отчёты выполненных анализов. Ссылка для просмотра отчётов будет отправляться в СКВ, чтобы разработчики могли быть в курсе выявленных уязвимостей. В качестве веб сервера можно выбрать «NGINX», который можно дополнительно использовать как балансировщик сетевой нагрузки, что только положительно скажется на быстродействии системы.4. Четвёртая ВМ - "Архив". Данная ВМ будет представлять собой пустую оболочку операционной системы, на которой будут храниться копии всех проектов, участвующих в разработке, а также отчёты всех анализов программы. Данная ВМ может использовать вспомогательные средства для создания резервных копий (например, «Ru-Backup»).5. Пятая ВМ будет использоваться как тестовое окружение для проверки работоспособности программы. Здесь будет эмулироваться среда предприятия, в которую данная программа может быть безопасно интегрирована для сбора метрикДанная модель инфраструктуры может быть дополнительно скорректирована для нужд того или иного предприятия. Однако представленные выше структурные единицы системы являются универсальными для систем подобного типаОценка эффективности работы программ. Для оценки эффективности процесса непрерывной интеграции и развёртывания могут использоваться показатели DORA (DevOps Research and Assessment):- Частота развёртывания - насколько регулярно выпускались обновления,- Время цикла - сколько уходит времени с момента отправки изменений в СКВ до доставки их на рабочий сервер,- Процент отказов изменений — доля изменений, которые приводят к сбою или исправлению,- Среднее время восстановления после сбоев. Данные метрики могут собираться как в ходе проверки программы в тестовом окружении, так и в ходе её работы на предприятииЗаключение. Таким образом, системы непрерывной интеграции и развёртывания являются перспективным программным решением, внедрение которого может значительно ускорить процесс разработки, снизить количество ошибок и уязвимостей, что положительно скажется на доходах того или иного предприятия.
Номер журнала Вестник науки №12 (93) том 3
Ссылка для цитирования:
Морозов А.О. ПРИМЕНЕНИЕ НЕПРЕРЫВНОЙ ИНТЕГРАЦИИ И ДОСТАВКИ В ХОДЕ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ СИСТЕМ АВТОМАТИЧЕСКОГО УПРАВЛЕНИЯ ТЕХНОЛОГИЧЕСКИМИ ПРОЦЕССАМИ // Вестник науки №12 (93) том 3. С. 1341 - 1349. 2025 г. ISSN 2712-8849 // Электронный ресурс: https://www.вестник-науки.рф/article/27650 (дата обращения: 09.02.2026 г.)
Вестник науки © 2025. 16+