Построение PlanetScale с помощью PlanetScale

Построениеplanetscaleспомощьюplanetscale

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

Наша локальная среда разработки

Есть много движущихся частей, на которых работает PlanetScale, но для меня, инженера в команде Surfaces (которая отвечает за UI, API и CLI), есть две основные кодовые базы, на которых я сосредоточен. Обычно я работаю над интерфейсом PlanetScale , который использует Next.js с TypeScript и Ruby on Rails API, который его поддерживает. Для простоты и удобства использования каждый инженер локально запускает приложение Ruby on Rails, которое обращается к локальному экземпляру MySQL. Вы, наверное, задаетесь вопросом – если вы используете MySQL для локальной разработки, когда вы используете PlanetScale? Когда приходит время вносить изменения в схему, мы используем ветвление базы данных PlanetScale для развертывания изменений в нашей производственной базе данных, которая размещена на PlanetScale.

Для разработчиков изменение схемы – это образ жизни

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

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

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

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

Will Smith pain meme with Tweet from him that reads Попытка применить миграции базы данных без простоя или блокировки базы данных до PlanetScale

Расширение возможностей разработчиков с помощью запросов на разветвление и развертывание базы данных

Мой предыдущий опыт миграции баз данных помог мне понять и оценить ценность неблокирующей схемы изменения в PlanetScale. Сначала мы создаем миграции нашей базы данных, как обычно, используя соответствующую команду Rails:

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

      Локальный сервер базы данных MySQL для локального тестирования кода
    • Специальная ветка базы данных в PlanetScale, которая представляет собой изолированную копию вашей производственной базы данных, в которую вы можете вносить изменения

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

GitHub имеет отличное руководство ), но вот рабочий процесс, который мы используем для создания и развертывания запроса на развертывание:

Создание новой ветви базы данных

С PlanetScale CLI , мы создаем новую ветку в нашей базе данных и переключаемся на нее, выполнив следующую команду:

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

Подключение к новой ветви базы данных с помощью Rails

Для переключения между нашим локальным MySQL базу данных и нашу ветку базы данных PlanetScale, мы используем переменную среды с именем ENABLE_PSDB . Когда этот параметр включен, он подключает приложение Rails к ветви базы данных в PlanetScale. Теперь мы можем вносить любые желаемые изменения в эту ветку в полной изоляции от нашей основной производственной базы данных.

Ниже вы можете увидеть, как мы используем эту переменную среды в нашем config / database.yml файл и пользовательский config / planetscale.rb файл:

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

Когда приходит время применить эту миграцию, мы запускаем ENABLE_PSDB = 1 пакет exec rake db: migrate , который затем применяет изменение схемы к ветви базы данных. Затем вы можете либо перейти к приложению PlanetScale и открыть запрос на развертывание из самой ветви, либо использовать интерфейс командной строки для создания такого запроса на развертывание:

Обычно я посещаю страницу запросов развертывания в нашей базе данных в веб-приложении и копирую URL-адрес запроса развертывания или создаю его самостоятельно из номера запроса развертывания. Затем создатель вставляет этот URL-адрес в тело своего запроса на вытягивание на GitHub, чтобы рецензенты могли просматривать оба объекта бок о бок. Запрос на развертывание также показывает операторы DDL ( CREATE / ALTER / DROP для каждой таблицы изменено в процессе миграции с построчным различием, чтобы каждый, у кого есть доступ, мог ясно видеть, что произойдет.

Запрос на развертывание функции
The schema change in the PlanetScale deploy request
Изменение схемы в запросе на развертывание PlanetScale
The schema change in the PlanetScale deploy request
Запрос на вытягивание GitHub, который отображается на depl oy запрос

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

Развертывание изменений схемы

После того, как запрос на развертывание был одобрен членом группы, создатель может A GitHub pull request that maps to a deploy request разверните изменения схемы в основной производственной ветки, добавив ее в очередь развертывания. Очередь развертывания позволяет ставить в очередь сразу несколько развертываний, поэтому другой товарищ по команде также может поставить в очередь свои изменения схемы для развертывания после текущего выполняющегося. Если что-то пойдет не так во время миграции (например, добавление NOT NULL ограничение для строки, которая является ЗНАЧЕНИЕ NULL), развертывание остановится и отобразится соответствующая ошибка. После исправления ошибки развертывание можно будет перезапустить. После успешного завершения развертывания запрос на вытягивание GitHub объединяется, и наше приложение развертывается в производственной среде с новыми изменениями. Если что-то нужно добавить или изменить в схеме, так же легко создать еще один запрос на развертывание с обновлениями и передать эти изменения в новый запрос на вытягивание.

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