image

Stack Overflow побеседовал с Эрин Ишимотича, инженером в группе Software Delivery Engineering из Чокто Нейшн в Оклахоме. Ишимотича, работающая инженером на постоянной основе уже 15 лет, начала свою карьеру с написания скриптов shell и Perl, а в SpaceX работает уже около двух лет.

Проверять, проверять и еще раз проверять


Работа отдела Software Delivery Engineering, по словам Ишимотича, заключается в координации надлежащей практики разработки и тестирования программного обеспечения в компании SpaceX, обеспечивая, чтобы все, кто пишет код для космических аппаратов, использовали надлежащие методы контроля версий и проходили автоматизированное и человеческое тестирование, управляемое системой непрерывной интеграции (CI).

«Мы разрабатываем и поддерживаем нашу собственную систему CI», — сказала она. «У нас есть веб-служба, которая создает отчеты — она получает телеметрию от тестов программного и аппаратного обеспечения, строит графики и имеет свои собственные утверждения, которые она выполняет на основе данных, создавая отчет о том, как работает программное обеспечение».


Это означает, что специалисты из Software Delivery Engineering занимаются разработкой, тестированием и DevOps, в команде около 15 инженеров, включая специальную команду Software Reliability Engineering (SRE).

Контроль качества программного обеспечения для космических аппаратов отличается от обычных корпоративных или потребительских приложений. Требования к нему довольно высоки. «Вы можете посмотреть на классификацию программного обеспечения NASA — об этом есть много общедоступной информации. Мы делаем нечто подобное. Существует несколько различных стандартов качества, которые применяются к программному обеспечению, начиная от инструментов CI и заканчивая летным программным обеспечением, которое обеспечивает критически важные функции безопасности для экипажа».

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

Прикрываем друг друга


Процесс разработки, по-видимому, это agile, с проектированием на основе тестирования и несколькими инженерами, постепенно вносящими изменения в код.

«Большую часть времени мы работаем с концепцией ответственного инженера, который берет тикет — проблему — из бэклога». Затем ответственный инженер работает над проблемой, начиная с понимания сути проблемы и доводя ее до конца, возможно, даже развертывая новое программное обеспечение.

«Если я беру тикет, я сначала изучаю проблему и пытаюсь ее воспроизвести. Затем я разрабатываю исправление или функцию, реализующую исправление, обеспечиваю покрытие тестами и функциональное тестирование в изолированной среде. Затем я делаю пул реквест на это исправление. Это моя обязанность — найти того, кто рассмотрит ПР».


Процесс не является законченным, когда ревью завершено. «Когда PR сливается, я отвечаю за то, чтобы следующий тест на мастере прошел в CI. А затем мы приступаем к верификации».

Среда CI основана на [HT Condor], системе управления рабочей нагрузкой для интенсивных вычислений, которая возникла в High Throughput Computing Group Висконсинского университета в Мэдисоне. Эта система ценится в SpaceX за ее мощные возможности управления очередями, приоритетами заданий и ресурсами — особенно для испытательных стендов HITL (Hardware-in-the-loop, подробнее о них позже).

Condor управляет рабочими нагрузками аналогично традиционной пакетной системе, но может лучше использовать незадействованные ресурсы компьютера. По словам Ишимотича, «мы выполняем около миллиона сборок CI в месяц».

Управление сборками и ракеты на столе


Платформа построена на PostgreSQL для управления метаданными о сборках, результатах тестирования и других артефактах, наряду с большим количеством Python и C/C++.

Python используется для запуска бэкенд-тестов, организации сборок, а также все наши веб-серверы основаны на Python. Это множество маленьких скриптов и множество больших веб-сервисов. Angular и JavaScript на веб-сервисах для фронтэнда, и немного Typescript, который очень хорош, я его большой поклонник.

Широко используется Docker, а также немного Kubernetes. «Docker часто используется для эфемерных сборок». Используя Docker, можно гарантировать, что каждая сборка выполняется в чистой среде. «Возможность поместить эти задания в Docker означает, что мы можем каждый раз отбрасывать побочные эффекты, что просто замечательно».

Мы поинтересовались, как в Software Delivery Engineering работают с оборудованием. «Мы не так часто работаем с оборудованием транспорта, как с оборудованием центров обработки данных», — сказал Ишимотича. «Мы постоянно перестраиваем рабочие системы и добавляем оборудование в систему CI. У нас около 550 малых, средних и больших воркеров, выполняющих различные виды работ. Маленький воркер имеет два ядра, а наши большие воркеры имеют 28 ядер и 32 гигабайта памяти».

Есть одна классная часть работы, которая связана с игрой на реальном оборудовании. «У нас также есть тонна испытательных стендов, подключенных к системе CI. Мы называем эти тесты HITLs, произносится „хиттлз“, что означает „аппаратное обеспечение в цикле“. Это единичные, сделанные на заказ, буквально все внутренности ракеты разложены на столе. У нее нет ни топливных баков, ни двигателей, но есть все бортовые компьютеры и датчики». Она рассмеялась. «У нас есть один для сидений на Dragon 2, и в нем есть приводы, мы можем перемещать сиденья». Вам не нужно быть ученым-ракетостроителем, чтобы стать инженером-испытателем, но довольно забавно быть инженером-испытателем, который работает с настоящими физическими ракетами.




image

Вакансии
НПП ИТЭЛМА всегда рада молодым специалистам, выпускникам автомобильных, технических вузов, а также физико-математических факультетов любых других высших учебных заведений.

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

В компании организован специальный испытательный центр, дающий возможность проводить исследования в области управления ДВС, в том числе и в составе автомобиля. Испытательная лаборатория включает моторные боксы, барабанные стенды, температурную и климатическую установки, вибрационный стенд, камеру соляного тумана, рентгеновскую установку и другое специализированное оборудование.

Если вам интересно попробовать свои силы в решении тех задач, которые у нас есть, пишите в личку.



О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.

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

Комментарии (3)


  1. anonymous
    00.00.0000 00:00


  1. amarao
    28.08.2021 14:41
    +6

    строит графики и имеет свои собственные утверждения,

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

    Алсо, пост-merge CI - совершенно нормальная практика для больших проектов. В самых больших проектах (например, openstack), есть даже отдельный робот, который следит за порядком применения MR, и проверяет, что тесты проходят после MR (до принятия MR!).


    1. saboteur_kiev
      29.08.2021 01:12

      а в транк-флоу вообще мерж в мастер идет после деплоя в продакшен =)