Czy Git / GitHub jest dobrym rozwiązaniem do wdrażania WordPress?


67

Obecnie rozwijam mój WordPress lokalnie, zatwierdzam mój kod do GitHub z Git, a następnie SSHing na mój serwer i wykonuję polecenie „git pull”, aby zaktualizować mój kod. Czy jest to dobra opcja do wdrożenia kodu na stronie WordPress (w tym przypadku mam oczywiście dostęp na poziomie root do mojego serwera). Znam takie rzeczy jak Capistrano, ale czy byłoby to przesadą w przypadku wdrożenia na stronie WordPress? Jak mogę w pełni wykorzystać Git / GitHub w tym przypadku?


Korzystam z deployhq.com i bardzo lubię oferowane przez nich funkcje. Jest to usługa płatna, ale uważam, że cena jest rozsądna. Jeśli zdarzyło Ci się hostować z WP Engine (ja), niedawno wypuścili funkcję git push: git.wpengine.com .
dwenaus

Odpowiedzi:


60

Używam do tego git i uważam, że działa naprawdę dobrze. Kilka sugestii:

  • Dodaj katalog do swoich .gitignoreplików (wp-content / uploads) do swojego pliku.
  • Uruchom serwer WWW i serwer bazy danych w systemie programistycznym, aby móc przetestować zmiany lokalnie przed przekazaniem ich do produkcji.
  • Zachowaj spójność ustawień połączenia z bazą danych między programistą i prod, lub dodaj wp-config.php do .gitignorepliku, aby zapobiec nadpisywaniu ustawień produkcji przez wordpress.
  • Unikaj aktualizowania wtyczek w systemie produkcyjnym za pomocą interfejsu administracyjnego Wordpress - w najlepszym razie twoja kopia git zastąpi wszystkie wtyczki, które aktualizujesz, gdy tylko wypchniesz / wyewidencjonujesz, w najgorszym przypadku wystąpią konflikty. Dokonuj aktualizacji za pomocą interfejsu administratora w systemie programistycznym, zatwierdzaj, wypychaj i kasuj w produkcji.
  • Zastanów się nad dodaniem git post-receivehooka, aby automatycznie pobierać aktualizacje do katalogu, którego używasz do publikowania wordpress za pośrednictwem serwera WWW (np /var/www.). Pozwala to tylko na sprawdzenie samych plików, unikając znalezienia metadanych git w drodze do katalogu głównego serwera WWW, a także oznacza, że ​​możesz dodać wszelkie zmiany uprawnień do haka po odebraniu, aby Twoje uprawnienia pozostały spójne za każdym razem. Przykład znajduje się poniżej:

    #!/bin/sh
    unset GIT_INDEX_FILE
    # the directory your web server serves wordpress from 
    export GIT_WORK_TREE=/var/www/example.com/
    # the local directory where your remote git repository sites
    export GIT_DIR=/home/git/repos/example.com.git/
    # below user is for debain - you want the user and group your webserver uses
    sudo git checkout -f
    sudo chown -R www-data:www-data $GIT_WORK_TREE
    sudo chmod -R 755 $GIT_WORK_TREE
    sudo chmod 600 $GIT_WORK_TREE/wp-config.php
    sudo chmod -R 775 $GIT_WORK_TREE/wp-content
    

Czy backtick pojawia się po unset GIT_INDEX_FILEliterówce?
Weston Ruter

James prawie podsumował moje worfklow, z tym wyjątkiem, że dodałem pliki motywu do repozytorium git dopiero po utworzeniu strony inscenizacyjnej / testowej / produkcyjnej. Również całkowicie polecam użycie haka po otrzymaniu na zdalnym serwerze, oszczędza logowanie i robienie ściągania git itp.
davemac

To, wraz z aliasami SSH, oznacza, że ​​mogę przejść do repozytorium motywów na żywo za pomocą „git push live” itp.
davemac

Nie znam procesu aktualizacji wtyczek w wordpress, ale co się stanie, jeśli aktualizacja wtyczek dokona zmian w bazie danych? W jaki sposób te lokalne zmiany zostaną wypchnięte na serwer produkcyjny?
Użytkownik

@ Użytkownik, który różni się w zależności od wtyczki. Core wordpress wykonuje sprawdzanie wersji schematu, więc jeśli zaktualizujesz Wordpress bez korzystania z wbudowanego aktualizatora, zrobi on aktualizacje DB osobno. Moja rada byłaby, jeśli korzystasz z jakichkolwiek wtyczek, które piszą do bazy danych, sprawdzasz obszar administracyjny Wordpress, ponieważ aktualizacje schematu są tam zwykle obsługiwane bez względu na to, jak aktualizujesz kod wtyczki.
James Hebden

22

Zdecydowanie poleciłbym ustawienie Capistrano - za pierwszym razem jest to trochę praca z góry, ale potem możesz łatwo użyć go do nowych ustawień.

Główne zalety to

  • możliwość wdrożenia z pulpitu. Może to nie zabrzmieć dużo, ale ssh-sshing na twoim zdalnym serwerze, a robienie git pull wciąż jest uciążliwe.
  • łatwe cofnięcie do poprzedniej wersji, jeśli zajdzie taka potrzeba
  • w stanie robić fajne rzeczy, takie jak wdrażanie instalacji w środowiskach pomostowych / produkcyjnych.

Dodaję zestaw skryptów capistrano, aby pokazać ci, jak to skonfigurować.

Capfile

require 'railsless-deploy'
load 'config/deploy'`

deploy.rb

set :stages, %w(production staging local)
set :default_stage, "staging"
require 'capistrano/ext/multistage'

set :application, "" # your application name - used to set directory name

set :scm, :git
set :repository, "" # use the ssh repo access line you get from the provider eg git@github.com:name/repo.git
set :deploy_to, "/var/www/#{application}" #this is the root site folder on the remote server
set :deploy_via, :remote_cache # get directly from repo
set :copy_exclude, [".git", ".DS_Store", ".gitignore", ".gitmodules", "wp-config.php"]

# makes capistrano ask for sudo password or other remote inputs
default_run_options[:pty] = true

namespace :tasks do
    task :fix_links  do
        run "ln -nfs #{shared_path}/uploads #{release_path}/wp-content/uploads"
        run "ln -nfs #{shared_path}/wp-config.php #{release_path}/wp-config.php"
      run "ln -nfs #{shared_path}/blogs.dir #{release_path}/wp-content/blogs.dir"
      run "ln -nfs #{shared_path}/.htaccess #{release_path}/.htaccess"
      run "sudo chown -R www-data.www-data #{release_path}/"
    end
end

after "deploy", "tasks:fix_links"

i na koniec przykładowy plik środowiska (jeśli używasz wielostopniowego klejnotu, możesz mieć jeden z nich dla każdego etapu środowiska, np. lokalnego, inscenizacji, produkcji)

config / local.rb

server "", :app  #hostname
set :branch, 'develop' #choose branch to deploy
set :use_sudo, false #don't use sudo

set :deploy_to, "/var/www/#{application}" #overwrite default path to deploy to

Te pliki mogą nie działać bez poprawek i będziesz potrzebować podstawowej wiedzy o Capistrano, ale mam nadzieję, że pomoże niektórym ludziom.

To był pierwszy samouczek, z którego skorzystałem, używając Capistrano i WordPress: http://theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/


2
Jeśli korzystasz z haków po otrzymaniu git, negują one potrzebę ssh na zdalnym serwerze i ściągania git
davemac

git post-receivehak jest do zrobienia!
Brock Hensley

3
@ Brud problem z hakiem po otrzymaniu polega na tym, że jeśli nie masz przyzwoitej infrastruktury CI, jedno nieprawidłowe scalenie może zniszczyć całą witrynę. Prawdopodobieństwo tego wzrasta, jeśli pracujesz nad projektem z wieloma deweloperami, którzy mają dostęp do Twojego repozytorium. Właśnie dlatego osobiście wolę wdrożyć za pośrednictwem capistrano, ale rozumiem, dlaczego inni tak bardzo się o to nie martwią.
anu

Korzystasz z samego repozytorium git, więc problem scalania nie jest istotny
davemac

9

Właściwie zrobiłem prezentację WordCamp na ten temat. Zamiast się powtarzać, oto zrzut ekranu z niego i bardzo prosty skrypt wdrażania, który towarzyszy temu, o czym mówiłem.

Krótko mówiąc, używam GitHub do hostowania repozytorium i używam haka do wdrażania zmian w oparciu o git ref. Pozwala to korzystać z modelu rozgałęzienia git Vincenta Driessena i otwiera się na nieograniczoną liczbę głowic internetowych, serwerów pomostowych, serwerów testujących itp., Wszystkie z automatycznym wdrażaniem. Zajmuję się również utrzymywaniem wp-config.php pod kontrolą wersji, zachowując osobne wersje deweloperskie / produkcyjne (przez zmianę nazw plików i dowiązanie symboliczne).


5

Wiem, że to pytanie jest trochę starsze, ale ponieważ nie widziałem tego jako odpowiedzi, chciałbym podzielić się tym, co zwykle robię dla konfiguracji i wdrożeń opartych na git dla pojedynczej witryny i działa naprawdę dobrze, również z pracą z wieloma urządzenia, lokalizacje i wielu programistów (wszyscy mają swoje lokalne repozytoria, w których działają, jak to jest typowe dla git).

Mogę serdecznie zasugerować następującą konfigurację:

Jest on również opisany w (jeśli potrzebujesz drugiego zasobu, aby owinąć wokół niego głowę):

Zasadniczo działa (z co najmniej trzema repozytoriami) poprzez:

  1. umieszczenie strony internetowej na hoście na żywo pod git,
  2. utwórz nowe repozytorium git git na hoście na żywo.
  3. A następnie przejdź z gołego repozytorium do lokalnych repozytoriów git repo.

Po zakończeniu pracy naciskasz na zdalne repozytorium, z którego sklonowałeś. Nagie repo ma haczyki do synchronizacji z repozytorium na żywo (w kodach powyżej nazywanych prime ).

Jako specyficzne ustawienia Wordpress w repozytorium mam to .gitignore:

# uploads are data, excluded from source tree
wp-content/uploads/

Reszta wraz z konfiguracja wtyczki i motywu Kontroluję wersję / konfigurację. To pozwala mi łatwo śledzić zmiany i sprawdzać kod przed użyciem go na żywo. Mogę też łatwiej łączyć się ze zdalnymi drzewami z własnymi zmianami. Jest to szczególnie przydatne w przypadku rdzenia Wordpress, który jest dostępny na Github .

Działa to całkiem dobrze dla większości moich potrzeb Wordpress. Gołe repo zapobiega wypychaniu sprzecznych zmian. Synchronizuje także najpierw kopię zdalną przed aktualizacją witryny na żywo. Oznacza to, że aktualizacja strony na żywo jest zwykle dość szybka. Z powodu haków możesz nawet wywołać haki aktualizacji Wordpress, jeśli chcesz.

Jeśli nie eksperymentowałem, o ile można to poprawić za pomocą haków Github, ale zwykle nie potrzebuję ich, ponieważ kod jest pod lokalną kontrolą wersji, a nie Github.

Aby skonfigurować taki system po raz pierwszy, powinieneś poświęcić trochę czasu na sprawdzenie, czy masz wszystkie narzędzia dostępne na zdalnym hoście:

  • Dostęp SSH
  • GIT
  • Prywatny katalog, w którym można umieszczać pliki i podkatalogi (np. Do samego repozytorium git)

Pierwszy raz konfiguracja powinna być możliwa w ciągu dwóch godzin włącznie. całe środowisko i najpierw publikujesz push.

W zależności od hosta możesz także chcieć zabezpieczyć .gitkatalog przed dostępem do Internetu. Oto przykładowy .htaccesskod, w którym Wordpress jest nawet umieszczony w podkatalogu, co pozostawia miejsce w repozytorium niepublikowanym online (przydatne):

Options -Indexes

# fix trailing slash for .git / make it disappear + .gitignore and similar files.
RedirectMatch 404 ^/\.git(.*)$

# mask 403 on .ht* as 404
<Files ~ "^\.ht">
  Order Deny,Allow
  Allow from all
  Satisfy All
  Redirect 404 /
</Files>

RewriteEngine On
RewriteBase /

# map everything into public and set environment var
# to tag the request being valid
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule ^(.*)$ /public/$1 [E=sitealias:set,L]

Krótko mówiąc, wszystko, co nie znajduje się w katalogu publicznym, nie jest w trybie online. W katalogu publicznym może znajdować się na przykład baza kodów Wordpress, ponieważ .htaccesswtedy potrzebujesz:

RewriteEngine On
# mask as 404 if directly accessed
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule .* - [L,R=404]

Zapobiega to bezpośredniemu dostępowi do publicznego . Część tego .htaccess -foo można znaleźć tutaj: Żądania do .htaccess powinny zwrócić 404 zamiast 403 . W przypadku zmiennych środowiskowych musisz sprawdzić, czy to działa w twoim środowisku. Musisz także zdecydować, czy poddasz to kontroli wersji, czy nie.

Jeśli masz większą kontrolę nad hostingiem, możesz zrobić więcej rzeczy tutaj (i inaczej / bardziej zoptymalizować), powyższe przykłady są skierowane do typowych środowisk współdzielonego hostingu (które oferują GIT, niektórzy użytkownicy twierdzą, że możesz łatwo zainstalować go jako swój własny no cóż, zwykle proszę moich hostów o ich dostarczenie, ponieważ wolę, jeśli dbają o to, za co im płacę).

Z drugiej strony, ma to kilka typowych problemów opisanych również w innych odpowiedziach. Jedną z rzeczy, z których nie jestem dumny, ale to, co działa, to dać hostowi programistycznemu zmianę pliku hosta, aby serwer bazy danych wskazywał kopię programistyczną. Możesz więc zachować jedną konfigurację bazy danych. Niezbyt fajne esp. z powodu poświadczeń.

Automatyczne kopie zapasowe

Jednak zwykle nie dbam o to zbytnio, ale zamiast tego codziennie wykonuję kopie zapasowe w zdalnych systemach, które są przyrostowo, które następnie są przechowywane w innej zdalnej lokalizacji. Jest to łatwe i tanie i pozwala przywrócić zarówno instalację Wordpress, jak i przesyłanie plików, bazę danych i repozytorium git. Również dla moich poleceń tworzenia kopii zapasowych może nie być w porządku, ale te działają dla mnie:

mysql: mysqldump --host=%s -u %s --password=%s %s| gzip > %s
git  : git gc
       git bundle
files: tar --force-local -czf %s %s

Sugeruję tutaj, abyś nie korzystał z procesów związanych z instalacją Wordpress poza Wordpress. Muszą działać w określonym systemie, więc zwykle nie masz ich w aplikacji (np. Aplikacja może się zawiesić, ale musisz nadal działać).

Włączone dla pracy zespołowej

Kolejną zaletą jest to, że Twoja witryna ma już możliwość pracy zespołowej. Dzięki dodatkowemu repozytorium typu repozytorium nie można zrobić wiele źle, a nawet udostępniać zdalne oddziały poza oddziałem głównym lub działającym na żywo ze swoimi kolegami.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.