tło

Zbliżam się do końcowych etapów budowy mojej pierwszej dość dużej witryny WordPress, a teraz napotykam pewne tarcia. W przeważającej części witryna została opracowana na moim komputerze lokalnym i chciałbym przekazać zmiany do serwera pomostowego w celu przejrzenia (więcej informacji na ten temat można znaleźć w tym pytaniu ). Rozwiązanie, z którym się skończyłem, działało całkiem dobrze, kiedy to tylko ja edytowałem treść, ale teraz niektóre inne osoby edytują treść, a ja wciąż mam funkcje do dodania. Pomysł polegał na tym, że moglibyśmy szybciej załatwić sprawę, gdyby funkcje i zawartość były z sobą połączone ... ale teraz nie jestem tego taki pewien.

Obecnie w bazie danych na serwerze pomostowym jest inna zawartość niż na moim komputerze lokalnym. To samo w sobie jest w porządku, ponieważ nie potrzebuję ostatecznej kopii treści na moim komputerze lokalnym, ale muszę zrobić więcej prac rozwojowych, które wpłyną na bazę danych (zainstaluj / napisz kilka wtyczek, które potrzebują własnych tabel).

Moje pytanie brzmi:

Czy istnieje prosty sposób na zautomatyzowanie łączenia baz danych, aby wiele osób mogło pracować nad instalacją WordPress? Mógłbym oczywiście po prostu wyeksportować tabele, które, jak wiem , zmieniły się na moim komputerze lokalnym i wypchnąć je na serwer pomostowy, ale możliwe jest, że na serwerze pomostowym są również rzeczy, które chciałbym obniżyć. Mógłbym pobrać dane SQL obu baz danych i różnicować je ... ale to wydaje się nudne i hackerskie. Zastanawiam się, czy jest to problem rozwiązany przez innych; jeśli istnieje akceptowany przez społeczność sposób radzenia sobie z tego rodzaju sprawami.

Dzięki!

Zadałem to pytanie ponad rok temu iw tym czasie dodaliśmy więcej osób do naszego zespołu i opracowaliśmy znacznie większą liczbę witryn w WordPress. Chciałem przejść przez nasz proces, aby pomóc komukolwiek innemu.

Wszystko w Git

To było coś, co robiłem, nawet gdy zadawałem pytanie, ale dobrze jest to podkreślić. Korzystanie z Git nie tylko pomogło nam zwiększyć produktywność, ale także kilkakrotnie uratowało nasze kolektywne oceny.

Czy kiedykolwiek musiałeś dokonywać poważnych remontów strukturalnych na budowie, uzyskiwać zgodę klienta na te renowacje, a jednocześnie dokonywać drobnych aktualizacji wersji nieodnowionej? Mamy i Git, pozwól nam to zrobić. Opisanie tej konfiguracji byłoby trochę skomplikowane, ale podstawowe jest to, że stworzyliśmy nową gałąź, przeciągnęliśmy tę gałąź na serwer i dołączyliśmy subdomenę do tej gałęzi.

Zostaliśmy również uratowani przez Git. To oczywiście pozwala nam przywracać zmiany, co jest świetne, ale pozwala nam także przywracać stare wersje plików. Oznacza to, że jeśli klient zapyta: „Pamiętasz, jak działała ta część witryny około rok temu? Czy możemy to przywrócić?”, Odpowiedź brzmi „tak” - nawet jeśli pytana osoba nie brała udziału w tym projekcie przez rok temu.

Oprócz tych punktów oznacza to również, że nigdy nie utkniemy bez potrzebnych plików. Zawsze możemy pobrać najnowszą wersję strony z dowolnego komputera i rozpocząć wprowadzanie zmian.

Do wdrożenia użyj Git

Prowadzimy hosting WordPress w Media Temple i bardzo nam się podobają. Nie są najtańszym dostawcą, ale ich usługa jest doskonała, a ich serwery są naprawdę dobrze skonfigurowane. Zapewniają również domyślnie Git. Oznacza to, że możemy skonfigurować serwer jako repozytorium Git i w ten sposób pobierać zmiany zamiast używać SFTP. Oznacza to również, że wykonywanie pracy na serwerze nie jest zagrożone nadpisaniem (ponieważ zmiany te można po prostu scalić i przenieść z powrotem).

Ponieważ używamy BitBucket jako naszego hosta Git, tutaj wymaga trochę dodatkowej pracy. Przede wszystkim używamy plików .ssh / config , abyśmy mogli wpisywać takie rzeczy, jak ssh sitenamelogowanie do naszych serwerów (używamy również SSH bez hasła , co czyni to bardzo łatwym). Zawsze upewniamy się, że zawsze używamy haseł ssh (Mac OS X ułatwia to, umożliwiając przechowywanie hasła w Keychain.app ). Na koniec dodajemy wiersz ForwardAgent do wpisu .ssh / config na hostach, z których chcemy pobierać. Oznacza to, że potrzebujemy tylko klucza publicznego SSH każdej osoby w BitBucket, a nie klucza publicznego każdego serwera. Dbamy również o to, aby .gitkatalog był o jeden katalog powyżej publicznego katalogu HTML.

Zautomatyzowane zrzuty bazy danych

Gdy serwer jest w trybie produkcyjnym , na wszelki wypadek zapewniamy automatyczne wykonanie kopii zapasowej naszej bazy danych .

Każdy ma własną konfigurację wp-config

Ponieważ wszyscy mamy własne nazwy użytkowników i hasła do lokalnych baz danych, a ponieważ moglibyśmy używać różnych nazw i mechanizmów udostępniania, każdy z nas zachowuje własny plik wp-config. Każdy z nich jest przechowywany w Git pod nazwą podobną wp-config-gavin.php, a kiedy chcemy użyć tej konfiguracji, dowiązujemy ją symboliczniewp-config.php (co jest ignorowane przez Git przy użyciu .gitignore ).

To pozwala nam również zastąpić siteurlopcję w wp_optionstabeli bazy danych w następujący sposób:

define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');

To uniemożliwia WordPressowi przeglądanie bazy danych lokalizacji serwera i oznacza, że ​​nie ma dziwnych różnic w lokalizacji między instalacjami lokalnymi a serwerowymi.

Ostatnia uwaga na temat plików wp-config.php: pamiętaj, aby przechowywać je nad publicznym katalogiem HTML i uczynić uprawnienia tylko do odczytu dla użytkownika sieci . To ogromna różnica w zabezpieczaniu WordPressa.

Problem z bazą danych

Wreszcie, sedno sprawy.

Musiałem zaakceptować to, że używając WordPress, nie ma dobrego sposobu na „scalenie” zmian w bazie danych. Zamiast tego musieliśmy opracować zasady postępowania, aby rozwiązać ten problem. Zasady są dość proste i do tej pory dobrze nam służyły.

Podczas opracowywania jest jedna osoba, która „jest właścicielem” witryny. Ta osoba zwykle wykonuje konfigurację (zebranie pakietu hostingowego, rozpoczęcie projektu Basecamp, krojenie projektu itp.). Gdy ta osoba znajdzie się w rozsądnym punkcie, zrzuć bazę danych do instalacji WordPress i umieść ją w Git. Od tego momentu każdy programista używa zrzutu bazy danych, a właściciel jest jedynym, który wprowadza zmiany w bazie danych.

Gdy kompilacja witryny pójdzie trochę dalej, witryna zostanie umieszczona na serwerze. Od tego momentu baza danych serwera jest kanoniczna. Wszyscy (łącznie z właścicielem) muszą wprowadzić wszystkie zmiany w bazie danych na serwerze i usunąć te zmiany w celu rozwoju lokalnego i testowania.

Ten proces nie jest idealny. Nadal możliwe jest, że ktoś będzie musiał wprowadzić zmiany w backendie WordPress lokalnie podczas programowania, a następnie będzie musiał wprowadzić te zmiany ponownie w produkcji. Odkryliśmy jednak, że takie rzeczy są rzadkie i ten proces działa dla nas całkiem dobrze.

Pracuję nad taką instalacją i wcześniej odpowiadałem na takie pytania . Poniżej znajduje się moja preferowana konfiguracja do tego rodzaju pracy. Ponieważ chcesz scalić bazy danych zamiast zastąpić istniejącą, dodam do nich ostrzeżenie, aby nie używać flagi --add-drop-table podczas robienia zrzutu MySQL.

• Krok 1. Mysqldump swoją bazę danych programowania
• Krok 2. Zamień wszystkie wystąpienia development.domain.com na production.domain.com ^^
• Krok 3. Zaloguj się do MySQL, uruchom polecenie SOURCE, aby zaimportować dane np source /path/to/file

^^ Jak zastąpić wszystkie wystąpienia starej domeny nową: (1) Skopiuj poniższy skrypt. (2) chmod +xto. (3) Uruchom.

Stosowanie: ./script.sh development-dump.sql > production-dump.sql

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g

W tej chwili eksperymentuję z różnymi rozwiązaniami tego samego problemu. To zdecydowanie trudne.

Moje obecne rozwiązanie polega na wykonaniu lokalnego zrzutu mysql przy użyciu flagi --skip-Extended-Insert. Uważam, że ta flaga powoduje generowanie instrukcji wstawiania rekordu dla każdego wiersza bazy danych, dzięki czemu zrzut jest bardziej przyjazny dla scalania. Podniosłem tę sztuczkę z tego artykułu: http://www.viget.com/extend/backup-your-database-in-git/ .

Następnie kontroluję źródło wynikowego pliku .sql przy użyciu Git wraz z plikami źródłowymi witryny. Gdy inny programista usuwa zmiany kodu, dołącza się do niego plik .sql. Następnie importuje ten plik do swojej lokalnej wersji bazy danych. Obie skonfigurowaliśmy nasze lokalne bazy danych w ten sam sposób na obu komputerach, używając MAMP, więc nie ma potrzeby wyszukiwania i zastępowania.

Wystąpiły problemy z scalaniem, dlatego staramy się stosować podejście „na zmianę” do wszystkiego, co spowoduje zmianę bazy danych. Zanim zrobię cokolwiek w Wordpressie, które zmieni bazę danych, upewniam się, że sprawdził na swoim najnowszym zrzutu, wyciągnął go i zaimportował, a następnie poprosił go, aby nie wprowadzał żadnych zmian w DB, dopóki nie dokonam i nie sprawdzę w moim. To oczywiście nie jest idealne i szukam lepszego rozwiązania, ale to początek. Daje nam to także kontrolę wersji DB, co jest miłe.

Mogę w końcu ustawić nam udostępnioną bazę danych deweloperów na serwerze i spróbować połączyć obie nasze lokalne kopie strony internetowej z tym samym DB przez tunelowanie SSH. Takie podejście napotka jednak problemy za każdym razem, gdy jeden z nas zainstaluje wtyczkę. Zasadniczo pliki PHP i MySQL DB nie będą zsynchronizowane.

Chętnie słyszę, jak inni radzą sobie z tym problemem.