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, и в нем есть приводы, мы можем перемещать сиденья». Вам не нужно быть ученым-ракетостроителем, чтобы стать инженером-испытателем, но довольно забавно быть инженером-испытателем, который работает с настоящими физическими ракетами.

---

• Первая в России серийная система управления двухтопливным двигателем с функциональным разделением контроллеров
• В современном автомобиле строк кода больше чем…
• Бесплатные онлайн-курсы по Automotive, Aerospace, робототехнике и инженерии (50+)
• McKinsey: переосмысляем софт и архитектуру электроники в automotive