Как настроить процесс разработки локальной базы данных для небольшой веб-команды?

Фон

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

Раньше мы все работали через FTP на сервере dev с одной базой данных dev. Это «сработало» ^* некоторое время, но мы движемся в новом направлении, поэтому пришло время взрослеть нашего процесса.

Мы используем Percona Server 5.5, но это должно быть независимым от базы данных, с целью снижения затрат.

Цели :

Я смотрю на создание процесса непрерывной интеграции (CI) для разработки баз данных, имея в виду следующее:

1. Разработчики имеют локальную копию данных для запуска кода разработки
2. Возможность откатить структуру базы данных до предыдущего набора изменений
3. Возможность отделить новые изменения схемы объекта от изменений в дизайне схемы
4. Возможность локального изменения структуры базы данных для тестирования.

Начальная концепция

Я набросал процесс ниже, используя SVN и LiquiBase, хотя он полностью удаляется #4.

• создать ветку 'развития' из ствола
• центральный сервер разработки 'db' запускает ветку 'development'
• локальные разработчики настроены как подчиненные для ветви разработки (см. #1выше)
• Наборы изменений в liquibase регулярно передаются в ветку разработки, которая выполняет хук после фиксации для обновления центральной базы данных разработки (которая будет распространяться на локальные машины, работающие в качестве подчиненных для этого сервера разработки) (liquibase предоставляет #2выше)
• когда функции или исправления схемы будут готовы перейти к QA, администратор базы данных (я) объединит соответствующие изменения из ветви разработки в транк. Это действие создаст сценарий SQL для применения к серверу промежуточной базы данных.
• Промежуточный сервер должен отражать TRUNK, который должен иметь ту же структуру, что и Production, плюс изменения в QA
• после выполнения сценария sql на промежуточном сервере выполните некоторые проверки качества для изменений.
• Если все выглядит хорошо, пометьте структуру. Это сгенерирует сценарий .sql, который будет запускаться в производство вручную администратором базы данных (в непиковые часы, если требуется)

Этот процесс требует, чтобы все разработчики использовали одну и ту же ветку 'development', то есть в каждый момент времени существует только одна версия схемы базы данных (не уверен, что я этого хочу).

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

Как можно изменить вышеуказанный процесс, чтобы обеспечить локальную разработку, при этом сохраняя относительно актуальную копию данных (как это предусмотрено репликацией в моем предлагаемом процессе)? Я не требую, чтобы данные были актуальными даже до последней недели.

---

^* Под «работал» я имею в виду, что этого было достаточно, но это была PITA.

Управление средами

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

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

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

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

Что я сделал

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

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

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

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

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

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

Создание тестовых сред из модели репозитория. Это гарантирует, что разработка в средах, не синхронизированных с репозиторием, попадет в тестирование.

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

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

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

• Запустите скрипт исправления для среды тестирования дыма.

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

Что мне нравится в этом процессе

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

• Разработчики могут повозиться там, где им нужно.

• Несколько ветвей и потоков развития могут быть размещены.

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

• Инструменты сравнения схем обеспечивают QA для самого развертывания.

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

• Развертывание на основе моделей репозитория и сценариев исправлений означает, что неконтролируемый мусор случайно не переносится из сред разработки в рабочую среду.

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

• Среды дешевы и просты в развертывании без необходимости прыгать через обручи.

• Разработчики вынуждены создавать систему, которая поддается простому процессу сборки и развертывания.

• Разработчики вынуждены изучать основные задачи администрирования базы данных, но тестовая и производственная среды изолированы от ошибок noob.

Как это отвечает вашим требованиям

1. Разработчики имеют локальную копию данных для запуска кода разработки
   
   . Сценарии развертывания или образы БД означают, что они могут настроить среду из любой доступной версии.

2. Возможность откатить структуру базы данных до предыдущего набора изменений.
   
   Сортировка по сценариям развертывания. Либо с помощью DDL, либо с помощью тестовых образов резервных копий баз данных, созданных с помощью управляемого процесса, разработчики могут перенести среду к любой конкретной версии, которая у вас есть.

3. Возможность разделения новых изменений схемы объектов по сравнению с изменениями, внесенными в дизайн схемы.
   
   Патчи для общей версии можно поддерживать в отдельном ветвлении дерева svn. Если резервные копии базы данных используются в качестве эталонных сред, они должны храниться где-то с той же структурой папок, что и ветвление проектов контроля версий.

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