Jak zarządzać programowaniem opartym na współpracy w witrynie Drupal?

Współpracuję z innym programistą w witrynie Drupal. Staraliśmy się znaleźć dobry sposób na pracę nad różnymi częściami witryny jednocześnie, nie wchodząc sobie w drogę. Próbowaliśmy pracować nad tym samym wystąpieniem programistycznym witryny, ale często stawiamy sobie nawzajem palce lub obniżamy witrynę z powodu złego kodu uniemożliwiającego innym pracę do momentu rozwiązania problemu. Więc przenieśliśmy się do oddzielnych instancji programistycznych. Ale teraz wielkim problemem jest połączenie naszej pracy w jedną instancję witryny. W zasadzie powtarzamy wszystko na udostępnionej kopii.

Największym problemem, jaki mamy teraz, jest to, w jaki sposób scalamy zmiany bazy danych i jak włączamy bazę danych do naszego systemu kontroli źródła? Pliki są łatwe, wystarczy śledzić je wszystkie (używamy git) i łączyć naszą pracę, rozwiązując konflikty w razie potrzeby. Ale to tak naprawdę nie działa z bazą danych. Możemy zrobić zrzut SQL i dołączyć go do naszego repozytorium git, ale tak naprawdę nie możemy scalić baz danych. Moduł Funkcje pomaga trochę, pozwalając nam eksportować część naszej pracy bazy danych w kodzie, które mogą być następnie wersjonowanym i połączone. Jednak nawet blisko wszystkiego nie obsługuje funkcji. Więc...

• Jakie kroki możemy podjąć, aby łatwo połączyć zmiany w naszej bazie danych?

• Jak powinniśmy zaktualizować bazę danych (czy dobrym pomysłem jest umieszczenie pliku zrzutu w git)?

• Czy są dostępne jakieś moduły, które pomagają rozwiązać niektóre z tych problemów?

• Czy też utknęliśmy w pracy nad tą samą kopią strony? (proszę, więc nie)

Edycja: W komentarzach omawialiśmy, czego nie można wyeksportować za pomocą funkcji, a jedną z nich były taksonomie. Jest na to jeszcze jedno pytanie .

Jest to zmiana przepływu pracy, ale powinieneś przyzwyczaić się do pracy nad świeżym zrzutem bazy danych na żywo. Istnieją trzy sposoby wprowadzenia zmian w bazie danych.

1. Funkcje. To nie będzie działać na wszystko, ale na wiele rzeczy, których potrzebujesz.
2. zaktualizuj haki. Gdy funkcje nie działają, możesz na stałe zakodować różne elementy w haku aktualizacji posiadanego modułu.
3. Zmiany ręczne. Używaj oszczędnie. Niektóre rzeczy nie przychodzą naturalnie do funkcji lub aktualizacji zaczepów i są o wiele łatwiejsze do zrobienia ręcznie. Jest to ostateczność, ale czasami jest to jedyna piracka metoda.

Jeśli możesz. Kilka razy dziennie zrób nowy zrzut i przetestuj kompilację, powinieneś mieć mniej problemów z integracją.

Odpowiedziałem na podobne pytanie i zamierzam je nieco dostosować, aby odpowiedzieć na twoje pytanie tutaj. Moja sugestia roota polega na tym, że masz serwer programistyczny / testowy, w którym zmiany kodu są sprawdzane za pomocą systemu ciągłej integracji (np. Co 5 minut). Tak więc na komputerze lokalnym pracujesz tylko nad jednym żądaniem funkcji / raportem o błędzie na raz, pamiętając, aby wyraźnie oddzielić to zadanie od innych, nad którymi ludzie mogą pracować i komunikować się z kolegami z zespołu, nad którymi pracujesz (redmine lub inne śledzenie błędów jest do tego świetne). Następnie zatwierdzasz zmiany regularnie i są one ściągane na serwer deweloperów / pośredników, podobnie jak twoi koledzy z drużyny. Idealnie, jeśli masz wbudowane testy jednostkowe w swoim systemie ciągłej integracji (przy okazji bardzo polecam luntbuild lub QuickBuild, ale Hudson również działa). System CI lub testy mogą automatycznie wykryć wszelkie konflikty, które mogłeś wprowadzić, jak tylko wpiszesz swój kod. Jeśli musisz wprowadzić zmiany treści (nie-kodowe), robisz to na serwerze deweloperskim / pomostowym.

Jeśli chodzi o część bazy danych, w zasadzie przyjąłem tutaj dwie szkoły myślenia (trzecia szkoła myśli, robiąc różnice w bazach danych, nie będę dyskutować, ponieważ złożoność jest dość wysoka).

1) Wdróż, usuwając produkcyjną bazę danych i importując mysqldump programistycznej bazy danych. Opcjonalnie uruchom wcześniej wyrażenie regularne znajdź / zamień na wszelkich bezwzględnie zakodowanych linkach bezwzględnych, które odwołują się do adresu URL dewelopera w zrzutie SQL. Po zaimportowaniu bazy danych dev do prod, automatycznie uruchom następnie instrukcje SQL (zwykle za pomocą skryptu), aby zmienić wszelkie ustawienia, które są inne dla prod niż dev (np. Może masz w tabeli zmiennych niektóre ustawienia połączeń do łączenia się z systemami zewnętrznymi, które musisz zmień punkt na zewnętrzne systemy prod zamiast na wersję deweloperską).

2) Użyj modułu Funkcje, jak wspomniała budda, do ustawień administratora i użyj modułu Eksport węzłów do eksportu / importu zawartości w połączeniu z modułem Usuń wszystko. Tak więc przepływ pracy to:

użyj export_węzła i funkcji, aby wyeksportować węzły / funkcje do plików Opcjonalnie (i mam nadzieję) kontrola wersji Załaduj pliki do systemu prod Użyj interfejsu drush lub administratora, aby załadować funkcje Użyj interfejsu drush delete-all lub interfejsu administratora, aby usunąć wszystkie węzły typów, które chcesz zaimportować Użyj drush ne-import lub interfejsu administratora, aby zaimportować węzły z wyeksportowanego pliku węzłów. Jedna uwaga, zdecydowanie zalecam przyjęcie standardowego przepływu pracy, w którym treść idzie tylko w jednym kierunku. Albo Dev -> Prod lub Prod -> Dev (wolę ten).

Zrobiłem to i robię to na niektórych dużych systemach, z dość dobrymi wynikami, ale zawsze będzie wiele sposobów pokrojenia tego jabłka, wybierz ten, który najbardziej Ci odpowiada.

Chociaż jest to stare pytanie z zaakceptowaną odpowiedzią, uważam, że jest jeszcze miejsce na kolejne.

Po pierwsze, pozwól mi powiedzieć z góry, że nie uważam, że Funkcje są odpowiednim narzędziem do tego zadania i powinien zaproponować alternatywny zestaw narzędzi.

Warunkiem współpracy zespołu jest posiadanie serwera pomostowego do testowania wersji rozwojowych projektu, który jest niezależny od serwera produkcyjnego. Cały kod rozwoju jest testowany na serwerze pomostowym i przekazywany na serwer produkcyjny tylko wtedy, gdy jest stabilny i gotowy do wdrożenia. Jednak programiści nie działają bezpośrednio na serwerze pomostowym. Każdy programista pracuje na własnym stanowisku roboczym, korzystając z kontroli wersji i zarządzania kodem źródłowym (SCM) w celu skoordynowania swojej pracy z resztą zespołu.

System SCM pozwala członkom zespołu pracować równolegle nad różnymi gałęziami kodu bez ingerencji między sobą. Tylko mistrz oddziału jest wdrażany na serwerze pomostowym w celach testowych.

Aby utworzyć kopię lustrzaną bazy danych między produkcją, stagingiem i stacjami roboczymi, istnieje moduł o nazwie Kopia zapasowa i migracja, którego można użyć, jeśli korzystasz z hostingu współdzielonego i nie zarządzasz własną bazą danych. Jeśli zarządzasz własnym serwerem bazy danych, jest to jedyny projekt na tym serwerze i korzystasz z mysql , przydatne są następujące pary poleceń:

Rzucić:

mysqldump --all-databases --opt -u root -p > DUMP.sql

Przywrócić:

mysql -u root -p < DUMP.sql

Jeśli twoja nie jest jedyną bazą danych na tym serwerze, napisz skrypt jakiejś wersji mysqldump(lub równoważnej, jeśli nie używasz mysql ), która zrzuca tylko twoje bazy danych.

Utwórz zasadę, że jest to baza danych na serwerze produkcyjnym, który jest nadrzędny. Serwer pomostowy i stacje robocze powinny być kopią produkcyjnej bazy danych, a nie odwrotnie.

Zauważ, że Drupal 7 zachowuje wszystkie ustawienia administratora w bazie danych. Oznacza to, że tworzenie kopii lustrzanej bazy danych między witryną produkcyjną, witryną pomostową i stacjami roboczymi spowoduje migrację ustawień admimacji bez funkcji .

Teraz, aby udostępnić kod:

Standardowym sposobem udostępniania kodu członkom zespołu programistów jest korzystanie z systemu SCM. Drupal jest domyślnie zarządzany za pomocą takiego systemu o nazwie git .

Git pozwala na korzystanie z lokalnych lub zdalnych repozytoriów. Jeśli członkowie zespołu znajdują się w tej samej przestrzeni fizycznej, możesz skonfigurować lokalne repozytorium na serwerze pomostowym. Jeśli są one rozproszone geograficznie, możesz skonfigurować zdalne repozytorium. Jeśli nie masz nic przeciwko innym, którzy mają dostęp do odczytu w opracowywanym kodzie, możesz użyć piaskownicy na Drupal.org jako zdalnego repozytorium. Możesz także użyć obszaru projektu na GitHub . GitHub to nie tylko repozytorium, ale zawiera pewne narzędzia do współpracy i umożliwia repozytoria zarówno publiczne, jak i prywatne.

Zasadniczo system SCM pozwala członkom zespołu pobierać kod źródłowy i dokumentację z repozytorium udostępnianego przez członków zespołu i wcisnąć go ponownie po pracy. SCM śledzi zmiany, a jeśli wystąpi konflikt (np. Ktoś spróbuje wypchnąć kod, który nie zawiera zmian, które zatwierdził inny członek zespołu), poinformuje cię, a także zasugeruje sposób rozwiązania tego konfliktu.

Zwykle przy serdecznej komunikacji dotyczącej podziału zadań między członków zespołu nie będzie konfliktów. Ale dzięki systemowi SCM, który śledzi rzeczy, konflikty stają się możliwe do rozwiązania, nawet jeśli popełnione zostaną błędy lub komunikacja się nie powiedzie.

Istnieje wiele samouczków na temat rozpoczynania pracy z git (GIYF) i korzystania z niego. Dwa polecę: strona internetowa git-scm i Pro Git autorstwa Scott Chacon.