2008-11-12 17 views
32

W standardowych projektach opartych na php lub kodach źródłowych z łatwością przechowujemy cały kod w SVN, a każdy programista może wykupić własną kopię i współpracować nad tym samym kodem.Strategia kontroli źródła Drupal?

Podczas pracy nad stroną Drupal większość pracy jest w "konfiguracji". Poza tematem i modułami tak naprawdę nie masz żadnego "kodu źródłowego". W jaki sposób uruchamiasz wiele instancji tej samej witryny, aby programiści mogli jednocześnie pracować, a jednocześnie dzielić się swoimi dziełami?

Przykład Scenariusz:

Uruchamiamy wstępną wersję Drupal witryny z treścią typu „X” stworzył. Początkowo uruchamiamy także widok na stronie, który zawiera listę wszystkich węzłów typu "X" w porządku chronologicznym. Klient rozpoczyna korzystanie z witryny, dodaje zawartość, elementy menu itp.

Następnym wydaniem jest dodanie możliwości przeszukiwania tego widoku przez użytkownika. Konfiguracja tego jest jednak zawarta w bazie danych. Możemy skopiować produkcyjną bazę danych do naszej wersji rozwojowej, aby uzyskać najnowsze dane, podczas gdy pracujemy nad zmianą widoku. W tym czasie klient nadal może aktualizować witrynę, co powoduje, że nasza baza danych dla programistów nie jest zsynchronizowana. Kiedy jesteśmy gotowi przenieść nowy widok do produkcji, czy jest łatwiejszy sposób na to, niż ręczne powtórzenie kroków, aby skonfigurować go na instalacji produkcyjnej?

+0

hmm, czy możesz trochę wyjaśnić? czy w zasadzie mówisz o ustawieniach takich jak niektóre moduły? – Owen

+0

Naprawdę dobre pytanie, dzięki. – sepehr

Odpowiedz

11

Myślę, że dobrą strategią jest użycie interfejsu API profilu instalacji. Za pomocą API do profilu instalacji możesz zrobić większość rzeczy, które używają narzędzi administracyjnych Drupala. Większość podstawowych formularzy po prostu ustawia zmienne w tabeli zmiennych. Aby móc sensownie przetworzyć zawartość bazy danych bez treści, np.konfiguracja jest mądra, aby korzystać z funkcji aktualizacji.

Na mojej stronie mamy moduł "ec", który ma bardzo niewiele oprócz tego, że zawiera plik aktualizacji ec.install, np. ec_update_6001()

Twoja główna funkcja instalacji może zająć się faktycznie uruchomieniem aktualizacji nowych instalacji, aby zaktualizować swoje moduły.

function ec_install() { 
    $ret = array(); 
    $num = 0; 
    while (1) { 
    $version = 6000 + $num; 
    $funcname = 'ec_update_' . $version; 
    if (function_exists($funcname)) { 
    $ret[] = $funcname(); 
    $num++; 
    } else { 
    break; 
    } 
    } 
return $ret; 
} 

Funkcja aktualizacji lub dwie próbki z naszego rzeczywistego pliku teraz śledzić

// Create editor role and set permissions for comment module 
function ec_update_6000() { 
    install_include(array('user')); 
    $editor_rid = install_add_role('editor'); 
    install_add_permissions(DRUPAL_ANONYMOUS_RID, array('access comments')); 
    install_add_permissions(DRUPAL_AUTHENTICATED_RID, array('access comments', 'post comments', 'post comments without approval')); 
    install_add_permissions($editor_rid, array('administer comments', 'administer nodes')); 
    return array(); 
} 
// Enable the pirc theme. 
function ec_update_6001() { 
    install_include(array('system')); 
    // TODO: line below is not working due to a bug in Install Profile API. See http://drupal.org/node/316789. 
    install_enable_theme('pirc'); 
    return array(); 
} 

// Add the content types for article and mtblog 
function ec_update_6002() { 
    install_include(array('node')); 
    $props = array(
    'description' => 'Historical Movable Type blog entries', 
); 
    install_create_content_type('mtblog', 'MT Blog entry', $props); 
    $props = array(
    'description' => 'Article', 
); 
install_create_content_type('article', 'Article', $props); 
return array(); 
} 

Skutecznie to przede wszystkim rozwiązuje problem wersjonowania kodu z bazami danych i Drupal. Używamy go intensywnie. Pozwala nam na promowanie nowego kodu, który zmienia konfigurację bazy danych bez konieczności ponownego importowania bazy danych lub wprowadzania zmian na żywo. Oznacza to również, że możemy właściwie testować wersje bez obaw o ukryte zmiany w bazie danych.

Wreszcie cck i widoki wspierają to podejście. Zobacz ten fragment kodu:

// Enable CCK modules, add CCK types for Articles in prep for first stage of migration, 
// enable body for article, enable migration modules. 
function ec_update_6023() { 
    $ret = array(); 
    drupal_install_modules(array('content', 'content_copy', 'text', 'number', 'optionwidgets')); 
    install_include(array('content', 'content_copy')); 
    install_content_copy_import_from_file(drupal_get_path('module', 'ec') . '/' . 'article.type', 'article'); 
    $sql = "UPDATE {node_type} SET body_label='Body', has_body=1 
    WHERE type = 'article'"; 
    $ret[] = update_sql($sql); 
    return $ret; 
} 
11

Jakiś czas temu napisałem artykuł o dobrych praktykach painless Drupal revision control with CVS and Subversion.

Niestety, nadal istnieje problem z kontrolą źródła bazy danych, jak już zauważyłeś. Jest kilka sugerowanych metod, o których wspominam w additional post.

+0

Linki są martwe i nie mogę znaleźć drugiej wersji buforowanej przez Google (re: źródło kontrolujące bazę danych). Czy wiesz, kiedy artykuł zostanie utworzony ponownie lub gdziekolwiek indziej mogę go wyświetlić? Twoje zdrowie. – jackocnr

+1

Artykuł został przeniesiony do http://nicksergeant.com/2007/pless-drupal-revision-control-with-cvs-and-subversion-on-a-shared-host/, a dodatkowy post znajduje się na http: //nicksergeant.com/2008/my-thoughts-on-small-scale-drupal-development-to-production-environments-with-cvs-and-subversion/. –

+0

@ Karolina, dzięki za aktualizację linków – electblake

1

Możesz zaoszczędzić sobie trochę trudu związanego z konfigurowaniem i pracą z SVN, jak opisano w artykule Nicka, jeśli korzystasz z właściwości svn:externals. Dzięki temu twoja lokalna wersja Drupala będzie aktualizowana automatycznie wraz z określonym oddziałem Drupala i możesz używać dokładnie tego samego mechanizmu dla swoich modułów. Dodatkowo, ponieważ SVN odczyta definicje zewnętrznych z pliku, możesz umieścić je również pod kontrolą wersji!

Nie sądzę, że CVS ma równoważną funkcję. Jednak całkiem łatwo jest napisać prosty skrypt, który automatycznie zainstaluje moduł Drupal, pobierając tylko URL (zrobiłem to, aby moja strona Drupala była aktualna).

W odniesieniu do wersjonowania bazy danych problem ten jest trudniejszy do rozwiązania. Sugerowałbym wyeksportowanie "zapasowej" bazy danych Drupal do pliku SQL i umieszczenie go pod kontrolą wersji. Każdy programista będzie miał własny lokalny prywatny serwer bazy danych do użycia. Następnie można udostępnić skrypt, który przywróci określoną bazę danych do wersji magazynowej zawartej w pliku SQL.

Jako przykład tego, jak ten problem rozwiązano w inny sposób, opiszę sytuację w pracy. Pracuję nad aplikacją internetową; nie korzysta z bazy danych, więc nie ma takich problemów. Naszym sposobem na obejście powtarzającej się konfiguracji witryn jest przebudowanie z kontroli źródła i zapewnienie programu umożliwiającego automatyczne wdrażanie witryn. Program jest również używany przez naszych klientów jako sposób na tworzenie witryn.

1

Niektóre moduły, takie jak CCK i Widoki, pozwalają eksportować i importować swoje dane konfiguracyjne jako tekst. Możesz zapisać te reprezentacje tekstowe w systemie kontroli źródła.

7

Przeniesienie ustawień Drupal z bazy danych do kodu w szybkim tempie. Dwa moduły, które naprawdę pomagają w tej dziedzinie to:

Features - Umożliwia gromadzenie elementów takich jak typy zawartości, taksonomia, widoki, a nawet kanały. Używamy tego bardzo skutecznie i umożliwiło to udostępnianie zmian między programistami.

Strongarm - Umożliwia przechowywanie i eksport zmiennej za pomocą powyższego modułu. Zrobiłem kilka testów z tym modułem, ale nie używamy go, ponieważ nie potrzebowaliśmy tej funkcji.

Rozwiązują one największe problemy z utrzymaniem konfiguracji witryny w bazie danych. Nie są one jednak doskonałe. . . znaleźliśmy moduły, które nie były obsługiwane lub obsługiwane nieprawidłowo.

1

Niestety, po prostu nie ma tu dobrego/prostego rozwiązania. Problem jest niefortunnym efektem ubocznym architektury nie tylko Drupala, ale wszystkich CMS typu szkieletowego, w których aplikacje są definiowane tak samo przez konfigurację (tj. Dane przechowywane w bazie danych), jak przez kod źródłowy. Żadna z dwóch opcji zarządzania danymi konfiguracji nie jest świetna. Pierwszym z nich jest to, co robisz: zdefiniuj pojedynczy db jako kanoniczny (tj. Db produkcyjny) i pozwól programistom pracować lokalnie z migawką bazy produkcyjnej i "scalaj" nowe informacje konfiguracyjne w produkcyjnym środowisku db przez ręczną konfigurację przez witrynę produkcyjną interfejs administratora. W przypadku dobrze zdefiniowanych podsystemów - tzn. Widoków - możesz skorzystać z opracowanych funkcji importowania/eksportowania w celu ułatwienia właśnie tego rodzaju migracji konfiguracji. Druga opcja - tj. Automatyzacja, którą myślę, że szukasz - jest trudna, ale może być warta - lub wymagana - w przypadku dużych projektów z budżetem na złożoną automatyzację projektów: zanurkuj głęboko w strukturę systemu/modułu db i rozwijaj niestandardowe skrypty do scal nowe dane konfiguracyjne na poziomie tabeli/rekordu w db produkcyjnym, powiedzmy, jako część nocnej "kompilacji" najnowszej bazy danych. Obawiam się, że po prostu nie ma żadnego rozwiązania pośredniego.

Pod względem kontroli wersji dla historycznego śledzenia danych konfiguracyjnych, moduł taki jak backup_migrate umożliwia wykonywanie automatycznych zrzutów SQL bazy danych. Możesz wybrać, które tabele są zrzucane, definiując "profil" kopii zapasowej i utworzyć taki, który pozostawił dużą zawartość, rejestrowanie i buforowanie tabel (np. Węzeł, zawartość cache_content, watchdog) ze zrzutu, dzięki czemu pozostało ci łatwiejsze do zarządzania porwanie na potrzeby wersjonowania . Niektóre proste skrypty na serwerze lub w innym miejscu mogą pobrać najnowszy zrzut i dodać go do repozytorium.

0

Drupal obsługuje teraz konfigurację eksportowalną, która pozwala przenieść większość konfiguracji witryny do kodu. Możliwości eksportu są obsługiwane dla zmiennych konfiguracyjnych, widoków, typu zawartości, pól, formatów wejściowych itp. Za pomocą modułu features.

Możesz także zarządzać początkową, nie eksportowalną konfiguracją i zmianami konfiguracji za pośrednictwem centralnego profilu lub modułu. Użyj go, aby włączyć moduł, utworzyć użytkownika itp.

Zobacz prezentację The Development -> Staging -> Production Workflow Problem in Drupal i Code driven development: using Features effectively in Drupal 6 and 7.

Powiązane problemy