Процессы жизненного цикла

Настоящий документ описывает процессы жизненного цикла программы «Парсвайс» в том виде, в котором они выполняются на дату редакции. Правообладатель программы — индивидуальный предприниматель Крылов Руслан Хуважиевич.

1. Состав программы

2. Разработка

Разработку программы ведёт правообладатель. Изменения вносятся в основную ветку репозитория; объёмные изменения готовятся в отдельной ветке и затем объединяются с основной. Каждое изменение фиксируется в истории с описанием и автором.

Сторонний компонент попадает в программу только после проверки его лицензии.

3. Хранение исходного кода

Исходный код всех компонентов и конфигурация развёртывания хранятся в системе контроля версий GitVerse, размещённой в Российской Федерации, в организации правообладателя. История изменений хранится там же.

4. Сборка

Сборка выполняется из собственных копий сторонних компонентов, без обращения к зарубежным ресурсам:

• базовые образы контейнеров хранятся в собственном реестре правообладателя в Яндекс Облаке, Dockerfile и манифесты ссылаются на них по контрольной сумме;
• пакеты операционной системы устанавливаются через российское зеркало, подписи пакетов проверяются штатными средствами;
• Python-пакеты сервера устанавливаются из собственного образа-склада пакетов при отключённой на этом шаге сети; точный набор версий зафиксирован в репозитории;
• JavaScript-пакеты панели управления и виджета устанавливаются командой npm ci строго по файлу блокировки версий через собственный реестр-посредник в Яндекс Облаке; контрольная сумма каждого пакета сверяется с файлом блокировки;
• модель векторизации входит в образ сервиса векторизации и не загружается при запуске.

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

Обновление стороннего компонента — действие разработчика: новая версия копируется в собственный реестр, проверяется сборкой, новая контрольная сумма фиксируется в истории исходного кода.

5. Тестирование

После выкатки скрипт дожидается готовности новых экземпляров компонентов по проверкам готовности Kubernetes. Затем проверяются журналы компонентов и ответы программного интерфейса.

6. Выпуск и развёртывание

Сервер программного интерфейса и панель управления

Выкатка выполняется скриптом деплоя компонента:

1. Сборка образа контейнера.
2. Загрузка образа в Yandex Container Registry правообладателя.
3. Перезапуск развёртывания в Kubernetes: для сервера — сервер программного интерфейса, обработчик очередей и планировщик; для панели — панель управления.
4. Ожидание завершения выкатки и готовности новых экземпляров.

Сервер программного интерфейса обновляется поэтапно: новый экземпляр запускается до остановки старого, поэтому обновление проходит без перерыва в обслуживании. Схема базы данных обновляется миграциями автоматически при запуске сервера.

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

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

Сервис векторизации

Образ сервиса векторизации хранится в реестре правообладателя; манифесты Kubernetes ссылаются на него по контрольной сумме. Замена образа выполняется изменением манифеста в репозитории конфигурации развёртывания и его применением к кластеру.

Виджет

Виджет выпускается версиями по семантической нумерации, текущая версия — 3.12.5. Выпуск выполняется командой npm version, которая:

1. устанавливает пакеты через собственный реестр-посредник строго по файлу блокировки версий;
2. собирает бандл;
3. фиксирует номер версии коммитом и тегом и отправляет их в GitVerse;
4. размещает бандл в Yandex Object Storage, откуда он раздаётся по адресу releases.parsewise.ru.

Каждая версия размещается по собственному адресу, содержащему номер версии; содержимое по этому адресу не меняется и кешируется как неизменяемое. Адрес latest указывает на последнюю выпущенную версию и кешируется на 5 минут.

Поставка в контур заказчика

Для установки в инфраструктуре заказчика предназначен отдельный реестр поставки правообладателя в Яндекс Облаке, не совпадающий с реестром облачной установки. Теги образов в реестре поставки не перезаписываются; заказчик получает доступ отдельной учётной записью только к образам своей поставки. Образы также могут быть переданы архивом OCI для загрузки в реестр заказчика.

7. Откат

8. Установка обновлений

В облачной установке обновления выкатывает правообладатель в порядке раздела 6.

Установленная в контуре заказчика программа не получает обновлений автоматически и не обращается за ними к внешним ресурсам. Новую версию образов устанавливает заказчик по своему решению; при поддержке по годовому договору правообладатель передаёт обновлённые образы и помогает с установкой.

Сайты, подключившие виджет по адресу latest, получают новую версию в течение 5 минут после выпуска. Сайты, подключившие виджет по адресу конкретной версии, остаются на ней до смены адреса.

9. Сопровождение версий

Облачная установка работает на одной текущей версии компонентов для всех заказчиков. Исправления виджета выпускаются новыми версиями; ранее выпущенные версии остаются доступны без изменений. Для установки в контуре заказчика исправления передаются обновлёнными образами в рамках годового договора поддержки.

10. Устранение неисправностей

Обращения принимаются и обрабатываются в порядке и в сроки, указанные в документе Техническая поддержка. Исправление проходит тот же путь, что и любое изменение: фиксация в истории исходного кода, сборка, проверка, выкатка, проверка после выкатки.

Уязвимости в сторонних компонентах закрываются обновлением компонента в собственном реестре. Пример: после окончания поддержки Debian 11 образ сервера переведён на Debian 13 и Python 3.12, образ панели управления — на Node.js 24.

11. Хранение и удаление данных

В облачной установке данные заказчика хранятся в инфраструктуре Яндекс Облака: в основной базе данных, векторной базе данных и объектном хранилище. При установке в контуре заказчика данные остаются в его инфраструктуре и находятся под его управлением.

Заказчик может выгрузить диалоги из панели управления в формате CSV: тема, вопрос, ответ, оценка.

Владелец проекта может удалить проект в панели управления. При удалении программа удаляет данные проекта из основной базы данных, файлы и медиа из объектного хранилища и векторы из векторной базы данных; очистка векторной базы выполняется фоновой задачей.

Отдельного срока хранения данных после окончания облачного договора программа не устанавливает: данные удаляются удалением проекта.

12. Персонал

Для поддержания жизненного цикла программы требуются следующие компетенции.

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