Jak scalić zmiany z wersji rozwojowej witryny do działającej witryny bez utraty nowej zawartości?

40

Jaka jest najlepsza procedura łączenia pracy nad wersją rozwojową witryny z kopią produkcyjną na żywo? Często do witryny dodawano wiele nowych treści, odkąd rozpoczęto prace nad najnowszymi funkcjami. Większość dodatków do witryny będzie wymagać zmian w bazie danych. Kopiowanie nowych plików jest więc łatwe, ale co z bazą danych? Jak scalić zmiany z istniejącą produkcyjną bazą danych bez utraty nowej zawartości, która została dodana od ostatniej aktualizacji witryny produkcyjnej? Czy są jakieś moduły, które mogą w tym pomóc?

database updating

— Chaulky
źródło

2

Usuń zamieszanie: Scal i migruj to dwa różne słowa. Użyłeś obu w swoim pytaniu. Jeśli działająca witryna jest pusta, musisz przeprowadzić migrację kopii programistycznej do działającej witryny / hosta. Jeśli witryna na żywo ma już zawartość, należy scalić nową zawartość z kopii programistycznej do strony na żywo (scalanie jest nieco trudne). Co musisz zrobić?

— user931,

16

Aby zapoznać się z typami treści, widokami i zmianami struktury w witrynie deweloperów, skorzystaj z opcji Funkcje, aby wyeksportować bazę danych do kodu.

W przypadku migracji treści istnieje wiele opcji, ale nie ma jednego solidnego rozwiązania. Jednym z przykładów jest pakiet wdrażania .

— budda
źródło

pakiet Demployment zdecydowanie wygląda interesująco, choć wciąż znajduje się w Dev (jeszcze nawet Beta). Użyłeś go sam? Czy wiesz coś, czego by to nie obejmowało?

— Chaulky

2

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

1) Wdróż, upuszczają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 zrzucie 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ł budda, do ustawień administratora i użyj modułu Eksportuj węzeł do eksportu / importu zawartości w połączeniu z modułem Usuń wszystko . 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 admin, aby załadować funkcje
Użyj 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.

— koderintherye
źródło

W opcji 1, w jaki sposób odtwarzasz zawartość dodaną do działającej witryny, której nie ma w witrynie deweloperskiej? Wygląda na to, że nadpisujesz to wszystko za pomocą dev db, a następnie możesz zmienić niektóre ustawienia / zmienne. Jakiej szkoły myśli używasz obecnie na swoich stronach? Jakieś zalety i wady każdego podejścia?

— Chaulky,

W opcji 1 używamy teraz node_export do regularnego wysyłania treści (po usunięciu poprzedniej zawartości). Kiedyś wprowadzaliśmy zmiany treści zarówno dla deweloperów, jak i prod. Jest to w rzeczywistości powszechny scenariusz w kilku miejscach, które widziałem, choć oczywiście nie jest idealny. Właśnie dlatego dodaję, przyjmuję kierunek i trzymam się go, albo treść idzie dev -> prod lub prod -> dev, ale staram się nie robić obu. I tak, w zasadzie nadpisujemy, chociaż bardziej przypominamy kasowanie i odbudowywanie. W mojej nowej pracy wykonujemy numer 2, w mojej starej pracy wykonaliśmy numer 1, ale przenosimy się na numer 2 (nadal się z nimi konsultuję).

— coderintherye

1

Zrzuć bazy danych kopii witryny na żywo i kopii rozwojowej witryny w pliku SQL (użyj tych samych parametrów i ustawień dla obu zrzutów).
Następnie porównaj oba pliki SQL za pomocą małego narzędzia do porównywania ExamDiff . Wyświetli różnice plików obok siebie w różnych kolorach. Możesz również bezpośrednio przejść do różnic (bez przewijania). Sprawdź różnice i dodaj / edytuj wiersze do pliku SQL działającej witryny. Upewnij się, że w tym pliku nie ma bezwzględnej ścieżki / adresu URL środowiska programistycznego. To już koniec! Czas przywrócić bazę danych na żywo.
Ułatw sobie życie:W pierwszym kroku zrzuć tylko te tabele, które zostały zmienione. Na przykład, jeśli edytowałeś moduł w kopii rozwojowej, który jest skierowany na osobną tabelę, zrzuć tylko tę tabelę. Jeśli nie masz pewności co do konkretnej tabeli, zrzut całej bazy danych jest w porządku.

— użytkownik931
źródło

Ta technika ma poważne ograniczenia w niektórych ważnych okolicznościach. Na przykład, jeśli witryna programistyczna ma nowe węzły, obie bazy danych będą zawierały wpisy o tych samych identyfikatorach węzłów i nie będzie możliwe rozpoznanie odniesień i scalenie ich z zrzutu tekstowego bazy danych SQL. Ten rodzaj operacji jest lepiej obsługiwany za pomocą funkcji i wdrażania, jak wspomniano w innych odpowiedziach.

— greg_1_anderson