Развёртывание из кодинг-агента

Кодинг-агент может использовать Lizard Skill и Lizard CLI для развёртывания созданного им приложения. Агент читает руководство установленного CLI, проверяет целевой проект, запускает сборку и анализирует результат. Для этого не требуется отдельный MCP-транспорт.

Перед началом

Подготовьте рабочее приложение, разрешение на его развёртывание и аккаунт на Lizard. Приложение должно слушать на 0.0.0.0 и настроенном порту. Запустите локальные проверки приложения перед стартом облачной сборки.

Передайте агенту актуальное руководство

npm install -g @lizard-build/cli
lizard skills get core --json
lizard --help --json

Lizard Skill загружает инструкции, соответствующие установленному CLI. Для конкретной команды читайте её схему вместо угадывания флагов:

lizard up --help --json
lizard service set --help --json

Полезный промпт:

Разверни это приложение с помощью Lizard. Прочитай руководство установленного CLI, проверь связанный проект и сервис, запусти проверки приложения и покажи результат сборки и рабочий URL. Спроси перед изменением существующего продакшн-сервиса или удалением данных.

Развёртывание локального исходного кода

Для полноценного теста используйте пример agent-app. Он использует Node.js 22 и pg 8.16.3, слушает порт 3000 и читает одну строку из Managed Postgres. При запуске создаёт демо-таблицу и строку, если их нет. Для более крупного приложения используйте свой процесс миграций.

Скопируйте пример в отдельную директорию и запустите локальные проверки:

npm ci
npm run check
lizard status --json

Это проверяет JavaScript-синтаксис. Проверки базы данных и публичного HTTP приходят после развёртывания. Если эта директория уже связана, убедитесь, что это тот проект. Для нового тестового проекта:

lizard init --name agent-example --json
lizard add --service api --json
lizard add postgres --json
lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api --json
lizard up --service api --port 3000 --json

Используйте фактическое имя базы, если оно не postgres. Сохраните ссылку в кавычках, чтобы локальная оболочка не расширила её. Настройте перед первым развёртыванием. Входите через lizard login только если команда сообщает, что требуется аутентификация.

Путь загрузки намерен для этого скопированного примера. Для приложения, уже находящегося в GitHub, используйте следующий раздел. В macOS с Lizard CLI 0.3.92 выполните COPYFILE_DISABLE=1 lizard up --service api --port 3000 --json, чтобы исключить метаданные AppleDouble. В этой версии CLI неудачная сборка может завершиться с кодом 0: изучите терминальное событие failed/deployed и проверьте приложение. См. известные проблемы.

Развёртывание из GitHub

Используйте этот путь, когда у приложения есть репозиторий GitHub. Сначала проверьте удалённый репозиторий:

git remote get-url origin
lizard status --json
lizard ps --json

Используйте связанный тестовый проект или создайте его через lizard init --name YOUR_PROJECT_NAME. Подключите репозиторий без запуска сборки, чтобы успеть настроить окружение:

lizard add --repo YOUR_ORG/YOUR_REPO --name api-git --no-deploy --json
lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api-git --json

Сначала подключите Managed Postgres, если у проекта его нет. Эта последовательность использует тот же пример на Node.js. Для репозитория с приложением в поддиректории или на другой ветке настройте перед развёртыванием:

lizard service set api-git --set branch=YOUR_BRANCH --set rootDirectory=YOUR_APP_DIRECTORY --set containerPort=3000 --json
lizard redeploy --service api-git --json

Для приложения в корне репозитория на main опустите команду service set. Укажите правильный порт, если ваше приложение использует другой. Если репозиторий недоступен для Lizard, подключите GitHub App; не заменяйте этот путь загрузкой молча.

Для последующих обновлений существующего GitHub-сервиса используйте lizard redeploy --service api-git или отправьте изменения в отслеживаемую ветку, если включён автодеплой. lizard up переключает сервис на загрузку исходников. Изменение настроек сборки у уже запущенного сервиса может запустить собственную сборку; изучите события перед запросом следующей.

Проверка результата

Читайте логи сборки и рантайма отдельно:

lizard logs --build --service api --json
lizard logs --service api --json
lizard ps --json

Для GitHub-пути используйте api-git вместо api. Установите APP_URL в HTTPS URL, сообщенный CLI, затем выполните:

curl --fail "$APP_URL/health"
curl --fail "$APP_URL/data"

Первый ответ — App ready. Второй — {"value":"database-connected"}. Одна сборка не доказывает, что ссылка на базу разрешилась. Пример показывает только эту фиксированную демо-строку, а не API администрирования базы.

Для этого тестового сервиса проверьте перезапуск рантайма:

lizard restart --service api --json

Дождитесь, пока сервис вернётся в running в lizard ps --json, и повторите оба HTTP-запроса. Хвост рантайм-лога может быть пустым; HTTP-ответ — это проверка приложения. Строка хранится в Managed Postgres; процесс сервиса её не хранит. Для проверки повторного использования существующих данных обновите демо-строку на уникальное значение в редакторе базы перед перезапуском и подтвердите, что /data возвращает это значение после.

logs --json возвращает хвост лога и завершается. Прочитайте хранилище и восстановление перед изменением реальных данных приложения.

Когда развёртывание падает

Используйте код выхода и JSON-ошибку упавшей команды. Ошибка компиляции, процесс, который завершается, и недоступный порт требуют разных исправлений. См. JSON и автоматизация и сервис никогда не становится healthy. redeploy — это новая сборка, а не откат к старой версии.

Лимиты и стоимость

Агент может создавать оплачиваемые ресурсы через тот же CLI, что и человек. Проверьте лимиты и цены, и ограничьте права учётных данных нужными проектами и сервисами.

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