¿Es Git / GitHub una buena solución de implementación de WordPress?

Actualmente estoy desarrollando mi WordPress localmente, enviando mi código a GitHub con Git y luego SSHing en mi servidor y haciendo un "git pull" para actualizar mi código. ¿Es esta una buena opción para la implementación de código en un sitio de WordPress? ¿Cómo puedo aprovechar al máximo Git / GitHub en este caso?

Utilizo git para esto y me parece que funciona muy bien. Algunas sugerencias

• Agregue su directorio de directorio de cargas (wp-content / uploads) a su .gitignorearchivo.
• Ejecute un servidor web y un servidor de base de datos en su sistema de desarrollo para que pueda probar los cambios localmente antes de llevarlos a producción.
• Mantenga la configuración de conexión de la base de datos coherente entre dev y prod, o agregue wp-config.php a su .gitignorearchivo para evitar que su configuración de desarrollo de wordpress sobrescriba las de producción.
• Evite actualizar complementos en su sistema de producción utilizando la interfaz de administración de Wordpress, ya que, en el mejor de los casos, su copia git sobrescribirá los complementos que actualice tan pronto como presione / finalice la compra, en el peor de los casos obtendrá conflictos. Realice sus actualizaciones utilizando la interfaz de administración en su sistema de desarrollo, confirme, envíe y finalice la producción.

• Considere agregar un post-receivegancho de git para verificar sus actualizaciones automáticamente en el directorio que utiliza para publicar WordPress a través de su servidor web (por ejemplo /var/www). Esto le permite verificar solo los archivos, evitando que los metadatos git lleguen a la raíz de documentos de su servidor web, y también significa que puede agregar cualquier cambio de permiso en el enlace posterior a la recepción para que sus permisos permanezcan consistentes cada vez. A continuación se incluye un ejemplo:

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

Recomiendo encarecidamente configurar Capistrano: es un poco un trabajo inicial la primera vez, pero después de eso puede usarlo fácilmente para nuevas configuraciones.

Las principales ventajas son

• poder implementar desde su escritorio. Puede que no parezca mucho, pero meterse en el servidor remoto y hacer un tirón todavía es una molestia.
• fácil retroceso a una versión anterior si necesita
• capaz de hacer cosas interesantes como la implementación de la configuración en entornos de preparación / producción.

Estoy agregando un conjunto de secuencias de comandos de capistrano para mostrarle cómo configuro las cosas.

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"

y finalmente, un archivo de entorno de muestra (si usa la gema de varias etapas, puede tener uno de estos para cada etapa de su entorno, por ejemplo, local, puesta en escena, producción)

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

Es posible que estos archivos no funcionen sin ajustes, y necesitará algunos conocimientos básicos de Capistrano, pero con suerte ayudará a algunas personas.

Este fue el primer tutorial que utilicé que me puso en marcha con Capistrano y WordPress: http://theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/

Realmente hice una presentación de WordCamp sobre este tema. En lugar de repetirme, aquí hay un screencast de él y aquí hay un script de implementación muy simple para acompañar lo que discutí.

En resumen, uso GitHub para alojar el repositorio y uso un webhook para implementar cambios basados ​​en la referencia de git. Esto le permite usar el modelo de ramificación git de Vincent Driessen y lo abre a tener cabezas web ilimitadas, servidores de prueba, servidores de prueba, etc., todo con implementación automatizada. También cubro el mantenimiento de wp-config.php bajo control de versiones mientras mantengo versiones separadas de desarrollo / producción (renombrando los archivos y enlaces simbólicos).

Sé que esta pregunta es un poco más antigua, sin embargo, como no he visto esto como respuesta aquí, me gustaría compartir lo que normalmente hago para configuraciones e implementaciones basadas en git de un solo sitio y está funcionando muy bien, también con el trabajo desde múltiples dispositivos, ubicaciones y con múltiples desarrolladores (todos tienen sus propios repositorios locales en los que operan, ya que es común para git).

Puedo sugerir con entusiasmo la siguiente configuración:

• Un flujo de trabajo Git centrado en la web (por Joe Maller; noviembre de 2008)

También se describe en (si necesita un segundo recurso para entenderlo):

• Uso de Git para la implementación (por Dan Barber; abril de 2011)

Básicamente funciona (con al menos tres repositorios):

1. poner el sitio web en el host en vivo bajo git,
2. cree un nuevo repositorio de git desnudo en el host en vivo.
3. Y luego bifurca desde el repositorio desnudo a tus repositorios de desarrollo local de git.

Cuando el trabajo está hecho, empujas contra el repositorio desnudo remoto desde el que has clonado. El repositorio simple tiene ganchos para sincronizarse con el repositorio en vivo (en los códigos anteriores llamados prime ).

Como configuración específica de Wordpress en el repositorio, tengo esto .gitignore:

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

El resto incl. la configuración del complemento y el tema que mantengo bajo control de versión / configuración. Esto me permite rastrear fácilmente los cambios y revisar el código antes de usarlo en vivo. También puedo fusionarme más fácilmente contra árboles remotos con mis propios cambios. Eso es especialmente útil contra el núcleo de Wordpress que está disponible en Github .

Esto funciona bastante bien para la mayoría de mis necesidades de Wordpress. El repositorio simple evita que empujes cambios conflictivos. También se sincroniza con una copia remota antes de actualizar el sitio en vivo. Eso significa que la actualización del sitio en vivo suele ser bastante rápida. Debido a los enlaces, incluso puede llamar a los enlaces de actualización de Wordpress después si lo desea.

Si no he experimentado cuánto se puede mejorar con los ganchos de Github, pero normalmente no los necesito ya que el código está bajo control de versión local, no Github.

Para configurar dicho sistema por primera vez, debe tomarse un tiempo para evaluar si tiene todas las herramientas disponibles en su host remoto:

• Acceso SSH
• GIT
• Un directorio privado en el que puede colocar archivos y subdirectorios (por ejemplo, para su repositorio de git)

El tiempo de configuración por primera vez debe ser posible dentro de una dos horas incl. todo el entorno y primero publicas push.

Dependiendo de su host, es posible que también desee proteger el .gitdirectorio del acceso web. Aquí hay un .htaccesscódigo de ejemplo que incluso lo hace teniendo Wordpress dentro de un subdirectorio, lo que deja espacio en el repositorio no publicado en línea (ú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]

En resumen, todo lo que no está dentro del directorio público no está en línea. Dentro del directorio público puede estar la base de código de WordPress, por ejemplo, para lo .htaccessque necesita entonces:

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

Esto impide el acceso directo al público . Parte de este .htaccess -foo se puede encontrar aquí: Las solicitudes a .htaccess deben devolver 404 en lugar de 403 . Para las variables de entorno, debe probar si eso funciona en su entorno. También debe decidir si lo pone bajo control de versión o no.

Si tiene más control sobre el alojamiento, puede hacer más cosas aquí (y de manera diferente / más optimizada), los ejemplos anteriores están dirigidos a entornos de alojamiento compartido típicos (que ofrecen GIT, algunos usuarios dicen que puede instalarlo fácilmente como suyo) bueno, normalmente les pido a mis anfitriones que me lo proporcionen porque prefiero que si se cuidan, eso es lo que les pago).

En el lado negativo, esto tiene algunos de los problemas comunes también descritos en las otras respuestas. Una cosa de la que no estoy orgulloso es que lo que funciona es darle al host de desarrollo un cambio en su archivo de host para que el servidor de la base de datos apunte a la copia de desarrollo. Para que pueda mantener una configuración de base de datos. No es realmente genial esp. por las credenciales

Copias de seguridad automáticas

Sin embargo, normalmente no me importa mucho aquí, sino que tengo copias de seguridad diarias que se ejecutan en los sistemas remotos, que se almacenan gradualmente en otra ubicación remota. Eso es fácil y barato y le permite restaurar tanto la instalación de Wordpress como las cargas de archivos, la base de datos y el repositorio de git. También para mis comandos de copia de seguridad podría no estar perfectamente bien, pero esos funcionan para mí:

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

Lo que sugiero aquí es que mantenga los procesos alrededor de su instalación de Wordpress fuera de Wordpress. Deben ejecutarse en un sistema específico, por lo que normalmente no los tiene dentro de la aplicación (por ejemplo, la aplicación puede fallar, pero necesita que estos continúen funcionando).

Habilitado para trabajo en equipo

Otro buen beneficio es que su sitio ya está habilitado para el trabajo en equipo. Gracias al repositorio simple adicional, no puede hacer mucho mal e incluso puede compartir ramas remotas aparte de una rama maestra o en vivo con sus colegas.