localhost + escenarios + entornos de producción?

Tengo un website que dice www.livesite.com que se está ejecutando actualmente. He estado desarrollando una nueva versión del website en mi máquina local con http: // localhost y luego comprometiendo mis cambios con svn a www.testsite.com donde probaría el sitio en el server livesite.com pero bajo otro dominio ( es el mismo entorno que el sitio en vivo, pero bajo un dominio diferente).

Ahora estoy listo para lanzar la nueva versión a livesite.com. Hacerlo la primera vez es fácil, podría simplemente copyr y pegar todo desde testsite.com a livesite.com (no estoy seguro de que sea la mejor manera de hacerlo).

Quiero mantener a testingite.com como un sitio de testing en el que enviaría actualizaciones, las verificaría y una vez que esté satisfecho me mudaré a livesite.com pero no estoy seguro de cómo hacerlo después de que se lanza el nuevo sitio. No creo que copie Pegar todo el directory es la forma correcta de hacerlo y romperá las operaciones de los usuarios actuales en livesite.com.

También quiero mantener mi historial de svn en testsite.com. ¿Cuál es la forma correcta de hacer esto con SVN? Muchas gracias!

Otras respuestas que mencionan a Hudson o Weploy son buenas. Cubren más problemas que lo que sigue. Dicho esto, lo siguiente puede ser suficiente.

Si crees que eso es excesivo, aquí está la forma de hacerlo del pobre hombre con SVN y un poco de administración de sistemas creativa.

Haga que su raíz de documento de orgullo sea un enlace simbólico, no un directory real. Lo que significa que tienes algo como esto:

/var/www/myproject-1-0-0 /var/www/myproject-1-1-0 /var/www/myproject-1-1-1 /var/www/html -> myproject-1-1-1 

Esto significa que puede verificar el código en la producción (por ejemplo, myproject-1-1-2) sin sobreescribir las cosas que se están publicando. Luego puede cambiar las bases de código casi instantáneamente haciendo algo como:

 $ rm html && ln -s myproject-1-1-2 html 

Recomiendo además no hacer una export de svn / svn export de tu trunk en el cuadro de producción. En su lugar, cree una twig antes de time (nómbrelo como myproject-XYZ). De esta manera, si necesita hacer un ajuste muy estresante del código de producción, puede volver a enviarlo a la twig y volver a fusionarlo con el tronco una vez que el fuego se haya extinguido.

Hago esto mucho, y funciona bastante bien. Sin embargo, tiene algunos inconvenientes importantes:

Principalmente, usted debe manejar migraciones de bases de datos u otras secuencias de commands de actualización, todo usted mismo. Si tiene scripts (SQL simple o algo más complicado), debe pensar cuál es la mejor manera de ejecutarlos. El time de inactividad de, afortunadamente, solo un minuto podría no ser una mala idea. Puede mantener un "sitio de mantenimiento" alnetworkingedor (/ var / www / mainenance), y apuntar el enlace simbólico allí por unos momentos si es necesario.

Este método no es tan bueno como Weploy, por ejemplo, pero para proyectos relativamente pequeños (que se ejecutan en un único server, con bases de datos no grandes), a menudo es lo suficientemente bueno y simple.

Mi respuesta complicará las cosas un poco, pero aquí va:

Para este tipo de escenario, usaría Hudson .

Hudson le permitirá tener una implementación automática / limpiar el directory actual / agregar nuevo desde el process svn . A continuación, puede preocuparse por el desarrollo y less sobre malabarismo e implementación de un lugar a otro.

La advertencia es que debe aprender un poco sobre cómo configurar Hudson y cómo hacer que trabaje para usted.

Cómo comenzar con PHP para Hudson

Creo que eso debería llevarlo por el buen path, un poco de trabajo como dije, pero vale la pena más adelante.

Si solo cambia el código del lado del server, es posible que simplemente copie el código y todo estará bien. Pero incluso allí hay que pensar en la posibilidad de que las personas interactúen a medias. Si el código del lado del cliente cambia, especialmente si está utilizando fuertemente ajax, tendrá que hacer que los usuarios actuales vuelvan a cargar sus páginas. Si la database también cambia, entonces debe asegurarse de que no ocurran transactions en la database durante el time en que está aplicando las secuencias de commands de cambio de la database.

En todos los casos, e independientemente de si está utilizando alguna herramienta de continuous integration, creo que es más seguro recurrir al time de inactividad para aplicar estos cambios. Una de las razones por las cuales las personas tienen la label "beta" en sus sitios es para que puedan cerrar la session y cerrarlas para aplicar cambios sin previo aviso. Siempre y cuando no lo hagan con mucha frecuencia, también pueden salirse con la suya. Una vez que sale de la versión beta, la aplicación de cambios se convierte en una ceremonia en la que comienza a anunciar el time de inactividad con semanas de anticipación, luego obtiene una window de 30 minutos a unas pocas horas para aplicar todos los cambios.

Para aspectos subyacentes como el parcheo de fallas de security en el sistema operativo o software del sistema, la adición de hardware, etc., se puede evitar el time de inactividad si hay equilibrio de carga, y los parches se aplican uno por uno.