Об изменениях в процессе доставки геометрического ядра C3D18.09.2024 12:16

Анна Ладилова, руководитель команды DevOps в C3D Labs, раскрывает причины возрастающей роли Linux в разработке, описывает связанные с этим изменения, которые происходят в процессе доставки ядра C3D, а также делится планами дальнейшего развития.

В 2022 году компания C3D Labs начала собирать геометрическое ядро C3D на базе платформы «Эльбрус».

В том же году мы сообщили, что наше ядро работает на Astra Linux, причем не только ядро, но и все компоненты C3D Toolkit.

В 2023 году была выполнена сборка, портирование на архитектуру e2k, проведены тесты, и сегодня мы с уверенностью заявляем, что геометрическое ядро C3D успешно работает на платформе «Эльбрус». Если в процессе возникали вопросы и ошибки, мы их исправляли.

Когда мы решали эти задачи, оценивая работоспособность ядра C3D на базе «Эльбруса» и отечественной операционной системы Astra Linux, обнаружился ряд сложностей.

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

Одновременно с этим роль Linux, несомненно, росла — об этом свидетельствовало увеличение числа поступающих к нам запросов.

Причем это касалось не только Astra Linux, но и DBN, Ubuntu и других дистрибутивов. Помимо того, что в целом интерес к Linux-решениям растет, важную роль играет то, что создатели системы проектирования «КОМПАС-3D» начали разработку Linux-версии. Все эти факторы в совокупности убедили нас в том, что мы обязаны, во-первых, поддерживать Linux, а во-вторых, обеспечивать качество нашего продукта на уровне, не уступающем Windows-решениям.

Какие действия мы предприняли, чтобы поправить эту ситуацию и решить задачи, которые перед нами встали? В 2022 году мы заменили систему управления версиями. Ранее разработка велась на основе системы управления версиями SVN. Как мы работали?

Фактически у нас была только одна ветка, в которую мы сдавали все изменения. Также существовал ряд ограничений. Несколько раз в день, то есть раз в несколько часов, мы запускали прогон «быстрых» тестов, а кроме того, каждую ночь производилось полное регрессионное тестирование по всей нашей базе. В чем было неудобство? В том, что единственное, что мы могли сделать при возникновении ошибок, это отменить коммит, который вызывал эти ошибки. Других вариантов реакции на ошибки не было.

Как следствие, эти аспекты замедляли процесс доставки. Но при этом неоспоримым было одно большое преимущество — всё исправно работало по схеме, отработанной десятилетиями. Однако недостатки были очевидны: долгий процесс доставки, линейная работа с единственной веткой. Плюс ко всему, система SVN морально устарела, мы были намерены развиваться, перерастать ее и, как результат, перешли на систему управления версиями Git.

Как происходил процесс перехода? На самом деле, он продолжается до сих пор.

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

Отдельного внимания заслуживает еще одна новинка, которая ознаменовала собой 2023 год. Мы внедрили менеджер управления зависимостями Conan.

Что это такое и для чего это нужно? При разработке часто случается, что нам нужно пользоваться какими-то дополнительными решениями, каким-то дополнительным софтом. Conan позволяет автоматически «подтягивать» эти зависимости. При этом есть возможность выбрать нужные операционную систему, компилятор, версию пакета, конфигурацию. Все задачи решаются автоматически: не нужно скачивать что-либо вручную. К тому же в Conan существует репозиторий готовых пакетов, причем внушительный. В нем имеется, наверное, все возможное «свободное» ПО, и даже если каких-то конфигураций нет, их можно скомпилировать из исходных кодов. Важное преимущество заключалось в том, что Conan — это кроссплатформенное решение, и менеджер легко интегрируется с другими инструментами сборки. Немаловажно и то, что его достаточно просто использовать: порог вхождения — низкий.

Исходя из того что в процессах сборки мы всегда использовали систему CMake, внедрение Conan стало следующим закономерным шагом.

Из Conan мы вызываем CMake, а потому нам мало что пришлось изменять в текущих процессах. Для себя мы упростили процесс «подтягивания» зависимостей, и это позволило пользоваться этим инструментом для того, чтобы эффективно «подтягивать» новые зависимости. Кроме того, мы создали собственный Conan-репозиторий, из которого можно получить наше ядро в тех же самых конфигурациях, как это сейчас реализовано через веб-сайт. Адрес репозитория — https://gitlab.c3d.ascon.ru: мы готовы предоставить ключ для использования всем желающим.

Стоит детальнее описать процесс тестирования, того, как мы обеспечиваем качество нашего продукта.

Как было упомянуто, действовали схема, отработанная годами, и наша собственная система тестирования. Что она собой представляла? Это было Windows-приложение, система работала только c Windows. Мы не могли тестировать наш продукт в связке с другими операционными системами. В этом едином монолитном приложении все параметры, включая точность тестирования, были «зашиты» в исходный код. Результат тестирования также предоставлялся в виде бинарного файла, который мы могли прочитать и проанализировать только с помощью этого же приложения. Обвязка нашего тестового приложения была представлена в виде двух десятков скриптов. Сложности возникали и с эталонными результатами, потому что при необходимости перезаписать их можно было только блоком. Не было возможности заменять эталоны для отдельных входных данных.

Что мы сделали?

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

В обновленной системе тестирования мы реализовали все замыслы.

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

Самое главное, чего мы достигли, — это тестирование сборок в Linux на постоянной основе. На сегодняшний день мы можем заявить, что качество продукта C3D в Linux мы отслеживаем и стараемся, чтобы оно не уступало качеству Windows-решения. Вместе с тем этот процесс все еще продолжается.

C3D Labs планирует развивать собственную систему тестирования, а именно расширять направления, увеличивать количество тестов. Также мы продолжаем совершенствовать процесс доставки. Остается некоторая проблема с ускорением, со скоростью доставки, но мы над этим работаем. Еще одна сложность состоит в том, что большинство наших разработчиков работают на Windows, тем не менее нам надо адаптироваться в Linux и при возникновении ошибок исправлять их. Именно сейчас мы занимаемся внедрением практик по работе с Linux-системами на рабочих местах. Таковы планы на ближайший год.

© Habrahabr.ru