Комментарий команды R&D компании РОСА к проекту создания прототипов систем для Национальной программной платформы.
Многие интересуются, с чем мы пойдем на сдачу и показывают на старые сборочные инструменты Мандривы. На самом деле, выигрыш ПингВином первого этапа НПП и, как следствие, пришедшая в R&D РОСы задача по предоставлению системы сборки дают нашей скромной команде повод продемонстрировать публике развиваемый в РОСе/Mandriva внутренний проект универсального билд-сервера ABF.
Этот проект мы начали в России для реализации нашей давней идеи автоматизированного согласования зависимостей при пересборке пакетов. А именно, ABF работает так, что новые пакеты не проходят апрув (и не попадают в репозитории) пока не достигнута пересборка всех зависимых от них. Процедура согласованной пересборки позволяет в т.ч. обрабатывать кольцевые зависимости. Как результат – один раз достигнутые корректность и воспроизводимость сборки набора пакетов (а значит – дистрибутивов и любых программ для них) далее не нарушаются неосторожными действиями майнтейнеров (с чем идеологам ABF приходилось в своей предыдущей жизни часто сталкиваться при построении производных Федоры, а позднее и самой Мандривы). Если майнтейнер предлагает некачественный пакет, он немедленно и автоматически получит его обратно с указанием переделать.
На взгляд системных архитекторов РОСы/Mandriva, continuous integration при построении дистрибутивов – это не сколько сам факт ежедневных сборок из пакетов разной степени свежести, как часто бывает, но в гораздо большей степени – уверенность билд-менеджера в том, что все пакеты в образе собраны без конфликтов друг с другом, и проверять это нужно в целом, а не только набором локально применяемых тестов. Нам кажется странной ситуация, когда нарушение пакетом сборки других пакетов обнаруживается в значительной степени случайно, вручную и запросы на пересборку размещаются вручную же в списке рассылки без гарантии какой-либо реакции. Это – прошлый век.
Конструктивно ABF представляет собой расширяемое распределенное множество билд-клиентов (для разных платформ и архитектур), работающих с единым хранилищем кода и управляемых из единого диспетчера-балансировщика. Уже сейчас есть билд-клиенты для Mandriva и для ряда RH-производных, то есть единообразно собираются различные дистрибутивы. От приходящего в эту инфраструктуру разработчика платформы/дистрибутива требуется создать на основе нашего шаблона собственный сборочный бэкенд (используя фрагменты скриптов оригинальной процедуры сборки) и импортировать исходные коды в хранилище. То есть, собрать любой RPM-based дистрибутив – это дело техники. С Debian-based дистрибутивами создание бэкендов несколько сложнее, но достижимо и уже запланировано. А уж создание производных дистрибутивов и сборка одного приложения для нескольких платформ – все это перестает быть хоть сколько-нибудь сложным.
Повторю, речь идет о давно задуманных и развиваемых в РОСе технологиях, причем изначально развиваемых для внутренних нужд. Сдавать эти технологии наружу мы не стремились, специально для конкурса не готовили (и в процессе подготовки прототипов приходится срочно адаптировать код под некоторые требования), к тому же бюджет заявки от ПингВин не покроет даже наших собственных, уже понесенных, расходов на разработку этих технологий. Тем не менее, если ставить вопрос о технических альтернативах в данном контракте, мы считаем наши технологии вполне достойными участия и, что важно, достаточно современными (см. выше). Уровень, на который мы претендуем – это уровень Launchpad и OBS.
Вопрос о том, в каком режиме вести проект после сдачи для нас остается открытым. Безусловно, мы заинтересованы развивать его и приглашать дистрибутивные команды, особенно работающие с Debian-дистрибутивами, производными Мандривы (особенно будем рады глубокоуважаемой команде EduMandriva), а также собирающие дистрибутивы на других аппаратных архитектурах.
Евгений Соколов
ROSA R&D
Многие интересуются, с чем мы пойдем на сдачу и показывают на старые сборочные инструменты Мандривы. На самом деле, выигрыш ПингВином первого этапа НПП и, как следствие, пришедшая в R&D РОСы задача по предоставлению системы сборки дают нашей скромной команде повод продемонстрировать публике развиваемый в РОСе/Mandriva внутренний проект универсального билд-сервера ABF.
Этот проект мы начали в России для реализации нашей давней идеи автоматизированного согласования зависимостей при пересборке пакетов. А именно, ABF работает так, что новые пакеты не проходят апрув (и не попадают в репозитории) пока не достигнута пересборка всех зависимых от них. Процедура согласованной пересборки позволяет в т.ч. обрабатывать кольцевые зависимости. Как результат – один раз достигнутые корректность и воспроизводимость сборки набора пакетов (а значит – дистрибутивов и любых программ для них) далее не нарушаются неосторожными действиями майнтейнеров (с чем идеологам ABF приходилось в своей предыдущей жизни часто сталкиваться при построении производных Федоры, а позднее и самой Мандривы). Если майнтейнер предлагает некачественный пакет, он немедленно и автоматически получит его обратно с указанием переделать.
На взгляд системных архитекторов РОСы/Mandriva, continuous integration при построении дистрибутивов – это не сколько сам факт ежедневных сборок из пакетов разной степени свежести, как часто бывает, но в гораздо большей степени – уверенность билд-менеджера в том, что все пакеты в образе собраны без конфликтов друг с другом, и проверять это нужно в целом, а не только набором локально применяемых тестов. Нам кажется странной ситуация, когда нарушение пакетом сборки других пакетов обнаруживается в значительной степени случайно, вручную и запросы на пересборку размещаются вручную же в списке рассылки без гарантии какой-либо реакции. Это – прошлый век.
Конструктивно ABF представляет собой расширяемое распределенное множество билд-клиентов (для разных платформ и архитектур), работающих с единым хранилищем кода и управляемых из единого диспетчера-балансировщика. Уже сейчас есть билд-клиенты для Mandriva и для ряда RH-производных, то есть единообразно собираются различные дистрибутивы. От приходящего в эту инфраструктуру разработчика платформы/дистрибутива требуется создать на основе нашего шаблона собственный сборочный бэкенд (используя фрагменты скриптов оригинальной процедуры сборки) и импортировать исходные коды в хранилище. То есть, собрать любой RPM-based дистрибутив – это дело техники. С Debian-based дистрибутивами создание бэкендов несколько сложнее, но достижимо и уже запланировано. А уж создание производных дистрибутивов и сборка одного приложения для нескольких платформ – все это перестает быть хоть сколько-нибудь сложным.
Повторю, речь идет о давно задуманных и развиваемых в РОСе технологиях, причем изначально развиваемых для внутренних нужд. Сдавать эти технологии наружу мы не стремились, специально для конкурса не готовили (и в процессе подготовки прототипов приходится срочно адаптировать код под некоторые требования), к тому же бюджет заявки от ПингВин не покроет даже наших собственных, уже понесенных, расходов на разработку этих технологий. Тем не менее, если ставить вопрос о технических альтернативах в данном контракте, мы считаем наши технологии вполне достойными участия и, что важно, достаточно современными (см. выше). Уровень, на который мы претендуем – это уровень Launchpad и OBS.
Вопрос о том, в каком режиме вести проект после сдачи для нас остается открытым. Безусловно, мы заинтересованы развивать его и приглашать дистрибутивные команды, особенно работающие с Debian-дистрибутивами, производными Мандривы (особенно будем рады глубокоуважаемой команде EduMandriva), а также собирающие дистрибутивы на других аппаратных архитектурах.
Евгений Соколов
ROSA R&D