WordPress i Git Workflow

Wiem, że to pytanie zostało zadane tysiąc razy, ale naprawdę staram się wymyślić, jak najlepiej wykorzystać Git podczas pracy z WordPress.

Szukałem w Internecie i czytałem dziesiątki artykułów, które zdają się krótko omawiać ten temat. Oto kilka z najbardziej znanych, które ostatnio czytałem.

- Kontrola wersji WordPress

- Zarządzanie wdrożeniami motywów WordPress za pomocą Git

- Zarządzaj niestandardowym motywem WordPress za pomocą git zamiast FTP

Obecnie mój przepływ pracy wygląda tak.

• Zainstaluj WordPress lokalnie
• Opracuj motyw
• Eksportuj bazy danych WordPress z lokalnego serwera
• Zaimportuj bazę danych WordPress na zdalny serwer
• Prześlij pliki i motyw WordPress przez FTP
• Klient dokonuje zmian
• Pobierz pliki i motyw WordPress przez FTP i wyeksportuj bazy danych WordPress ze zdalnego serwera
• Zastąp pliki lokalnie
• Wprowadź zmiany programistyczne
• Prześlij ponownie przez FTP, eksportuj i importuj bazę danych na zdalny serwer

Zdaję sobie sprawę, że Git może usprawnić ten proces. Wydaje się, że najlepszym sposobem na to jest posiadanie pliku .gitignore, który ignoruje niektóre katalogi, które nie muszą być śledzone, a także posiadanie lokalnego i zdalnego pliku wp-config.php.

Ale jak radzisz sobie z bazami danych? Klienci zwykle wprowadzają zmiany (posty / strony / wtyczki). Czy nadal muszę eksportować ze zdalnej bazy danych i importować z powrotem na mój lokalny serwer?

Czy ktoś może tutaj zasugerować najlepszy przepływ pracy? I poprowadź mnie przez kroki.

Ponadto prawdopodobnie chciałbym użyć Bitbucket, ponieważ prywatne repozytorium z nimi są bezpłatne, w przeciwieństwie do GitHub.

Każda pomoc będzie mile widziana.

Z góry dziękuję!

Jestem jednym z programistów WP Migrate DB Pro i chciałbym odpowiedzieć na pytanie @ Ennui:

„Czy wiesz, czy uruchamiany skrypt db url db bierze pod uwagę ciągi serializowane?”

Tak, obsługuje dane zserializowane. Jest to główny powód, dla którego opracowałem darmową wersję wtyczki w 2009 roku. :)

Niestety mam reputację 41, więc nie mogłem odpowiedzieć na komentarz @ Ennui. Przepraszam za to.

Jestem na granicy głosowania, by zakończyć to jako „mało konstruktywne”, ponieważ wydaje się, że jest to rodzaj rzeczy, która raczej zachęci do debaty i opinii niż do odpowiedzi. Ale...

Nie tak wygląda mój przepływ pracy i sprawia, że ​​moje podejście (i odpowiedź) różni się od większości pozostałych odpowiedzi do tej pory.

1. Zainstaluj WordPress lokalnie
   1. Sklonowano go z lokalnego nagiego repozytorium Git zawierającego najnowsze stabilne wydanie.
   2. Zachowuję także lokalną kopię najnowszej wersji kilku wtyczek, które prawie zawsze instaluję.
2. Zbuduj motyw i wszelkie niezbędne wtyczki
3. Prześlij na publiczny serwer pomostowy
   1. Klient ma dostęp, ale nie może zmienić kodu i powiedział, że zmiany w bazie danych nie zostaną przesłane do strony produkcyjnej.
   2. Oznacza to, że nie ma powodu, aby pobierać kod z powrotem na serwer programistyczny.
   3. I nie ma powodu, aby ponownie synchronizować lokalną bazę danych
4. Wprowadź zmiany w lokalnej witrynie na podstawie naszych pracowników i opinii klienta.
5. Prześlij zmiany
6. Powtórz w razie potrzeby (ale z rosnącym oporem :))
7. Jeśli dostarczamy treść, co nie zawsze tak jest, my (nie klient) wyczyścimy bazę danych na serwerze pomostowym i prześlemy zawartość.
8. Wdróż, przesyłając lokalny kod na stronę produkcyjną.
9. Jeśli stworzyliśmy treść, jest ona eksportowana z witryny pomostowej za pomocą narzędzia do eksportu wanilii i importowana na stronę produkcyjną.
   1. To jedyny raz, kiedy muszę przenieść bazę danych i odbywa się to za pomocą dość standardowych narzędzi. W razie potrzeby użyję adresów URL aktualizacji Velvet Blues, aby wyczyścić bazę danych.
10. Odpluskwić
11. Koniec

Zasadniczo trzymam klienta z dala od moich rzeczy tak bardzo, jak to możliwe, dopóki nie przekażemy strony.

Kod przesuwa się w jedną stronę - z lokalnej na etapową lub produkcyjną. Nigdy nie porusza się w drugą stronę. To eliminuje niektóre twoje kroki i daje mi spokój. Nie chcę być obwiniany za majsterkowanie klienta w moim kodzie i nie chcę importować zhakowanego pliku, co jest niezerową możliwością.

Baza danych przenosi się tylko raz, jeśli w ogóle, co znacznie zmniejsza problem. Myślę, że radzę sobie z problemem „przenoszenia bazy danych”, zmniejszając lub usuwając potrzebę przenoszenia bazy danych. Zmniejsza to również problemy z korupcją bazy danych, które mogą się pojawić, i zmniejsza szanse na zaimportowanie włamania.

To prawda, że ​​muszę skonfigurować witrynę produkcyjną - bezpośrednie łącza, menu itp. - ale to zmusza mnie do pracy w witrynie produkcyjnej, więc uważam to za rodzaj debugowania. Pomaga mi potwierdzić, że wszystko działa w miejscu produkcji tak, jak powinno.

https://github.com/nathanielks/Wordpress-Capistrano-Deploy

Nie próbowałem tego sam (jeszcze), ale twierdzi, że wszystko wdrożyłem - w tym DB.

Jest też poradnik iść z nim: Tutorial część 1 | część 2

Spójrz na stos skalny . Używa kompozytora do zarządzania wersją Wordpress i wtyczek firm trzecich, a także obejmuje capistrano do wdrażania i vagrant / ansible do konfigurowania serwerów, w tym lokalnych serwerów wirtualnych do programowania.

Niedawno przeprowadziłem wiele testów w tym zakresie, a oto przepływ pracy, którego używam, który robi właściwie to, o co prosisz:

• Używam wp-cli do zarządzania rdzeniem wordpress i aktualizacji wordpress.
• Używam kompozytora wraz z http://wpackagist.org do zarządzania zależnościami wtyczek i motywów.
• Używam git i umieszczam podstawowe pliki wp w .gitignore. Więc głównie wp-config.php i pliki motywów potomnych są w git.

Nie jestem zaznajomiony z narzędziami do migracji db, ale byłby świetnym dodatkiem do tego przepływu pracy.

Oto pełne szczegóły dotyczące przepływu pracy http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli

Jeśli chodzi o „klonowanie” bazy danych, używam WP Migrate DB Pro: http://deliciousbrains.com/wp-migrate-db-pro/

Jest to usługa płatna, ale nie kosztuje dużo i z łatwością pozwala ci pobrać lub przesunąć bazę danych z twojego dewelopera na serwer na żywo i odwrotnie. Zmienia adresy URL i wszystko, co wymaga zmiany po drodze.