O Git / GitHub é uma boa solução de implantação do WordPress?

Atualmente, estou desenvolvendo meu WordPress localmente, enviando meu código para o GitHub com o Git e, em seguida, transferindo o SSH para o meu servidor e fazendo um "git pull" para atualizar meu código. Essa é uma boa opção para a implantação de código em um site WordPress (nesse caso, obviamente, tenho acesso no nível da raiz ao meu servidor.) Conheço coisas como Capistrano, mas isso seria um exagero para a implantação em um site WordPress? Como tirar o máximo proveito do Git / GitHub neste caso?

Eu uso o git para isso e acho que funciona muito bem. Algumas sugestões:

• Adicione o diretório do diretório de uploads (wp-content / uploads) ao seu .gitignorearquivo.
• Execute um servidor da Web e um servidor de banco de dados em seu sistema de desenvolvimento para poder testar as alterações localmente antes de enviá-las à produção.
• Mantenha as configurações de conexão do banco de dados consistentes entre dev e prod ou adicione wp-config.php ao seu .gitignorearquivo para evitar que as configurações do wordpress de desenvolvimento substituam as de produção.
• Evite atualizar plugins no seu sistema de produção usando a interface administrativa do Wordpress - como na melhor das hipóteses, sua cópia do git substituirá todos os plugins que você atualizar assim que você fizer o push / checkout, na pior das hipóteses você terá conflitos. Faça suas atualizações usando a interface administrativa do seu sistema de desenvolvimento, confirme, envie e faça check-out na produção.

• Considere adicionar um post-receivegancho git para fazer o checkout de suas atualizações automaticamente no diretório que você usa para publicar o wordpress através do seu servidor web (por exemplo /var/www). Isso permite que você verifique apenas os arquivos, evitando que os metadados do git encontrem o caminho da raiz do documento do servidor da web e também significa que você pode adicionar alterações de permissão no gancho pós-recebimento, para que suas permissões sejam sempre consistentes. Um exemplo está incluído abaixo:

  #!/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
  

Eu recomendo configurar o Capistrano - é um pouco de trabalho inicial na primeira vez, mas depois disso você pode usá-lo facilmente para novas configurações.

As principais vantagens são

• poder implantar a partir da área de trabalho. Pode não parecer muito, mas invadir o servidor remoto e fazer um git pull ainda é um problema.
• reversão fácil para uma versão anterior, se você precisar
• capaz de fazer coisas legais, como implantação de instalação em ambientes de preparação / produção.

Estou adicionando um conjunto de scripts capistrano para mostrar como eu configuro as coisas.

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 [email protected]: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"

e, finalmente, um arquivo de ambiente de amostra (se você usar a gema de vários estágios, poderá ter uma delas para cada estágio do seu ambiente, por exemplo, local, preparação, produção)

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

Esses arquivos podem não funcionar sem ajustes, e você precisará de algum conhecimento básico do Capistrano, mas espero que ajude algumas pessoas.

Este foi o primeiro tutorial que usei que me levou a usar o Capistrano e o WordPress: http://theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/

Na verdade, fiz uma apresentação do WordCamp sobre esse tópico. Em vez de me repetir, aqui está um screencast e um script de implantação muito simples para acompanhar o que discuti.

Em resumo, eu uso o GitHub para hospedar o repositório e uso um webhook para implantar alterações com base na referência do git. Isso permite que você use o modelo de ramificação git de Vincent Driessen e permite que você tenha ilimitados webheads, servidores de teste, servidores de teste etc., tudo com implantação automatizada. Também abordo a manutenção do wp-config.php sob controle de versão, mantendo versões separadas de desenvolvimento / produção (renomeando os arquivos e simbolizando).

Eu sei que essa pergunta é um pouco mais antiga, porém, como eu não vi isso como resposta aqui, gostaria de compartilhar o que normalmente faço para configurações e implantações baseadas em git de site único e está funcionando muito bem, também com o trabalho de vários dispositivos, locais e com vários desenvolvedores (todos com seus próprios repositórios locais em que operam, como é comum no git).

Posso sugerir calorosamente a seguinte configuração:

• Um fluxo de trabalho Git focado na Web (por Joe Maller; novembro de 2008)

Também é descrito em (se você precisar de um segundo recurso para envolvê-lo):

• Usando o Git para implantação (por Dan Barber; abril de 2011)

Basicamente, funciona (com pelo menos três repos) por:

1. colocando o site no host ao vivo sob git,
2. crie um novo repositório bare git no host ao vivo.
3. Depois, passe do repositório vazio para o seu repositório git de desenvolvimento local.

Quando o trabalho é concluído, você pressiona o repositório remoto remoto do qual clonou. O repositório simples possui ganchos para sincronizar com o repositório ativo (nos códigos acima chamados de prime ).

Como configurações específicas do Wordpress no repositório, tenho o seguinte .gitignore:

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

O resto incl. a configuração do plugin e do tema eu mantenho sob controle de versão / configuração. Isso me permite rastrear facilmente as alterações e revisar o código antes de usá-lo ao vivo. Também posso mesclar mais facilmente contra árvores remotas com minhas próprias alterações. Isso é especialmente útil no núcleo do Wordpress, disponível no Github .

Isso funciona muito bem para a maioria das minhas necessidades do Wordpress. O repositório simples impede que você faça alterações conflitantes. Ele também é sincronizado com uma cópia remota antes de atualizar o site ativo. Isso significa que atualizar o site ao vivo normalmente é bastante rápido. Por causa dos ganchos, você pode até chamar os ganchos de atualização do Wordpress depois, se quiser.

Se não tiver experimentado o quanto isso pode ser melhorado com os ganchos do Github, mas normalmente não preciso deles, pois o código está sob controle de versão local, não o Github.

Para configurar esse sistema pela primeira vez, você deve avaliar se possui todas as ferramentas disponíveis em seu host remoto:

• Acesso SSH
• GIT
• Um diretório privado no qual você pode colocar arquivos e subdiretórios (por exemplo, para o seu repositório bare git)

O tempo de configuração pela primeira vez deve ser possível dentro de uma duas horas, incl. todo o ambiente e você primeiro publica push.

Dependendo do seu host, você também pode querer proteger o .gitdiretório do acesso à web. Aqui está um exemplo de .htaccesscódigo que faz com que o Wordpress seja colocado dentro de um subdiretório, o que deixa espaço no repositório não publicado on-line (útil):

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]

Em resumo, tudo o que não está no diretório público não está online. Dentro do diretório público pode estar a base de código wordpress, por exemplo, para o .htaccessque você precisa então:

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

Isso impede o acesso direto ao público . Parte deste .htaccess -foo você pode encontrar descrito aqui: Os pedidos para .htaccess devem retornar 404 em vez de 403 . Para as variáveis ​​de ambiente, você precisa testar se isso funciona em seu ambiente. Além disso, você precisa decidir se coloca isso sob controle de versão ou não.

Se você tem mais controle sobre a hospedagem, pode fazer mais coisas aqui (e diferentemente / mais otimizado); os exemplos acima são direcionados para ambientes típicos de hospedagem compartilhada (que oferecem GIT, alguns usuários dizem que você pode instalá-lo facilmente como bem, normalmente peço aos meus anfitriões que o ofereçam, porque prefiro que eles tomem cuidado com isso.

No lado negativo, isso tem alguns dos problemas comuns também descritos nas outras respostas. Uma coisa de que não tenho orgulho, mas o que funciona é alterar o host de desenvolvimento em seu arquivo host para que o servidor de banco de dados aponte para a cópia de desenvolvimento. Então você pode manter uma configuração de banco de dados. Não é muito legal esp. por causa das credenciais.

Backups automáticos

No entanto, normalmente não me importo muito aqui, mas, em vez disso, os backups diários são executados nos sistemas remotos, que são incrementalmente armazenados em outro local remoto. Isso é fácil e barato e permite restaurar a instalação do Wordpress, bem como os uploads de arquivos, o banco de dados e o repositório git. Também para os meus comandos de backup, posso não estar perfeitamente bem, mas eles funcionam para mim:

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

O que eu sugiro aqui é que você mantenha os processos em torno da instalação do Wordpress fora do Wordpress. Eles precisam ser executados em um sistema específico, para que você normalmente não os tenha dentro do aplicativo (por exemplo, o aplicativo pode ficar inativo, mas é necessário que eles continuem funcionando).

Habilitado para trabalho em equipe

Outro benefício interessante é que seu site já está ativado para o trabalho em equipe. Graças ao repo bare adicional, você não pode fazer muita coisa errada e pode compartilhar ramificações remotas além de uma ramificação principal ou ao vivo com seus colegas.