Як керувати змінами схеми бази даних у версіях проекту з відкритим кодом

Я керую веб-програмою з відкритим кодом PHP / MySQL, яку використовують декілька шкіл К-12 та деякі коледжі. Я також єдиний розробник проекту. У той час як це було трохи більше, ніж завантаження програми, у якого працює мій роботодавець, останній рік я працював над тим, щоб перетворити його на "справжній" проект з відкритим кодом з документацією, нумерованими випусками, публічними журналами змін тощо.

Я прагну вдосконалити процес оновлення, і одна з потенційно болючих областей (особливо для шкіл, голодуючих від ІТ) - це зміни в схемі бази даних між випусками. Вони, як правило, трапляються часто або не є різкими змінами, але я вдячний пропозиціям щодо цього процесу.

В даний час я підтримую базовий сценарій встановлення SQL для установки бази даних у новому встановленні. Сюди входить повна схема поточного випуску; додаткові дії не потрібні для нової установки. Зміни, що трапляються між випусками, зберігаються в upgrade-$releasever.sqlскриптах, і для всіх пропущених релізів потрібно поступово запускати всі сценарії оновлення.

Сценарії оболонки не дуже підходять, оскільки багато наших користувачів працюють на хостах без доступу до оболонки. Зважаючи на інші пріоритети, складний сценарій встановлення / оновлення на базі браузера PHP навряд чи реалізується. Однак я хотів би щось зробити зі скриптом PHP на основі браузера, щоб спростити оновлення. Пропозиції, як підійти до цього?

У моєму проекті є файл update.php, який користувач запускає через свій браузер після встановлення нової версії програмного забезпечення. Цей скрипт оновлення перевіряє номер версії бази даних, який зберігається в таблиці в активній базі даних, і чи змінює будь-які операції з базою даних, які отримають цю схему бази даних до останньої, яка включає оновлення цього номера версії бази даних.

Drupal CMS має цікаве рішення вашої проблеми. Я пропоную поглянути на Drupal взагалі, якщо ви розробляєте веб-рішення за допомогою PHP. Це мій улюблений PHP CMS, і я буду досить упереджений, щоб сказати, що це найкраще там. ;)

Drupal пропонує досить складну обгортку взаємодії з базою даних. Це дозволяє абстрагувати фактичний тип бази даних від розробника модуля, тому вам не дуже важливо, чи працює сервер PostgreSQL, MySQL тощо. Ви також можете створити власний інтерфейс. Кожен модуль повинен надати файл module.install, який містить hook_schemaі hook_install. hook_schemaвикористовується для оголошення схеми таблиці для модуля, при цьому hook_installвиконується процедура встановлення. Архітектура також підтримує поняття оновлень, тому, якщо у користувача вже встановлений модуль, викликаються потрібні гачки оновлення та дозволяють легко оновлювати схему таблиці.

Погляньте: http://drupal.org/node/146862 Навіть якщо Drupal не для вас, я впевнений, що ви можете щось дізнатися з їх архітектурних рішень.

Ми зробили це, створивши папки версій. Ми розмістили всі сценарії бази даних у цій папці. Коли прийшов час розгорнути це для нового клієнта, вони отримали останню версію.

Ми також зберігали будь-які сценарії оновлення в цій папці. Таким чином ми могли перенести клієнта з версії x до версії y.

Це не найкращий метод ... але він працював на нас.