Este Git/GitHub o soluție bună pentru implementarea WordPress?

Vă recomand cu căldură să configurați Capistrano - necesită puțin efort inițial prima dată, dar după aceea îl puteți folosi cu ușurință pentru noi setări.

Principalele avantaje sunt

• posibilitatea de a face deploy direct de pe desktop. Poate nu pare mult, dar a vă conecta prin SSH la serverul remote și a face un git pull este în continuare o corvoadă.
• revenirea ușoară la o versiune anterioară dacă este necesar
• posibilitatea de a face lucruri interesante, cum ar fi configurarea deploy-ului pentru medii de staging/producție.

Adaug un set de scripturi Capistrano pentru a vă arăta cum am configurat eu lucrurile.

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, "" # numele aplicației tale - folosit pentru a seta numele directorului

set :scm, :git
set :repository, "" # folosește linia de acces SSH la repo pe care o obții de la provider, ex. git@github.com:nume/repo.git
set :deploy_to, "/var/www/#{application}" #acesta este folderul rădăcină al site-ului pe serverul remote
set :deploy_via, :remote_cache # obține direct din repo
set :copy_exclude, [".git", ".DS_Store", ".gitignore", ".gitmodules", "wp-config.php"]

# face ca capistrano să ceară parola sudo sau alte input-uri remote
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 în final, un fișier exemplu pentru mediu (dacă folosești gem-ul multistage, poți avea câte unul din acestea pentru fiecare stadiu al mediului tău, ex. local, staging, producție)

config/local.rb

server "", :app  #numele gazdei
set :branch, 'develop' #alege ramura pentru deploy
set :use_sudo, false #nu folosi sudo

set :deploy_to, "/var/www/#{application}" #suprascrie calea implicită pentru deploy

Aceste fișiere s-ar putea să nu funcționeze fără ajustări și vei avea nevoie de cunoștințe de bază despre Capistrano, dar sper că vor ajuta unele persoane.

Acesta a fost primul tutorial pe care l-am folosit pentru a începe cu Capistrano și WordPress: http://theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/

De fapt, am ţinut o prezentare la WordCamp pe această temă. În loc să mă repet, aici este un screencast al prezentării şi aici este un script foarte simplu de implementare care însoţeşte ceea ce am discutat.

Pe scurt, folosesc GitHub pentru a găzdui repository-ul şi utilizez un webhook pentru a implementa modificările bazate pe referinţa git. Acest lucru vă permite să utilizaţi modelul de ramificare git al lui Vincent Driessen şi vă deschide posibilitatea de a avea un număr nelimitat de webheads, servere de staging, servere de testare etc., toate cu implementare automată. De asemenea, acoperă păstrarea fişierului wp-config.php sub controlul versiunilor, menţinând în acelaşi timp versiuni separate pentru dezvoltare/producţie (prin redenumirea fişierelor şi folosirea symlink-urilor).

Știu că această întrebare este puțin mai veche, dar deoarece nu am văzut acest răspuns aici, aș dori să împărtășesc ceea ce fac în mod normal pentru configurațiile și implementările bazate pe git pentru un singur site și funcționează foarte bine, chiar și atunci când lucrez de pe mai multe dispozitive, locații și cu mai mulți dezvoltatori (toți având propriile depozite locale în care operează, așa cum este obișnuit pentru git).

Pot recomanda cu căldură următoarea configurație:

• Un flux de lucru Git axat pe web (de Joe Maller; Noiembrie 2008)

Este, de asemenea, prezentat în (dacă aveți nevoie de o a doua sursă pentru a înțelege mai bine):

• Utilizarea Git pentru implementare (de Dan Barber; Aprilie 2011)

Practic, funcționează (cu cel puțin trei depozite) prin:

1. plasarea site-ului web pe gazda live sub git,
2. crearea unui nou depozit gol git pe gazda live.
3. Și apoi bifurcați din depozitul gol către depozitul local de dezvoltare git.

Când munca este gata, faceți push către depozitul gol de la care ați clonat. Depozitul gol are hook-uri pentru a se sincroniza cu depozitul live (în codurile de mai sus numit prime).

Ca setări specifice Wordpress în depozit, am acest .gitignore:

# fișierele încărcate sunt date, excluse din arborele sursă
wp-content/uploads/

Restul, inclusiv configurația plugin-urilor și a temelor, le păstrez sub controlul versiunilor/configurației. Acest lucru îmi permite să urmăresc cu ușurință modificările și să revizuiesc codul înainte de a-l folosi live. Pot, de asemenea, să fac merge mai ușor cu copii remote cu modificările mele. Acest lucru este util în special pentru nucleul Wordpress, care este disponibil pe Github.

Această metodă funcționează foarte bine pentru majoritatea nevoilor mele legate de Wordpress. Depozitul gol vă împiedică să faceți push la modificări conflictuale. De asemenea, se sincronizează mai întâi cu o copie remote înainte de a actualiza site-ul live. Asta înseamnă că actualizarea site-ului live este de obicei destul de rapidă. Datorită hook-urilor, puteți chiar să apelați hook-uri de actualizare Wordpress după aceea, dacă doriți.

Nu am experimentat cât de mult poate fi îmbunătățit acest lucru cu hook-urile Github, dar în mod normal nu am nevoie de ele, deoarece codul este sub controlul versiunilor local, nu pe Github.

Pentru a configura un astfel de sistem pentru prima dată, ar trebui să vă luați un timp pentru a evalua dacă aveți toate instrumentele disponibile pe gazda remote:

• Acces SSH
• GIT
• Un director privat în care puteți pune fișiere și subdirectoare (de exemplu, pentru depozitul gol git)

Timpul de configurare pentru prima dată ar trebui să fie posibil în una sau două ore, inclusiv întregul mediu și primul push publicat.

În funcție de gazdă, ați putea dori, de asemenea, să protejați directorul .git de accesul web. Iată un exemplu de cod .htaccess care face acest lucru chiar și atunci când Wordpress este plasat într-un subdirector, ceea ce lasă spațiu în depozit care nu este publicat online (util):

Options -Indexes

# corectează slash-ul final pentru .git / face să dispară + .gitignore și fișiere similare.
RedirectMatch 404 ^/\.git(.*)$

# maschează 403 pe .ht* ca 404
<Files ~ "^\.ht">
  Order Deny,Allow
  Allow from all
  Satisfy All
  Redirect 404 /
</Files>

RewriteEngine On
RewriteBase /

# mapează totul în public și setează variabila de mediu
# pentru a marca cererea ca fiind validă
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule ^(.*)$ /public/$1 [E=sitealias:set,L]

Pe scurt, tot ce nu este în directorul public nu este online. În directorul public poate fi, de exemplu, codul Wordpress, iar pentru .htaccess acolo aveți nevoie de:

RewriteEngine On
# maschează ca 404 dacă este accesat direct
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule .* - [L,R=404]

Acest lucru previne accesul direct la public. O parte din acest .htaccess-foo o puteți găsi prezentată aici: Cererile către .htaccess ar trebui să returneze 404 în loc de 403. Pentru variabilele de mediu, trebuie să testați dacă funcționează în mediul dumneavoastră. De asemenea, trebuie să decideți dacă puneți asta sub controlul versiunilor sau nu.

Dacă aveți mai mult control asupra gazdării, puteți face mai multe lucruri aici (și diferit / mai optimizat), exemplele de mai sus sunt destinate pentru medii tipice de găzduire partajată (care oferă GIT, unii utilizatori spun că îl puteți instala și singur, eu în mod normal îi cer furnizorilor mei să ofere astfel de servicii pentru că prefer să aibă ei grijă de asta, pentru asta îi plătesc).

Pe partea negativă, acest lucru are unele dintre problemele comune prezentate și în celelalte răspunsuri. Un lucru de care nu sunt mândru, dar care funcționează, este să ofer gazdei de dezvoltare o modificare a fișierului său de gazde pentru a direcționa serverul de baze de date către copia de dezvoltare. Astfel, puteți păstra o singură configurație de bază de date. Nu este chiar cool, mai ales din cauza credențialelor.

Backup-uri automate

Totuși, în mod normal nu mă preocup prea mult aici, ci în schimb am backup-uri zilnice care rulează pe sistemele remote, care sunt incrementale și care sunt stocate apoi într-o altă locație remote. Asta este ușor și ieftin și vă permite să restaurați atât instalarea Wordpress, cât și fișierele încărcate, baza de date și depozitul git. De asemenea, pentru comenzile mele de backup s-ar putea să nu fie perfect corecte, dar acestea funcționează pentru mine:

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

Ceea ce sugerez aici este să păstrați procesele din jurul instalării Wordpress în afara Wordpress. Ele trebuie să ruleze pe un sistem specific, așa că în mod normal nu le aveți în interiorul aplicației (de exemplu, aplicația poate cădea, dar trebuie ca acestea să continue să funcționeze).

Pregătit pentru lucrul în echipă

Un alt beneficiu frumos este că site-ul dumneavoastră este deja pregătit pentru lucrul în echipă. Datorită depozitului gol suplimentar, nu puteți face prea multe greșeli și puteți chiar să partajați ramuri remote în afară de ramura master sau live cu colegii dumneavoastră.