Благодаря мощному инструментарию с открытым исходным кодом и облачным сервисам отправка приложения в рабочую среду еще никогда не была такой простой. В этой записи блога мы собираемся перейти от начальной загрузки приложения Next.js к его развертыванию на Vercel. Мы будем использовать GitHub Action для обработки непрерывной интеграции и Sentry для мониторинга приложения после его развертывания, чтобы получать предупреждения о любых проблемах, как только оно появится.

Начальная загрузка приложения

Давайте сначала загрузим приложение

npx create-next-app prod-ready-nextjs-sentry --use-npm

Мы можем запустить наше приложение, используя скрипт, предоставленный Next.js в файле package.json.

Давайте добавим небольшой фрагмент кода, который добровольно вызывает исключение на домашней странице. Мы будем использовать это, чтобы вызвать ошибку в рабочем приложении и протестировать нашу интеграцию Sentry.

Мы добавляем простую кнопку, которая выдает ошибку при нажатии на файл index.js.

Настройка часового

Sentry — это платформа для мониторинга приложений. Интеграция Sentry в наше приложение предоставит нам следующие возможности:

Короче говоря, вы будете в деталях знать, если что-то пойдет не так во время и после развертывания вашего приложения, и, кроме того, вы получите некоторые данные о производительности вашего приложения.

Во-первых, нам нужно создать учетную запись Sentry, перейдя на веб-сайт Sentry и создав новый проект Next.js.

Проект готов на стороне Sentry. Теперь мы можем приступить к настройке Sentry SDK в нашем приложении. Чтобы сделать это максимально простым и беспроблемным, Sentry предоставляет SDK, специально предназначенный для приложений Next.js. Его можно быстро установить с помощью npm.

npm install --save @sentry/nextjs

Затем мы запускаем мастер для автоматической инициализации нашей конфигурации.

npx @sentry/wizard -i nextjs

Настроив вашу конфигурацию таким образом, Sentry будет сообщать об ошибках и исключениях из коробки, а также будет генерировать и загружать исходные карты, чтобы упростить отладку минимизированного или связанного кода javascript.

Короче говоря, он генерирует все необходимые файлы конфигурации, необходимые Sentry для обработки любых ошибок, возникающих в нашем приложении Nextjs, как на стороне клиента, так и на стороне сервера.

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

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

Если мастер часового не может найти ваш проект, убедитесь, что в файле sentry.properties установлено правильное значение, а в файле .sentryclirc — правильный токен.

При выполнении этой команды вы также можете столкнуться со следующей ошибкой.

Как указано в ошибке CLI, это происходит, когда файл next.config.js уже был сгенерирован во время начальной загрузки приложения next.js.

Чтобы решить эту проблему, вам нужно объединить эти два файла в один файл next.config.js.

Мы уже можем протестировать нашу реализацию, запустив наше приложение

npm run dev

и нажав кнопку ошибки, которую мы добавили ранее.

Возвращаясь к проекту Sentry, мы видим, что возникла новая проблема.

Теперь наше приложение протестировано, и мы можем начать думать о том, как развернуть его в рабочей среде.

Настройка непрерывной интеграции с GitHub Action

Существует множество отличных решений для реализации непрерывной интеграции с нашим приложением, одним из которых является GitHub Actions. это не самое многофункциональное или самое продвинутое решение, но оно очень доступно и, как вы можете догадаться, очень хорошо интегрируется с приложениями, размещенными на Github.

Первым делом создадим новый репозиторий github.

Мы пушим приложение в репозиторий.

git remote add origin [email protected]:Mozenn/prod-ready-nextjs.git 
git branch -M main 
git push -u origin main

Мы сохраним наш пайплайн простым, запуская этап проверки и сборки каждый раз, когда что-то помещается в основную ветку.

Конечно, действия GitHub обеспечивают гораздо более продвинутое использование, особенно с использованием действий, доступных на торговой площадке GitHub, или путем создания собственного настраиваемого действия. Мы могли бы, например, запустить несколько сквозных тестов с Cypress и существующим действием кипариса.

GitHub Actions работает декларативно, используя рабочие процессы, написанные в формате Yaml и помещенные в папку .github/workflows вашего репозитория.

Файл рабочего процесса состоит из нескольких заданий, и каждое задание состоит из множества шагов.

Сначала мы определяем, как запускается рабочий процесс. Этот конвейер будет запускаться каждый раз, когда что-то новое помещается в основную ветку благодаря директиве on-push.

Затем мы определяем рабочие процессы.

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

Второй просто запускает сборку приложения. Далее в статье вы увидите, что Vercel также создает приложение перед его развертыванием, что делает эту работу бесполезной в данном случае. Однако вы можете захотеть отключить автоматическое развертывание для каждой отправки в основную ветку в Vercel, но по-прежнему хотите запускать сборку для каждой отправки через действия GitHub.

Давайте рассмотрим задание сборки, чтобы более подробно изучить действия Github.

Директива run-on устанавливает тип сервера, на котором будет выполняться задание.

Первые два шага используют предопределенные действия, которые предоставляются по умолчанию. Затем мы используем директиву run для выполнения сценариев, определенных в package.json, один для получения зависимостей, а другой для запуска сборки.

Иногда шаги требуют динамических конфигураций. Эти конфигурации могут быть предоставлены через переменные среды с помощью блока env.

Их объем будет зависеть от того, где вы разместите блок env.

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

Но здесь есть одна загвоздка. Вы могли заметить, что мы используем префикс «секреты».

Это потому, что мы хотим сохранить нашу конфигурацию часового для себя.

Для этого GitHub Actions предоставляет способ безопасного хранения секретов с помощью Encrypted Secrets. Они могут быть определены на уровне организации или репозитория. Здесь мы определяем эти переменные в части Secrets нашего репозитория GitHub, доступной через страницу настроек.

Мы закончили с настройкой рабочего процесса, давайте попробуем его, сделав новый коммит и отправив его в удаленный репозиторий.

git add -A 
git commit -m "add github action workflow" 
git push origin main

Вернувшись в наш репозиторий GitHub, мы видим, что наш рабочий процесс был запущен и успешно запущен!

Настройка Верселя

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

Для этого мы используем Vercel, облачную платформу от создателя Next.js. Он очень хорошо подходит для гибридной природы Next.js с рендерингом на стороне сервера, с одной стороны, и рендерингом на стороне клиента со статической генерацией, с другой. Таким образом, это отличное решение для развертывания нашего приложения Nextjs.

Во-первых, давайте создадим учетную запись, если это еще не сделано.

Затем нам нужно связать нашу учетную запись Github, чтобы Vercel мог получить к ней доступ.

Затем мы создаем проект Vercel из репозитория Github.

Однако развертывание завершается ошибкой на этапе сборки.

Анализируя ошибку, мы видим, что развертывание не удалось, поскольку отсутствует конфигурация Sentry.

Чтобы решить эту проблему, мы могли бы вручную добавить переменные среды, как мы это сделали для действий GitHub. Но есть более простой способ — с помощью Sentry Integration for Vercel.

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

Возвращаясь к Sentry, нам нужно подключить проект Sentry к проекту Vercel в меню настроек.

После завершения интеграции мы видим, что наш проект Vercel подхватил конфигурацию Sentry в переменных среды проекта.

И мы можем отправить наш проект без ошибок!

По умолчанию Vercel автоматически создает новое развертывание каждый раз, когда что-то отправляется в основную ветку, но вы можете отключить или изменить это поведение по своему усмотрению.

Тестирование приложения

Давайте закончим этот блог, убедившись, что Sentry работает в продакшене.

Мы переходим в домен Vercel, где было развернуто приложение, и нажимаем кнопку, чтобы вызвать ошибку, как мы это делали в локальной среде.

Мы видим, что Sentry успешно обнаружил ошибку.

Вы могли заметить, что Sentry автоматически указывает правильную среду, которая по умолчанию берется из переменных среды NODE_ENV. Вы можете настроить его, если вам нужна более продвинутая конфигурация, указав новый тег во время вызова метода Sentry.init в файле sentry.config.js, как указано здесь.

Вы можете посмотреть демо-репозиторий на Github.

Первоначально опубликовано наhttps://blog.sentry.io/2022/09/27/deploy-your-next-js-application-on-vercel-using-sentry-and-github-actions. /.

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .

Заинтересованы в масштабировании запуска вашего программного обеспечения? Ознакомьтесь с разделом Схема.