Jaka jest najlepsza praktyka wdrażania przy korzystaniu z MODX?

Jest to wygodne, gdy masz wersję aplikacji DEVELOPMENT na komputerze lokalnym i możesz ją wdrożyć na serwerze STAGE do testowania (opcjonalnie), a następnie wdrożyć na serwerze PRODUCTION. Można to zrobić stosunkowo łatwo, gdy istnieje duża dyskrecja kodu i danych w projekcie (na przykład, jeśli przechowujemy cały kod i ustawienia w plikach projektu i danych w bazie danych).Jaka jest najlepsza praktyka wdrażania przy korzystaniu z MODX?

MODX przechowuje szablony, fragmenty itp. W bazie danych. Tak, możemy przenieść ten kod do plików statycznych, a następnie możemy użyć systemu kontroli wersji do śledzenia zmian tych elementów. Ale te mają również wiersze reprezentacyjne w bazie danych. Oznacza to, że musimy zaktualizować bazę danych tak jak poprzednio, jeśli dodaliśmy lub usunęliśmy niektóre elementy.

Wygląda na to, że możemy również uzyskać pewne problemy, jeśli skopiowaliśmy pliki rozszerzeń zamiast instalacji przez menedżera pakietów (ponieważ rozszerzenia często mają własne tabele w DB).

Innym problemem jest to, że aplikacje na DEV i PROD mają różne ustawienia zapisane w plikach (configs) i bazie danych (kontach użytkowników, np.).

Nie widzę jeszcze jasnego sposobu na zorganizowanie iteracyjnego cyklu rozwoju DEV-STAGE-PROD. Tak więc, moje pytania są następujące:

Jakie pliki i tabele bazy danych należy (lub trzeba) skopiować podczas wdrażania?
Jaki jest tryb (zastąp, zignoruj) Czy powinienem to zrobić?
Jaki jest najłatwiejszy i najszybszy sposób na zrobienie tego?

Moim największym zmartwieniem jest posiadanie bazy danych.

P.S. Mówię o wersji "Revolution" MODX, jeśli to ma znaczenie.

Źródło

2013-04-10 Alexander Surin

Mam na myśli sposób na wdrożenie tylko niektórych zmian, a nie całego projektu. W tym przypadku deweloper zwykle ma duże DB po stronie produkcyjnej i małe testowe DB na lokalnym komputerze. Która część bazy danych musi być skopiowana i jaki jest najlepszy sposób na zrobienie tego? Co z konfliktem identyfikatorów zasobów podczas tworzenia nowego zasobu na DEV i ma on ID, który jest już zajęty w PROD? –

Baza danych nie powinna w ogóle zapisywać żadnych informacji o ścieżkach, poprzednie wersje miały miejsce w tabeli modx_workspaces, ale od tego czasu zniknęły [jak wierzę w 2.2.4].

Jeśli martwisz się zmianami adresu URL [dev.mysite.com/stage.mysite.com/production ...], to nie jest - wszystko to znajduje się w pliku .htaccess [kiedyś strona_url ustawienia systemu, ale wydaje się również, że zniknął.]

Jedynym plikiem, którego powinieneś się martwić, to core/config/config.inc.php ~ utwórz 3 różne pliki z różnymi ścieżkami lub po prostu je zastąp, gdy migrować.

mój proces prowadzący do przejścia/aktualizacja/migrację witryn MODx jest:

jasne cache !! smoła cvfz httpdocs.tar.gz httpdocs/ mysqldump -u -p the_database> export.sql

przenieść pliki tar xvfz & zaimportować bazę danych. Warto sprawdzić tabelę modx_workspaves i jeśli korzystałeś ze starszej wersji galerii, sprawdź również, ale większość programistów wydaje się być używanych do NIE przechowywania informacji o ścieżce w tabelach DB & kodu.

Oczywiście, jeśli utwardziłeś swoją instalację, musisz wykonać kilka czynności, ale nic poważnego. [zobacz artykuł "hardening Modx na rtfm.modx.com]

Źródło

2013-04-10 20:48:39

Wygląda na to, że wytłumaczyłeś sposób na wykonanie pełnej kopii aplikacji. Ale co, jeśli mam już ogromną niezależną bazę danych na serwerze produkcyjnym (np. Zawartość generowana przez użytkowników) i małą bazę danych testowych na serwerze DEV? Mogę też mieć tylko jedno konto administratora z prostym hasłem dla DEV i wielu innych kont w PROD (dla menedżerów, autorów itp.). Przypuszczam, że w tym przypadku wymaga częściowego scalenia baz danych, czyż nie? Jak rozwiązać problem z konfliktem identyfikatora zasobu? Jeśli utworzyłem nową stronę na DEV i zamierzam przenieść ją do PROD, nie mam gwarancji, że taki identyfikator jest tam nadal nieobecny. –

Jeśli zamierzasz dodać zasób lub zasoby, dodaj je na żywo w stanie niepublikowanym, jeśli chcesz je najpierw przetestować na kopii zapasowej danych produkcyjnych. Poza tym, modyfikując fragmenty, szablony, porcje, telewizory, użytkownika, role, grupy lub zasady. najlepiej jest ponownie, przetestuj na kopii produkcyjnej, a następnie zaimplementuj. Podobnie jak w przypadku każdego problemu, problem polega na zmianie danych na żywo podczas pracy, jeśli musisz przetasować zmiany z dev, będziesz musiał przekopać się przez schematy xpdo, dowiedzieć się, jakie tabele mogą/zostaną zmienione i napisz samemu niektóre skrypty importu/eksportu. –

myślę co szukasz jest ten plugin (w zależności od wersji): MODx

https://github.com/digitalbutter/MODX-Mirror

https://github.com/digitalbutter/FEM

Wszystkie kawałki, fragmenty itd znajdują się na dysku . Wszelkie zmiany wprowadzone w plikach wywołają odpowiednie zmiany w bazie danych bez konieczności wykonywania pełnego importu/ponownego importu SQL. Umożliwi to dowolny system kontroli wersji/środowisko rozproszonego projektowania/zautomatyzowane wdrażanie.

Źródło

2014-03-20 19:32:47 Liquinaut

Jaka jest najlepsza praktyka wdrażania przy korzystaniu z MODX?

Odpowiedz

Powiązane problemy