106 lines
7.9 KiB
Markdown
106 lines
7.9 KiB
Markdown
## Purpose
|
|
|
|
Определяет поддерживаемые эксплуатационные свойства локального и серверного
|
|
запуска WealthLedger, включая поставку компонентов и сохранность состояния.
|
|
|
|
## ADDED Requirements
|
|
|
|
### Requirement: Локальная среда воспроизводит границы поставленного приложения
|
|
|
|
Поддерживаемый локальный запуск SHALL предоставлять один browser origin для
|
|
интерфейса и API WealthLedger. Разработка интерфейса MUST сохранять быстрый
|
|
цикл обратной связи при изменении исходного кода, а разработка API MUST
|
|
перезапускать затронутый runtime без ручной пересборки всей среды. Локальные
|
|
данные MUST быть изолированы от server data.
|
|
|
|
#### Scenario: Разработчик открывает локальное приложение
|
|
|
|
- **WHEN** поддерживаемая локальная среда успешно запущена
|
|
- **THEN** браузер получает интерфейс и обращается к API через тот же origin,
|
|
не зная внутреннего адреса API
|
|
|
|
#### Scenario: Разработчик меняет интерфейс
|
|
|
|
- **WHEN** разработчик изменяет исходный код интерфейса в запущенной локальной
|
|
среде
|
|
- **THEN** браузер получает изменение без ручной полной пересборки среды
|
|
|
|
### Requirement: Серверное приложение имеет одну внешнюю точку входа
|
|
|
|
Поддерживаемый server deployment SHALL принимать HTTP-трафик WealthLedger на
|
|
одной внешней точке входа. Через неё MUST быть доступны интерфейс и API с
|
|
сохранением их действующих путей и session semantics. API и хранилище данных
|
|
MUST NOT требовать отдельного внешнего сетевого доступа.
|
|
|
|
#### Scenario: Внешний reverse proxy направляет запрос приложению
|
|
|
|
- **WHEN** server reverse proxy передаёт запрос на единственную точку входа
|
|
WealthLedger
|
|
- **THEN** пользователь получает интерфейс, а запросы к действующему API
|
|
обрабатываются приложением без отдельного маршрута reverse proxy к API
|
|
|
|
### Requirement: Поставка допускает независимое обновление компонентов
|
|
|
|
Система SHALL предоставлять versioned delivery artifacts для интерфейса и API
|
|
как независимых компонентов. Оператор MUST иметь возможность установить
|
|
выбранную версию только одного компонента, сохранив другой компонент и
|
|
постоянное пользовательское состояние работающими. Поддерживаемая поставка
|
|
MUST явно фиксировать выбранные версии обоих компонентов.
|
|
|
|
#### Scenario: Обновляется только интерфейс
|
|
|
|
- **WHEN** оператор устанавливает новую версию интерфейса при неизменной
|
|
совместимой версии API
|
|
- **THEN** API и его постоянное состояние не пересоздаются, а приложение
|
|
начинает отдавать новую версию интерфейса
|
|
|
|
#### Scenario: Обновляется только API
|
|
|
|
- **WHEN** оператор устанавливает новую версию API при неизменной совместимой
|
|
версии интерфейса
|
|
- **THEN** интерфейс не пересоздаётся, а приложение начинает обрабатывать
|
|
запросы новой версией API после её готовности
|
|
|
|
### Requirement: Постоянное состояние и секреты переживают штатный lifecycle
|
|
|
|
Пользовательские данные, session state и ключи, необходимые для чтения
|
|
зашифрованных подключений, MUST сохраняться при штатных перезапусках и
|
|
обновлениях компонентов. Секреты MUST задаваться отдельно от versioned delivery
|
|
artifacts и MUST NOT попадать в интерфейс, журналы или публичный HTTP-ответ.
|
|
|
|
#### Scenario: Приложение штатно перезапускается
|
|
|
|
- **WHEN** оператор штатно перезапускает приложение без восстановления данных
|
|
- **THEN** после запуска доступны прежние пользовательские данные и действующие
|
|
session semantics, а сохранённые зашифрованные подключения остаются читаемыми
|
|
тем же ключом
|
|
|
|
### Requirement: Обновление API сохраняет целостность данных
|
|
|
|
Перед тем как новая версия API начинает принимать запросы, необходимые
|
|
изменения схемы постоянных данных MUST быть применены успешно. При ошибке
|
|
изменения данных новая версия API MUST NOT объявляться готовой. Краткий простой
|
|
обновляемого компонента допустим; непрерывность обслуживания и несколько
|
|
одновременных экземпляров API не являются обещанием этой capability.
|
|
|
|
#### Scenario: Подготовка данных новой версии не прошла
|
|
|
|
- **WHEN** обязательное изменение постоянных данных завершается ошибкой
|
|
- **THEN** новая версия API не начинает обслуживать запросы, а оператор получает
|
|
диагностируемый неуспешный результат обновления
|
|
|
|
### Requirement: Восстановление не выдаёт откат приложения за откат данных
|
|
|
|
Поддерживаемая процедура обновления и восстановления MUST различать возврат
|
|
версии компонентов и восстановление пользовательских данных. Она MUST требовать
|
|
согласованную резервную копию перед изменением постоянных данных и MUST NOT
|
|
заменять более новые пользовательские данные прежней копией как побочный эффект
|
|
возврата версии приложения.
|
|
|
|
#### Scenario: Оператор возвращает предыдущую версию API
|
|
|
|
- **WHEN** оператор возвращает прежнюю версию API после неуспешного обновления
|
|
- **THEN** процедура явно проверяет совместимость этой версии с текущими
|
|
данными и не выполняет восстановление старой копии данных без отдельного
|
|
решения оператора
|