Jak zarządzać zmianami schematu bazy danych w wydaniach projektów typu open source

Zarządzam aplikacją PHP / MySQL typu open source, z której korzysta kilka szkół K-12 i kilka szkół wyższych. Jestem także jedynym deweloperem projektu. Choć kiedyś było to niewiele więcej niż pobieranie aplikacji, którą hostuje mój pracodawca, w ciągu ostatniego roku pracowałem nad tym, aby przekształcić ją w „prawdziwy” projekt open source z dokumentacją, numerowanymi wydaniami, publicznymi dziennikami zmian itp.

Chcę usprawnić proces aktualizacji, a jednym z potencjalnie bolesnych obszarów (szczególnie dla szkół głodnych wiedzy informatycznej) są zmiany w schemacie bazy danych między wydaniami. Nie zdarzają się często lub są drastycznymi zmianami, ale byłbym wdzięczny za sugestie dotyczące tego procesu.

Obecnie utrzymuję podstawowy skrypt instalacyjny SQL, aby skonfigurować bazę danych w nowej instalacji. Obejmuje to pełny schemat dla bieżącej wersji; w przypadku nowej instalacji nie są wymagane żadne dalsze działania. Zmiany zachodzące między wydaniami są zapisywane w upgrade-$releasever.sqlskryptach i konieczne jest stopniowe uruchamianie wszystkich skryptów aktualizacji dla wszystkich wydań, które zostały pominięte.

Skrypty powłoki nie są odpowiednie, ponieważ wielu naszych użytkowników działa na hostach bez dostępu do powłoki. Ze względu na inne priorytety, prawdopodobnie nie zmaterializuje się złożony skrypt instalatora / aktualizacji PHP oparty na przeglądarce. Chciałbym jednak zrobić coś ze skryptem PHP opartym na przeglądarce, aby uprościć aktualizacje. Sugestie, jak do tego podejść?

Mój projekt ma plik update.php, który użytkownik uruchamia przez przeglądarkę po zainstalowaniu nowej wersji oprogramowania. Ten skrypt aktualizacji sprawdza numer wersji bazy danych przechowywany w tabeli w aktywnej bazie danych i wykonuje wszelkie operacje modyfikujące bazę danych, które doprowadzą ten schemat bazy danych do najnowszej, w tym aktualizację tego numeru wersji bazy danych.

Drupal CMS ma ciekawe rozwiązanie twojego problemu. Proponuję rzucić okiem na Drupala w ogóle, jeśli tworzysz rozwiązania internetowe za pomocą PHP. To mój ulubiony CMS PHP i będę na tyle stronniczy, by powiedzieć, że jest najlepszy na rynku. ;)

Drupal oferuje dość wyrafinowane opakowanie interakcji z bazą danych. Pozwala to wyodrębnić rzeczywisty typ bazy danych od twórcy modułu, więc tak naprawdę nie obchodzi cię, czy na serwerze działa PostgreSQL, MySQL itp. Możesz również stworzyć własny interfejs. Każdy moduł musi dostarczyć plik module.install, który zawiera hook_schemai hook_install. hook_schemasłuży do deklarowania schematu tabeli dla modułu, podczas hook_installuruchamiania procedury instalacji. Architektura obsługuje również pojęcie aktualizacji, więc jeśli użytkownik ma już zainstalowany moduł, wywoływane są odpowiednie przechwyty aktualizacji i umożliwiają łatwą aktualizację schematu tabeli.

Spójrz: http://drupal.org/node/146862 Nawet jeśli Drupal nie jest dla ciebie, jestem pewien, że możesz nauczyć się czegoś na podstawie ich decyzji architektonicznych.

Zrobiliśmy to, tworząc foldery wersji. W tym folderze umieściliśmy wszystkie skrypty bazy danych. Kiedy nadszedł czas, aby udostępnić to nowemu klientowi, otrzymali najnowszą wersję.

W tym folderze zachowaliśmy również wszystkie skrypty aktualizacji. W ten sposób możemy migrować klienta z wersji x do wersji y.

To nie jest najlepsza metoda ... ale zadziałała dla nas.