Фон
Я работаю над созданием нового процесса разработки для небольшой веб-команды из 4 программистов и 4 дизайнеров с очевидным потенциалом для роста команды в будущем. Наш продукт является центральным приложением, которое поддерживает клиентские сайты, которые мы также разрабатываем и размещаем.
Раньше мы все работали через FTP на сервере dev с одной базой данных dev. Это «сработало» * некоторое время, но мы движемся в новом направлении, поэтому пришло время взрослеть нашего процесса.
Мы используем Percona Server 5.5, но это должно быть независимым от базы данных, с целью снижения затрат.
Цели :
Я смотрю на создание процесса непрерывной интеграции (CI) для разработки баз данных, имея в виду следующее:
- Разработчики имеют локальную копию данных для запуска кода разработки
- Возможность откатить структуру базы данных до предыдущего набора изменений
- Возможность отделить новые изменения схемы объекта от изменений в дизайне схемы
- Возможность локального изменения структуры базы данных для тестирования.
Начальная концепция
Я набросал процесс ниже, используя SVN и LiquiBase, хотя он полностью удаляется #4
.
- создать ветку 'развития' из ствола
- центральный сервер разработки 'db' запускает ветку 'development'
- локальные разработчики настроены как подчиненные для ветви разработки (см.
#1
выше)- Наборы изменений в liquibase регулярно передаются в ветку разработки, которая выполняет хук после фиксации для обновления центральной базы данных разработки (которая будет распространяться на локальные машины, работающие в качестве подчиненных для этого сервера разработки) (liquibase предоставляет
#2
выше)- когда функции или исправления схемы будут готовы перейти к QA, администратор базы данных (я) объединит соответствующие изменения из ветви разработки в транк. Это действие создаст сценарий SQL для применения к серверу промежуточной базы данных.
- Промежуточный сервер должен отражать TRUNK, который должен иметь ту же структуру, что и Production, плюс изменения в QA
- после выполнения сценария sql на промежуточном сервере выполните некоторые проверки качества для изменений.
- Если все выглядит хорошо, пометьте структуру. Это сгенерирует сценарий .sql, который будет запускаться в производство вручную администратором базы данных (в непиковые часы, если требуется)
Этот процесс требует, чтобы все разработчики использовали одну и ту же ветку 'development', то есть в каждый момент времени существует только одна версия схемы базы данных (не уверен, что я этого хочу).
Это также означает, что любые изменения в схеме не могут быть протестированы локально и могут повлиять на других разработчиков, если не все сделано правильно. В нашей среде разработчики могут добавлять новые таблицы, но редко изменять существующую структуру. Как администратор базы данных, дизайн исправления сделаны мной. Но неспособность проверить исправления локально - моя самая большая проблема в этом процессе.
Как можно изменить вышеуказанный процесс, чтобы обеспечить локальную разработку, при этом сохраняя относительно актуальную копию данных (как это предусмотрено репликацией в моем предлагаемом процессе)? Я не требую, чтобы данные были актуальными даже до последней недели.
* Под «работал» я имею в виду, что этого было достаточно, но это была PITA.