¿Tiene alguna estrategia efectiva para lanzar una v2 de un sitio WP?


12

Mi equipo y yo estamos trabajando con un cliente que tiene un sitio de WordPress existente con bastante contenido y un tema personalizado que crearon. Es un blog grupal, lo que significa que tiene varios bloggers en todo el mundo que agregan y editan contenido todo el tiempo.

Nuestro trabajo es crear un tema completamente nuevo, con bastantes características nuevas. Algunas de estas características requerirán nuevos widgets personalizados, complementos y campos de bases de datos.

Actualmente estamos trabajando en nuestras propias máquinas de desarrollo y las estamos integrando en un único servidor de desarrollo. Todo el código está versionado en SVN. Nuestro DBA designado está fusionando manualmente cualquier cambio de base de datos en la base de datos de desarrollo en este momento, aunque esperamos que pueda automatizarlo pronto.

Acabamos de empezar a hablar sobre nuestro proceso de lanzamiento de producción. Significado: una vez que hayamos terminado, ¿cómo vamos a obtener todo nuestro código personalizado en el servidor de producción (en vivo) sin problemas y con la menor interrupción posible?

Tenemos algunos planes en mente, pero me encantaría saber cómo otros han abordado este problema también. ¿Hay alguna mejor práctica a seguir o escollos conocidos para evitar?

Respuestas:


4

Si sigue los consejos de SethMerrick, puede reducir en gran medida el tiempo de conmutación reduciendo el TTL en los registros DNS apropiados a 5 minutos más o menos varias horas (dependiendo de cuál sea el TTL actual) antes de cambiar la dirección IP.

Al hacer esto, le está diciendo a los servidores DNS remotos que solo almacenen en caché la dirección durante 5 minutos. Una vez que cambie la IP, puede aumentar el TTL a lo que era antes. Para minimizar aún más el efecto, realice el cambio durante un período de tráfico bajo.


Acabamos de empezar a hacer eso, por coincidencia. Definitivamente ayuda. No podemos permitirnos un largo período de implementación. ¡Gracias por agregar ese consejo!
Mike Lee

Tenga en cuenta que debe cambiar el TTL tanto tiempo antes de cambiar realmente la IP . En otras palabras, si TTL es una semana, debe cambiar el TTL a 5 minutos una semana antes de cambiar la IP, para que todos estén en el nuevo TTL cuando lo hagan.
Daniel C. Sobral

2

No estoy seguro de si esto es aplicable, pero acabo de pasar por un proceso similar de migrar y actualizar simultáneamente un sitio de alto tráfico.

La estrategia básica era trabajar en un servidor provisional, luego, cuando todo estuviera listo, hacer un volcado mysql en el servidor en vivo, importarlo al servidor intermedio, hacer cualquier limpieza requerida, luego apuntar los registros DNS al servidor intermedio, causando el servidor provisional para convertirse en el nuevo servidor en vivo.

El truco es fusionar todos los datos que se acumulan durante la propagación de DNS en el servidor provisional (que ahora es el servidor en vivo). En otras palabras, si transcurren 30 horas entre el momento en que realiza el volcado / actualización de DNS de mysql y cuando se completa la propagación del DNS, deberá fusionar selectivamente 30 horas de registros del sitio antiguo al nuevo.

No es un proceso continuo, pero para cuando teníamos una semana en el camino, todos los problemas se habían solucionado.


En este escenario, ¿haría que el sitio antiguo fuera de solo lectura mientras el DNS está en transición para evitar cambios en el sitio que no se migrarán?
Trevor Bramble

Ese es un enfoque alternativo, para evitar que se agreguen datos nuevos a la base de datos del sitio anterior durante la transición. Sin embargo, el enfoque que mencioné anteriormente deja el sitio antiguo activo durante la transición, luego combina manualmente las entradas de db adicionales que aparecieron durante la transición (nuevas publicaciones, comentarios, etc.) en el nuevo sitio. editar: solo quería mencionar que la sugerencia de Acterry sobre TTL Records es un consejo fantástico.
SethMerrick

Hemos hecho algo similar a eso. No es perfecto, pero bueno, funciona.
Mike Lee

2

@ Mike Lee: Gran pregunta, y uno de los santos griales de WordPress (o cualquiera de los principales CMS de código abierto con los que estoy familiarizado para ese asunto, como Drupal, Joomla, et al.)

Si bien ciertamente no está destinado a abordar su caso de uso, consulte mi respuesta a una pregunta relacionada que describe un complemento de nivel beta que acabo de poner a disposición a través de WordPress Answers Exchange llamado WP Migrate Webhosts (sí, apesta cuando se trata de nombres creativos .)

Pero también quiero resolver el caso de uso que describe con un complemento y actualmente estoy pensando en cómo lograrlo. Estoy pensando que la forma de abordarlo es dejar de resolverlo genéricamente y, en cambio, abordar los patrones conocidos que existen en WordPress y luego permitir que cualquier otra persona " enganche " mi complemento para casos de uso especiales. También estoy pensando que un enfoque es serializar los datos y las estructuras en WordPress como datos en un archivo PHP para que un complemento futuro pueda aplicar esos cambios como deltas al igual que un sistema de control de código fuente aplica los deltas para llegar a la versión actual de la fuente código.

Entonces, si bien no estoy respondiendo o resolviendo su problema en su totalidad, espero darle una buena idea para pensar y también espero que usted u otra persona quieran colaborar en una eventual solución.


WP Migrate Webhosts suena como un complemento muy necesario. ¡Gracias por compartir eso y esta retroalimentación!
Mike Lee

Sí, eso creo. ¡Espero obtener colaboración para que yo y otros podamos desarrollarla para que sea muy útil! Gracias por el voto positivo.
MikeSchinkel
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.