Wdrożenie programistyczne, sceniczne i produkcyjne dla witryn WordPress?

41

Więc muszę mieć możliwość tworzenia wersji / etapów / produkcji (na osobnych serwerach) dla strony WordPress, zwykle używam git, ale oczywiście to nie będzie działać z witrynami WordPress z powodu polegania na bazie danych dla głównego konfiguracja ... cóż, prawie wszystkiego.

Więc moje pytanie brzmi: jak to robicie? Miałem szybkie Google i zobaczyłem, że jest kilka wtyczek, czy to jedyny sposób? Które najlepiej sprawdzają się pod względem łatwości użycia, szybkości, niezawodności, interfejsu użytkownika itp.?

Rob Vermeer
źródło
pantheon.io ma programistę, testy i życie dla jednej domeny. Używają git do plików i przesyłają bazę danych między nimi jednym kliknięciem. Wypróbuj za darmo, a płacisz tylko wtedy, gdy idziesz „na żywo” - youtube.com/watch?v=KpGTDeqwgX4
jgraup

Odpowiedzi:

27

Mam konfigurację, z której jestem dość dumny i działa bardzo dobrze dla mojego zespołu.

Struktura ogólna

Trzymam całą instalację pod kontrolą git. Wszystkie zmiany, czy to aktualizacja systemu, dodawanie / aktualizowanie wtyczki, dodawanie / aktualizowanie motywu, przechodzą przez ten sam przepływ pracy. Zmiany można wycofać w dowolnym momencie. Mam serwer wdrażania (stary pulpit P4) z uruchomioną gitozą, ale równie dobrze możesz użyć github lub gitolite . W git mam dwie „specjalne” gałęzie masteri develop(wyjaśniono więcej poniżej). Moje serwery produkcyjne i tymczasowe są oparte na chmurze.

Środowiska programistyczne

Każdy programista uruchamia własny serwer programistyczny na własnym komputerze. Jeśli chodzi o bazy danych, potrzeba danych na żywo prawie nigdy nie stanowiła problemu. Używamy głównie danych z testu jednostki tematycznej . W przeciwnym razie eksport i import obejmuje większość rzeczy. Jeśli element DB był kluczowy, można skonfigurować replikację lub coś do synchronizacji na żądanie. Kiedy początkowo konfigurowałem tę strukturę, pomyślałem, że będzie to kluczowe, więc zacząłem pisać zestaw narzędzi, aby to zrobić, ale ku mojemu zdziwieniu tak naprawdę nie były potrzebne. (uwaga: ponieważ nie były one konieczne, nigdy ich nie dopracowywałem, więc pojawiają się błędy, np. zastąpi domenę w serializowanych danych).

Środowisko przejściowe

Gdy zatwierdzenia są wypychane z developgałęzi do gitosis, są one automatycznie wdrażane na naszym serwerze pomostowym. Baza pomostowa jest urządzeniem podrzędnym względem produkcyjnej bazy danych.

Środowisko produkcyjne

Gdy zatwierdzenia są wypychane do gitosis w masteroddziale, jest ono automatycznie wdrażane na serwerze produkcyjnym.

Problem z wp-config.php

Chcesz wp-config.phpbyć wyjątkowy między serwerami, ale chcesz też mieć kontrolę nad wersją. Moim rozwiązaniem było .gitignorezignorowanie wp-config.phpi przechowywanie wersji testowej i produkcyjnej jako plików o różnych nazwach. Następnie na każdym serwerze umieszczam dowiązanie symboliczne np wp-config.php -> wp-config-production.php. Każdy użytkownik przechowuje następnie własną bazę danych z własnymi poświadczeniami, z własnymi (nie śledzonymi) ustawieniami wp-config.php.

Inne notatki

Korzystam z Rackspace Cloud , która jest fenomenalna i niedroga. Dzięki temu mogę zachować identyczność moich serwerów testowych i produkcyjnych. Piszę teraz również wtyczki, które używają ich interfejsu API, aby pozwolić mi kontrolować moje usługi bezpośrednio z poziomu WordPress, to cudowne.

Katalogi pamięci podręcznej, katalogi przesyłania plików itp. Są dodawane do .gitignore. Jeśli chcesz, możesz skonfigurować zadanie CRON, aby rutynowo sprawdzać przesyłane pliki i popychać je do gitosis, ale nigdy nie wydawało mi się to konieczne.

Struktura master / develop ma częściowo naśladować rozgałęziony model Vincenta Driessena . Używam również jego rozszerzenia git git-flow i bardzo bym to sugerował.

Miałem około 10 programistów pracujących nad tą strukturą od ponad roku i praca z nimi była marzeniem. Niezawodny, bezpieczny, szybki, funkcjonalny i zwinny, nie możesz prosić o wiele więcej!

Matthew Boynes
źródło
Mam zamiar skonfigurować instalację wp w podobny sposób (ale używamy svn) i chciałem potwierdzić proces aktualizacji wtyczek i wp: dokończyć aktualizację i sprawdzić program, zatwierdzić zmiany, wdrożyć je na etapie testowania, sprawdzać, polegać na życiu. Podsumowując, tak naprawdę nigdy nie wykonujesz aktualizacji instalacji wp na serwerze na żywo, którą wprowadzasz w ramach aktualizacji w repozytorium?
paullb
1
Co ze zmianami w bazie danych wprowadzonymi przez procedurę aktualizacji. W jaki sposób wpływają one na produkcyjną bazę danych?
paullb
Ten przepływ pracy jest prawidłowy @paullb i nie musisz się martwić o aktualizacje DB. Jak działa WordPress, aktualizacje są uruchamiane po wykryciu zmiany, więc działa to dokładnie tak samo, jak działa aktualizacja ręczna (do rdzenia lub wtyczki)!
Matthew Boynes
@MatthewBoynes, cześć. Czy nadal używasz tego przepływu pracy do programowania? jeśli tak, zastosuję ten przepływ pracy do mojego projektu. dziękuję :)
khakiout,
Nie robię tego, ale tylko dlatego, że nie dotyczy to projektów, nad którymi obecnie pracuję, które są w większości hostowane na WordPress.com VIP. Gdyby miało to zastosowanie, nadal bym go używał (i faktycznie firma, dla której wcześniej pracowałem, nadal go używa).
Matthew Boynes
4

Po pierwsze, uważam, że ważne jest, aby zastanowić się, co zamierzasz do kontroli wersji. Polecam przed uruchomieniem całego katalogu WP pod VC. Myślę, że najbardziej sensowne jest umieszczenie wp-content / themes / YourThemeName pod VC. W przypadku dużej witryny z dużą liczbą skomplikowanych wtyczek mogłem zobaczyć także włączenie wp-content / plugins. Jeśli to absolutnie konieczne, możesz dołączyć wp-content / uploads. Poniższe odpowiedzi nieco się zmienią, w zależności od tego, co kontrolujesz.

Biorąc to pod uwagę, oto, czego używam:

Lokalne: skonfiguruj stos LAMP na swoim komputerze. Użyj tego samego adresu URL, co witryna do programowania. Użyj VirtualHosts i wpisów do pliku .host, aby zasymulować środowisko programistyczne z punktu widzenia adresu URL. Jeśli tylko VC'ujesz swój motyw, rozważ użycie SSHFS do połączenia z wp-content / plugins, wp-content / uploads. Zastanów się nad użyciem bazy danych w instalacji deweloperskiej projektu, chyba że naprawdę wykonujesz ciężkie prace.

Programowanie: Pobierz kopię roboczą swojego repozytorium do środowiska WP. Skonfiguruj hak POST-COMMIT w SVN, aby zaktualizować to repo przy każdym zatwierdzeniu. Pozwoli to zachować synchronizację. (Uważaj to za ciągłą integrację biednego człowieka).

Produkcja: Sprawdź nazwany tag wersji reprezentujący końcowego kandydata. Gdy musisz użyć nowej wersji, przełącz tag i zaktualizuj repozytorium.

Ethan Seifert
źródło
Środowisko deweloperskie bardzo dobrze nadaje się do testowania nocnych wersji, a wordpress git jest aktualizowany automatycznie co 30 minut, poza tym, że jest zdecentralizowany i działa lepiej dla zespołów, nie znam nikogo, kto przeszedł na git / hg, który wrócił do korzystania z svn.
Wyck
1
Ciekawe, dlaczego nie poddałeś całego katalogu WP kontroli wersji. To wydaje się być wąskim gardłem w przepływie pracy. Umieszczenie WP w repozytorium daje wszystkim programistom tę samą bazę kodów i wersję WP. Pozwala także zachować spójność w różnych środowiskach. Zobacz link Wycka (w jego odpowiedzi) do plików warunkowych wp-config.
Brian Fegter
2

Niedawno odkryliśmy RAMP . Uwaga: jest to tylko część całego procesu, ale synchronizacja baz danych zawartości między serwerami jest prawdopodobnie najtrudniejszą częścią tego procesu.

lkraav
źródło
2

Robię to za pomocą git i mercurial, po prostu upewnij się, że używasz prywatnego repo.

Opcja 1.

Jedynym problemem jest config.php, który możesz powiedzieć gitowi, aby ignorował podczas wypychania lub przed init.

Użyj .gitignorelub git update-index --assume-unchanged config.php(przeczytaj trochę o przyjętej niezmienionej komendzie przed jej użyciem)

Opcje 2.

Użyj pliku warunkowego w pliku config.php, który sprawdza adres URL i stosuje poprawne dane uwierzytelniające, podobnie jak „jeśli adres URL serwera = dev, to użyj danych logowania A, w przeciwnym razie użyj danych logowania B” itp.

Mark wyjaśnia to lepiej, http://markjaquith.wordpress.com/2011/06/24/wordpress-local-dev-tips/

ps. Możesz także serwować pliki bezpośrednio ze zdalnego repozytorium zamiast tradycyjnego „serwera plików”. (naprawdę nudne wideo, które zrobiłem na temat tego http://www.youtube.com/watch?v=8ZEiFi4thDI )

Wyck
źródło