La forma más perfecta de transferir de un producto a otro [duplicado]

Cualquier diferencia entre dev y prod es mala. Esto es lo que hago:

• Tener una dirección IP diferente para el servidor dev (ya sea que la computadora interna, externa o local no sea importante), pero el servidor dev debe tener la misma configuración (consulte el párrafo inferior)
• Cambie el archivo de hosts (consulte aquí) (en el suyo o en una computadora de prueba) o una máquina virtual) para apuntar a dev server ip
• Resultado: las solicitudes HTTP enviadas al servidor dev tienen campo del encabezado del host establecido como "example.com" exactamente como lo será para el servidor prod .

Este método elimina dos diferencias que a menudo se encuentran de otra manera:

1. tener que cambiar el nombre de dominio
2. tener código dev en un subdirectorio, pero código de código en el subdirectorio root o diff. Esto se debe a que uso git para transferir archivos entre dev y prod.

.

.

El servidor dev está configurado exactamente igual que el servidor prod (consulte Chef o Puppet para saber cómo administrar servidores mediante programación).

En mi experiencia, he usado el complemento de búsqueda y reemplazo para volver a hacer referencia a todos De las referencias al antiguo dominio. No es la solución más limpia, pero parece funcionar.

Hago el mismo tipo de despliegue dev-prod de forma regular, por lo que desarrollé algunas consultas estándar para él:

1. Actualizar la url del sitio:

   ACTUALIZAR wp_options SET option_value = replace (option_value, '[DEV_URL]', '[PROD_URL]') WHERE option_name = 'home' OR option_name = 'siteurl' OR option_name = 'fileupload_url';

2. Actualizar la ruta de subida:

   ACTUALIZAR wp_options SET option_value = '[SITE_ROOT_PATH] / wp-content / uploads' WHERE option_name = 'upload_path';

3. Actualizar las guías de mensajes:

   ACTUALIZAR wp_posts SET guid = replace (guid, '[DEV_URL]', '[PROD_URL]');

4. Actualizar urls en publicaciones:

   ACTUALIZAR wp_posts SET post_content = replace (post_content, '[DEV_URL]', '[PROD_URL]');

Reemplace las variables entre corchetes con valores reales, por ejemplo.

[DEV_URL] - > enlace [PROD_URL] - > enlace [SITE_ROOT_PATH] - > /home/client/domains/example-online-server.com/html

Que normalmente se ocupa de cualquier referencia al entorno dev. Debe tener en cuenta, sin embargo, que:

i) Muchos complementos también almacenan direcciones URL absolutas en wp_options o tablas personalizadas. Estos tienes que investigar caso por caso.

ii) La ejecución de una consulta de reemplazo de actualización (como 1. y 2. más arriba) seguramente corromperá los datos en los campos serializados. No he encontrado una técnica limpia y rápida de hacer este reemplazo, aparte de dejar que los complementos asociados realicen la actualización ellos mismos. El éxito de esto depende de la robustez del complemento.

Me gusta desarrollar en un subdirectorio para que mis clientes puedan acceder al sitio de prueba. cuando estoy listo para publicar, uso un complemento (recomendaciones a continuación) para duplicar todo en otro subdirectorio y luego solo apunto a WordPress para que cargue uno nuevo. Dejando el área de desarrollo activa para la prueba.

Use un complemento como duplicator (gratis) o backupbuddy (pagado). También vea si mi pregunta aquí le ayuda.

No hay una manera perfecta de cómo WordPress almacena el contenido en la base de datos.

Para insertar código a su alrededor puede ser tan perfecto como usar git / mercurial / svn o incluso solo sobrescribir archivos.

Pero ese no es el caso de ningún contenido almacenado en la base de datos (complementos, publicaciones, categorías, etc.) y no hay una forma buena de sincronizar dos bases de datos. Cómo: Mover fácilmente una instalación de WordPress desde el desarrollo a la producción ?

Uso esta herramienta de búsqueda de reemplazo:

enlace

Funciona tanto para otro software como para wordpress.

En cuanto a la implementación, configuro un entorno en el servidor que luego puedo cambiar a través de la asignación de dominios / vhosts para hacerlos realidad. El Dev de instalación está siempre en un servidor separado, y nunca se pone en funcionamiento.