Git/GitHub è una buona soluzione per il deployment di WordPress?

Consiglio vivamente di impostare Capistrano - richiede un po' di lavoro iniziale la prima volta, ma successivamente potrai utilizzarlo facilmente per nuove configurazioni.

I principali vantaggi sono:

• la possibilità di effettuare il deploy direttamente dal tuo computer. Potrebbe non sembrare molto, ma connettersi via SSH al server remoto e fare un git pull è comunque una seccatura.
• facile rollback a una versione precedente se necessario
• la capacità di fare cose interessanti come configurare il deploy per ambienti di staging/produzione.

Aggiungo una serie di script Capistrano per mostrarti come ho impostato il tutto.

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, "" # nome della tua applicazione - usato per impostare il nome della directory

set :scm, :git
set :repository, "" # usa la linea di accesso SSH al repository che ottieni dal provider es. git@github.com:nome/repo.git
set :deploy_to, "/var/www/#{application}" # questa è la cartella root del sito sul server remoto
set :deploy_via, :remote_cache # ottieni direttamente dal repository
set :copy_exclude, [".git", ".DS_Store", ".gitignore", ".gitmodules", "wp-config.php"]

# fa sì che Capistrano chieda la password sudo o altri input remoti
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"

Infine, un file di ambiente di esempio (se usi la gemma multistage, puoi averne uno per ogni fase del tuo ambiente, es. locale, staging, produzione)

config/local.rb

server "", :app  # hostname
set :branch, 'develop' # scegli il branch da deployare
set :use_sudo, false # non usare sudo

set :deploy_to, "/var/www/#{application}" # sovrascrivi il percorso predefinito per il deploy

Questi file potrebbero non funzionare senza modifiche e avrai bisogno di una conoscenza base di Capistrano, ma spero possano essere d'aiuto ad alcune persone.

Questo è stato il primo tutorial che ho usato per iniziare con Capistrano e WordPress: http://theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/

In realtà ho tenuto una presentazione su questo argomento durante un WordCamp. Piuttosto che ripetermi, ecco uno screencast della presentazione e ecco uno script di deployment molto semplice che accompagna ciò di cui ho parlato.

In breve, utilizzo GitHub per ospitare il repository e uso un webhook per distribuire le modifiche basate sul git ref. Questo ti permette di utilizzare il modello di branching git di Vincent Driessen e ti apre le porte a poter avere webhead illimitati, server di staging, server di testing, ecc., tutti con deployment automatizzato. Ho anche affrontato il tema di mantenere wp-config.php sotto controllo versione pur mantenendo versioni separate per sviluppo e produzione (rinominando i file e utilizzando symlink).

So che questa domanda è un po' datata, ma dato che non ho visto questa risposta qui, vorrei condividere quello che faccio normalmente per configurazioni e deployment basati su git per siti singoli, e funziona molto bene, anche lavorando da più dispositivi, luoghi e con più sviluppatori (ognuno con i propri repository locali in cui operano, come è comune con git).

Posso suggerire con grande entusiasmo la seguente configurazione:

• Un flusso di lavoro Git focalizzato sul web (di Joe Maller; Nov 2008)

È anche delineato in (se hai bisogno di una seconda risorsa per capirlo meglio):

• Usare Git per il Deployment (di Dan Barber; Apr 2011)

Fondamentalmente funziona (con almeno tre repository) in questo modo:

1. mettere il sito web sull'host live sotto git,
2. creare un nuovo repository git bare sull'host live.
3. E poi fare un fork dal repository bare al tuo repository git di sviluppo locale.

Quando il lavoro è fatto, fai un push verso il repository bare remoto da cui hai clonato. Il repository bare ha degli hook per sincronizzarsi con il repository live (nei codici sopra chiamato prime).

Come impostazioni specifiche di Wordpress nel repository, ho questo .gitignore:

# le upload sono dati, esclusi dall'albero sorgente
wp-content/uploads/

Il resto, inclusa la configurazione di plugin e temi, lo tengo sotto controllo delle versioni/configurazione. Questo mi permette di tracciare facilmente i cambiamenti e revisionare il codice prima di usarlo in live. Posso anche unire più facilmente alberi remoti con i miei cambiamenti. Questo è particolarmente utile contro il core di Wordpress disponibile su Github.

Questo funziona molto bene per la maggior parte delle mie esigenze con Wordpress. Il repository bare ti impedisce di fare push di cambiamenti conflittuali. Sincronizza anche prima con una copia remota prima di aggiornare il sito live. Questo significa che aggiornare il sito live è normalmente molto veloce. Grazie agli hook puoi anche chiamare gli hook di aggiornamento di Wordpress dopo, se vuoi.

Non ho sperimentato quanto questo possa essere migliorato con gli hook di Github, ma normalmente non ne ho bisogno perché il codice è sotto controllo delle versioni locale, non su Github.

Per configurare un tale sistema per la prima volta, dovresti prenderti del tempo per valutare se hai tutti gli strumenti disponibili sul tuo host remoto:

• Accesso SSH
• GIT
• Una directory privata dove puoi mettere file e sotto-directory (es. per il tuo repository git bare)

Il tempo di configurazione per la prima volta dovrebbe essere possibile entro una o due ore, incluso l'ambiente completo e il tuo primo push di pubblicazione.

A seconda del tuo host, potresti anche voler proteggere la directory .git dall'accesso web. Ecco un esempio di codice .htaccess che lo fa anche con Wordpress posizionato in una sotto-directory, che lascia spazio nel repository non pubblicato online (utile):

Options -Indexes

# fix trailing slash per .git / farla scomparire + .gitignore e file simili.
RedirectMatch 404 ^/\.git(.*)$

# maschera 403 su .ht* come 404
<Files ~ "^\.ht">
  Order Deny,Allow
  Allow from all
  Satisfy All
  Redirect 404 /
</Files>

RewriteEngine On
RewriteBase /

# mappa tutto in public e imposta variabile d'ambiente
# per taggare la richiesta come valida
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule ^(.*)$ /public/$1 [E=sitealias:set,L]

In breve, tutto ciò che non è dentro la directory public non è online. Dentro la directory public può esserci il codice base di Wordpress per esempio, per il .htaccess lì dentro avrai bisogno di:

RewriteEngine On
# maschera come 404 se acceduto direttamente
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule .* - [L,R=404]

Questo previene l'accesso diretto a public. Parte di questo .htaccess-foo lo puoi trovare delineato qui: Le richieste a .htaccess dovrebbero restituire 404 invece di 403. Per le variabili d'ambiente devi testare se funziona nel tuo ambiente. Inoltre devi decidere se metterlo sotto controllo delle versioni o no.

Se hai più controllo sull'hosting, puoi fare più cose qui (e in modo diverso / più ottimizzato), gli esempi sopra sono mirati per ambienti di hosting condivisi tipici (che offrono GIT, alcuni utenti dicono che puoi installarlo facilmente da solo, io normalmente chiedo ai miei hoster di fornirlo perché preferisco che se ne occupino loro, è quello per cui li pago).

Sul lato negativo, questo ha alcuni dei problemi comuni delineati anche nelle altre risposte. Una cosa di cui non sono orgoglioso ma che funziona è dare all'host di sviluppo un cambiamento al suo file host per far puntare il server di database alla copia di sviluppo. Così puoi mantenere una configurazione del database. Non è proprio figo, specialmente per le credenziali.

Backup Automatici

Tuttavia normalmente non mi preoccupo molto qui ma invece ho backup giornalieri che girano sui sistemi remoti che sono incrementali e che a loro volta sono memorizzati in un'altra posizione remota. Questo è facile ed economico e ti permette di ripristinare sia l'installazione di Wordpress che i file uploadati, il database e il repository git. Anche per i miei comandi di backup potrei non essere perfettamente a posto, ma quelli funzionano per me:

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

Quello che suggerisco qui è che tieni i processi intorno alla tua installazione di Wordpress fuori da Wordpress. Devono girare su un sistema specifico, quindi normalmente non li hai dentro l'applicazione (es. l'applicazione può andare giù ma hai bisogno che questi continuino a funzionare).

Abilitato per il Lavoro di Squadra

Un altro bel beneficio è che il tuo sito è già abilitato per il lavoro di squadra. Grazie al repository bare aggiuntivo non puoi sbagliare molto e puoi anche condividere branch remoti oltre a un master o live branch con i tuoi colleghi.