Desarrollando, probando y lanzando

¿Cómo desarrollar, probar e implementar para vivir sus sitios de Wordpress?

Siempre es un poco raro, especialmente cuando se trata de bases de datos, principalmente debido al hecho de que tener un sitio de prueba necesita una nueva base de datos para ser implementada, que a veces puede ser EXACTAMENTE igual, excepto que todos los enlaces se cambian a prueba de URL del sitio, en lugar del sitio en vivo.

De manera similar, cualquier carga que los usuarios hayan subido desde la última vez que necesitó corregir un error o desarrollar algo nuevo deberá copiarse en el sitio de prueba.

¿Cómo lo hacen los demás? ¿Acabas de soportar el faff? ¿Utiliza sistemas inteligentes de control de versiones que ayudan?

Gracias

testing

— Thomas Clayson
fuente

Si hace que un sistema gire en torno a la alteración de su archivo de hosts , entonces nunca tendrá que manipular su base de datos de prueba. ( wordpress.stackexchange.com/a/10943/9142 )

— Alexander Bird

Hay un poco de filosofía personal que entra en un flujo de trabajo de implementación. No es una pregunta fácil de responder sin conocer su experiencia con los servidores y el control de versiones, su sistema operativo, alojamiento, experiencia del cliente y cultura tecnológica, etc.

Aquí hay una pregunta similar que tiene mucha explicación.
Para la implementación de contenido, puede consultar el complemento RAMP de Crowd Favorite .
WP Hackers es un excelente hilo para encontrar buena información sobre implementaciones.

Personalmente, me aseguro de no codificar nunca las URL absolutas en mis temas. Utilice bloginfo () o codifique las URL relativas. Utilizo muchos condicionales en mi archivo wp-config.php. Aquí hay una versión vainilla de mis ediciones de wp-config.

switch($_SERVER['SERVER_NAME']){
    case 'dev.yourdomain.com':
        $db_host = '';
        $db_pass = '';
        //define debugging
        break;
    case 'stage.yourdomain.com':
        $db_host = '';
        $db_pass = '';
        break;
    default: //Live
        $db_host = '';
        $db_pass = '';
}
define('DB_PASSWORD', $db_pass);
define('DB_HOST', $db_host);

//You could also set this as a variable above
define('WP_HOME', 'http://'.$_SERVER['SERVER_NAME']));
define('WP_SITEURL', 'http://'.$_SERVER['SERVER_NAME']));

Trabajo en muchos sitios que siguen el

local (piratería personal :) en el servidor web de mi computadora portátil)>
dev (prueba en el servidor del cliente)>
etapa (fuente estable de control de calidad - edición de contenido)>
producción (sitio en vivo)

Por último, te sugiero que uses una herramienta de control de versiones para ayudarte en tus implementaciones, como GIT o SVN. Facilita el proceso significativamente y mantiene la integridad de la fuente entre entornos. Comprometerse con su local se actualiza fácilmente a través de la línea de comandos en el escenario y la producción. Es mejor durante el descubrimiento definir qué control de versión utilizarán usted y el cliente desde el principio si tienen desarrolladores trabajando en el proyecto. Yo personalmente uso GIT para mi control de versiones. Sin embargo, si un cliente usa SVN, hago una combinación de los dos en mi local para mantener un repositorio para mí mientras me comprometo con su repositorio.

Raramente tenemos problemas para migrar de un entorno a otro. Hacemos una búsqueda / reemplazo en la base de datos para cambiar la URL en consecuencia para los medios incrustados, etc.

— Brian Fegter
fuente

¡Esto es muy útil! :) Muchas gracias. Entonces, cada vez que implementa en cada uno de los diferentes servidores, ¿duplica la base de datos del sitio en vivo? Usted dice que implementa en un servidor de ensayo (stage.domain.com) para control de calidad y edición de contenido. ¿Qué sucede si la base de datos cambia mientras ejecuta el servidor de escenario en el sitio en vivo? es decir, usted o su cliente inician sesión en el escenario y actualizan parte del contenido, pero al mismo tiempo, ¿un colaborador publica un nuevo artículo en el sitio en vivo? ¿Simplemente efectúa las ediciones de contenido OTRA VEZ en el sitio en vivo? ¿Cómo aborda los cambios en la estructura de la base de datos?

— Thomas Clayson

¡Perdón por todas las preguntas! : p Estoy muy agradecido por su tiempo y ayuda.

— Thomas Clayson

En un nuevo conjunto de características, puede extraer desde prod> stage. Agregue el contenido para la nueva función y luego retroceda etapa> prod. A partir de ahí, stage es una copia de alta fidelidad de prod y puede extraer stage> dev. No es frecuente que retiremos la base de datos del escenario. La mayoría de los intercambios con el DB ocurren de etapa a producción a menos que una característica cambie la arquitectura db.

— Brian Fegter

Si desea utilizar el escenario para la implementación de contenido y nunca tocar prod, puede consultar el complemento RAMP que publiqué anteriormente.

— Brian Fegter

Haga clic en +1 todo lo anterior, con la condición de que algunos complementos irritantes insistan en almacenar URL en matrices serializadas, lo que puede estropear mover cosas de la base de datos de un entorno a otro. El problema es que las matrices serializadas almacenan longitudes de cadena y se borken cuando la longitud cambia. Por lo tanto, recomendaría que los nombres de dominio de env sean los mismos si es posible, por ejemplo, dev.example.com, tst.example.com, www.example.com etc.

— webaware