Содержание руководства
Первый деплой показывает, что сервис запускается. Для дальнейшей работы важно ещё и то, что приложение сохраняет данные и переживает обновления. Поручим Octo небольшой API заявок с Postgres и проверим его в двух состояниях: до изменения и после.
Что подготовить
- Понадобится доступ к Octo Apps и возможность создать Postgres в вашем рабочем пространстве. Уточните условия ресурсов у агента перед запуском.
- Скачайте учебное ТЗ. Оно задаёт поля заявки, операции создания и чтения и небольшое изменение для второго деплоя.
- Для упражнения используйте отдельный учебный сервис с тестовыми данными. Укажите, кто может выполнять запросы к нему.
В исходниках используются учебные данные. Замените их своими, когда освоите процесс.
Зафиксируйте контракт сервиса
Попросите Octo создать API и подключить Postgres. В ТЗ перечислите поля, обязательность, ответы на корректные и некорректные запросы и правила доступа.
Настройки подключения должны быть конфигурацией сервиса. Попросите агента показать, какие параметры нужны, не выводя значения секретов в публичный код или примеры.
Разверни через Octo Apps учебный API заявок с Postgres по приложенному ТЗ. Уточни условия ресурсов и необходимые доступы. Храни секреты в конфигурации вне публичного кода. Реализуй создание и чтение заявки с проверкой ввода и доступа. Дай адрес сервиса и примеры запросов без значений секретов.
Запишите и прочитайте тестовые данные
Создайте заявку, сохраните её идентификатор и прочитайте запись отдельным запросом. Так вы проверите не только успешный ответ API, но и возможность снова получить данные.
Проверьте некорректный email и запрос без нужного доступа. Ожидаемые ответы должны соответствовать согласованному контракту. Не заменяйте проверку ответом агента «всё готово».
Обновите сервис с сохранением записи
Добавьте необязательное поле «комментарий». Попросите выполнить изменение схемы и сервиса так, чтобы уже созданные записи сохранились.
После повторного размещения прочитайте старую заявку по сохранённому идентификатору и создайте новую с комментарием. Если старую запись не удаётся получить, обновление нельзя считать завершённым.
Добавь необязательное поле comment и обнови учебный сервис. Сохрани существующие данные. Перед изменением опиши способ восстановления при неудаче. После обновления прочитай старую заявку по сохранённому ID, затем создай и прочитай новую с comment. Покажи фактические результаты проверок.
Пример результата
Что сравнить до и после обновления
- До: API создаёт заявку с именем и email, возвращает идентификатор и читает запись по нему.
- После: та же запись доступна по прежнему идентификатору; новая запись дополнительно сохраняет комментарий.
- При отсутствии нужного доступа запрос отклоняется. Секрет подключения не появляется в коде страницы или тексте примеров.
Главный нюанс и проверка
Работающий API не доказывает сохранность данных при следующем изменении. Проверка обновления должна включать старую запись. Для рабочего сервиса отдельно согласуйте резервное копирование, восстановление и эксплуатацию с учётом доступных возможностей размещения.
Перед тем как использовать результат
- Создание и отдельное чтение возвращают согласованные данные.
- Некорректный ввод и запросы без доступа обработаны по контракту.
- После обновления старая запись сохранилась.
- Новая запись поддерживает добавленное поле; секреты не раскрыты.
Как повторить на своей задаче
Сохраните ТЗ, команды проверки и правила обновления рядом с проектом. При следующих изменениях поручайте Octo не только новый код, но и повторение тех сценариев, на которых уже работают пользователи.
Попробуйте этот сценарий
Скачайте исходник, скопируйте задание и отправьте его Octo вместе с файлом.