Wordpress Git Workflow Pomoc

Szukam silnego usprawnionego przepływu pracy do pracy z Wordpress.

1. Chciałbym mieć moje środowisko git na własnym serwerze wewnętrznie, nie używając Github do obsługi repozytoriów.
2. Automatyczne tworzenie subdomen po utworzeniu gałęzi git (development.domain.com, ryan.development.domain.com) - Prawdopodobnie byłby do tego potrzebny pewien haczyk skryptu powłoki.
3. Phing PHP / Shell script Obsługa migracji bazy danych (coś takiego: http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) do obsługi szeregowej wymiany bazy danych po wypchnięciu

Operacja prawdopodobnie przebiegałaby mniej więcej tak:

1. pobranie aktualnej najnowszej wersji wordpress i rozgałęzienie, nazwa oddziału otrzymuje wpis subdomeny (branchdevelopment.domain.com)
2. podmoduł żądany motyw, jeśli jest dostępny (chciałbym zrobić dla tego własne repozytorium git, ponieważ korzystam z pracy, chciałbym mieć pustą konfigurację git repo, aby pobrać wewnętrznie z serwera, który został już utworzony)
3. kasa i wprowadzanie zmian, recenzje klientów, po wprowadzeniu do życia skrypt bazy danych uruchomi się automatycznie, zmieniając zserializowane wartości adresu URL z hosta lokalnego (lub subdomeny) na adres URL na żywo

czy to możliwe? Słyszałem, że Capistrano jest również przydatny do tego, ale nie jestem pewien, jak całkowicie działa Capistrano.

Prowadzę około 200 witryn na własnym serwerze i chciałbym rozpocząć wdrażanie tych witryn w silnym środowisku przepływu pracy git, dzięki czemu mogę znacznie usprawnić moją pracę. W tej chwili w zasadzie pobieram obraz strony i pracuję nad nią lokalnie, a następnie przesyłam zmiany z powrotem na serwer. Jest to bardzo nudne w dzisiejszych czasach.

Czy ktoś ma jakieś rozwiązania dotyczące tego rodzaju przepływu pracy / pracował z tym w przeszłości? Jeśli tak, niektóre zasoby / odpowiedzi byłyby bardzo mile widziane.

Odpowiedzi na pytania ogólne

Nr.1. Chciałbym mieć moje środowisko git na własnym serwerze wewnętrznie, nie używając Github do obsługi repozytoriów.

Pierwszą rzeczą, którą zrobię, jest sprawdzenie kompozytora i jego współpracy z WordPress , projektem Andreya „@Rarsta” Savchenko .

Nr.2. Automatyczne tworzenie subdomen po utworzeniu gałęzi git ( development.example.com, ryan.development.example.com) - Prawdopodobnie byłby do tego idealny haczyk skryptu powłoki.

To jest coś poza zakresem dla tej strony. Poproś o pomoc w StackOverflow lub zapytaj u swojego hosta. Niektórzy hostingiści nie pozwalają na samodzielne edytowanie tych wpisów.

Nr 3 Phing PHP / Shell script Obsługa migracji bazy danych (coś takiego: http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) do obsługi szeregowej wymiany bazy danych po wypchnięciu

Ustawiłbym instalację na wielu serwerach / w sieci. Umożliwia to łatwe zarządzanie wszystkimi tabelami, utrzymywanie użytkowników w centralnym miejscu itp.

WP Gear - projekt Roberta „@Wyck” Ellison - ma listę alternatywnych skryptów kompilacji. W tym napisane przez siebie WordPhing . @TomJNowells /Interconnect.it skrypt dotąd nie ma w tym wykazie.

Odpowiedzi na pytania dotyczące operacji

Nr. 1. pobranie aktualnej najnowszej wersji wordpress i rozgałęzienie, nazwa oddziału otrzymuje wpis subdomeny (branchdevelopment.domain.com)

Nie jestem pewien, dlaczego chcemy to zrobić: Subdomena dla każdej gałęzi. Gdy spojrzysz na zsynchronizowane repozytorium GitHub WordPress i listę gałęzi , zobaczysz, że każda gałąź ma nazwę X.Y-branch. Twoje subdomeny zostałyby nazwane np 3.6-branch. Nie jestem pewien, czy subdomena może zaczynać się od cyfry (tak powinno być, ale zapytaj swojego hosta), a następnie pojawia się problem z otrzymaniem subdomeny o nazwie 6-branch, która ma subdomenę o nazwie subdomeny 3i kolejny o nazwie 2. Zgadnij, że parowanie gałęzi 2- i 3-wersyjnych w subdomenie nie jest tym, co chcesz osiągnąć.

W skrócie: Tylko checkout 3.6-branchjeśli chcesz zmienić gałęzie.

Nr.2. podmoduł żądany motyw, jeśli jest dostępny (chciałbym zrobić dla tego własne repozytorium git, ponieważ korzystam z pracy, chciałbym mieć pustą konfigurację git repo, aby pobrać wewnętrznie z serwera, który został już utworzony)

Thomas „@toscho” Scholz napisał fajną wtyczkę, która pozwala nam używać subdomeny do obsługi motywów poza katalogiem WordPress. Możesz go znaleźć zarówno w tej odpowiedzi, jak i w tej . Nawet automatyczne aktualizacje będą działać dla motywów od wersji WP 3.6.

Możesz zrobić to samo dla wtyczek MU i wtyczek, po prostu ustawiając następujące stałe w swoim wp-config.phppliku:

define( 'WP_PLUGIN_DIR',   'path/to/your/plugins.dev/folder/plugins' );
define( 'WP_PLUGIN_URL',   'https://plugins.dev/plugins' );
define( 'WPMU_PLUGIN_DIR', 'path/to/your/plugins.dev/folder/mu-plugins' );
define( 'WPMU_PLUGIN_URL', 'https://plugins.dev/mu-plugins' );

Teraz po prostu poddaj wszystkie wtyczki i motywy kontroli wersji i wypchnij je na serwer. Możesz łatwo udostępnić je wszystkie za pomocą wtyczek mu lub domyślnych wtyczek aktywowanych przez sieć.

Nr.3 kasy i dokonaj zmian, recenzje klientów, kiedy zostanie on wypchnięty do życia, skrypt bazy danych uruchomi się automatycznie, zmieniając zserializowane wartości adresu URL z localhost (lub subdomeny) na adres URL na żywo

Jeśli skrypt / wtyczka Toms do tej pory ci nie pomogła, powiedz , że akceptuje żądanie ściągnięcia na GitHub .

Nie ma czasu, aby napisać pełną odpowiedź na pytanie (znam trochę kiepskie), ale prawdopodobnie i tak warto to udostępnić (mógłbym to edytować, ponieważ planuję również blog na ten temat):

• Klonuję Wordpress z Github (możesz nawet zrobić to dla drzewa źródłowego stąd: tierra / wordpress )

• Następnie używam go jako scalenia poddrzewa w moim repozytorium stron (nawet natknąłem się na błąd w git, ale jego rozwiązanie jest tutaj: -X poddrzewo = ... ).

Oznacza to, że możesz mieć konfigurację WP opartą na linii głównej / wersji, którą możesz w pełni włamać. motywy i wtyczki.

Ponieważ jest to jedno niezależne (lokalne) repozytorium, możesz przesłać to przez ssh do innych repozytoriów, na przykład jednego:

• Znajduje się on na zdalnym hoście, na którym witryna powinna zostać wdrożona (bez repozytorium).
• Ma haczyki, dzięki którym kolejne repozytorium na tym hoście faktycznie łączy się z wprowadzonymi zmianami.

Jest to opisane w skoncentrowanym na sieci przepływie pracy Git (listopad 2008; Joe Maller) .

Jeśli masz przełącznik konfiguracji, który wybiera konkretny wp-config.phpsystem w oparciu o system, na którym działa, możesz nawet centralnie skonfigurować wszystkie hosty (programowanie, transmisja na żywo, inscenizacja, znajomi ...) w repozytorium.

Wstępne zmiany w WP po ​​prostu pobieracie i scalacie w poddrzewie.

Wtyczki, które właśnie aktualizujesz i zatwierdzasz.

Wdrożenie jest proste $ git push remote.

Uruchamiaj codzienne kopie zapasowe na zdalnym hoście dla repozytoriów git, bazy danych i przesyłanych plików. Jest to tanie, przyjazne dla programistów i elastyczne. Działa to dobrze zarówno w konfiguracjach dla pojedynczego dewelopera, jak i w małych zespołach, ponieważ każdy może pobrać kasę z samego nagrania na pilocie.

Istnieje kilka zastrzeżeń:

• Aliasy git git accept-theirsi git accept-theirssą pomocne w przypadku wystąpienia sprzecznych zmian linii bazowej, których wyraźnie wiesz, z którymi wolisz sobie poradzić. Znajdziesz to tutaj: Proste narzędzie do „zaakceptuj swoje” lub „zaakceptuj moje” w całym pliku za pomocą git
• Cześć Dolly. Klątwa całego pokolenia. Musisz to zawsze robić.

Teraz z listą kontrolną i konfiguracją, jak opisano powyżej:

1. Chciałbym mieć moje środowisko git na własnym serwerze wewnętrznie, nie używając Github do obsługi repozytoriów.

Github obsługuje tylko repozytorium w górę łańcucha dostaw (Wordpress), a nie twoje własne.

2. Automatyczne tworzenie subdomen po utworzeniu gałęzi git (development.domain.com, ryan.development.domain.com) - Prawdopodobnie byłby do tego potrzebny pewien haczyk skryptu powłoki.

Przedstawiona konfiguracja to podejście modułowe z jednym repozytorium na witrynę. Może obsługiwać dowolną liczbę hostów programistycznych, jak chcesz, może równie dobrze działać z instalacją wielu witryn, aby obsługiwać wiele domen, ale w tym podejściu byłoby to liczone jako jedna konfiguracja Wordpress.

3. Phing PHP / Shell script Obsługa migracji bazy danych (coś takiego: http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) do obsługi szeregowej wymiany bazy danych po wypchnięciu

Nie jest to tutaj potrzebne, ponieważ tylko kod jest pod kontrolą wersji, bazy danych są niezależne między programowaniem (, etapami) i produkcją, jak powinno być.

Być może szukasz skryptu instalacyjnego, który odpowiednio migruje domenę, ale nawet z lepszym kodem (który jest dostępny) zajmującym się serializowanym wyszukiwaniem i zamianą danych, w tej konfiguracji tutaj zwykle nie jest konieczne, ponieważ po prostu wprowadzasz zmiany w życie , w przypadkach testowych możesz szybko utworzyć zawartość w bazie danych programistów, co jest zwykle najmniejszym problemem (z mojego praktycznego doświadczenia, twoje mogą się różnić, ale sugerowałbym również, aby zachować takie tematy związane z migracją bazy danych na pytania dotyczące tego posiadać tutaj na stronie - ale proszę o to zapytać).

Prowadzę około 200 witryn na własnym serwerze i chciałbym rozpocząć wdrażanie tych witryn w silnym środowisku przepływu pracy git, dzięki czemu mogę znacznie usprawnić moją pracę.

Nie mogę sobie wyobrazić, jak te strony stałyby się w środowisku przepływu pracy git string. Być może skrypty konfiguracyjne i dane konfiguracyjne, którymi tu zarządzasz, będą pod kontrolą wersji git. To może mieć sens. W przeciwnym razie, biorąc pod uwagę samą liczbę stron, myślę, że nie ma sensu utrzymywanie tych wszystkich w jednym repozytorium git. Być może nawet jednego z nich, ponieważ to, co opisałem powyżej, dotyczy witryn, które tworzysz (w tym kod podstawowy WP), a nie tylko zadań instalacyjnych. Najprawdopodobniej musisz najpierw stworzyć sobie małą mapę tych 200 witryn i ich interakcji ze sobą oraz z których pakietów (WP core, wtyczki, motywy) składają się te witryny. Pierwszą rzeczą może być utworzenie arkusza kalkulacyjnego / matrycy i umieszczenie wszystkich witryn.

Następnie możesz zapisać go jako CSV, poddać kontroli wersji i sprawić, by skrypty wdrożeniowe działały na podstawie tego pliku.

A jeśli nauczyłem się czegoś na temat automatyzacji zadań: kieruj się filozofią Uniksa, użyj istniejących i dobrze działających narzędzi (lepiej poświęcić pół dnia na czytanie niektórych poleceń, niż na poszukiwanie alternatyw, ponieważ w przypadku większości zadań problemy były już rozwiązany) i skup się na narzędziach wiersza poleceń. Są najpotężniejsze.