localhost + staging + entornos de producción?

Question

Tengo un sitio web que dice www.livesite.com que se está ejecutando actualmente. He estado desarrollando una nueva versión del sitio web 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 servidor livesite.com pero bajo otro dominio (es el mismo entorno) como 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 copiar & 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 prueba donde insertar actualizaciones, probarlas y una vez que me haya conformado con moverme a lives.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 directorio 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!

Answer 1

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 cree que eso es excesivo, aquí está la manera del pobre de hacerlo 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 directorio real. Lo que significa que tiene 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 usted puede comprobar fuera de código en la producción (por ejemplo, miproyecto-1-1-2) se sirve sin sobrescribir cosas. A continuación, puede cambiar bases de código casi al instante haciendo algo como:

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

Me gustaría recomendar más no hacer una exportación svn checkout/SVN de su tronco en el cuadro de la producción. En su lugar, crea una rama antes de tiempo (llámalo algo así como myproject-X-Y-Z). De esta forma si lo que necesita hacer algunos ajustes muy estresante de código de producción, se puede cometer de nuevo a la rama, y ​​fusionarla nuevo en el tronco una vez que se apagó el fuego)

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

Principalmente, usted tiene que manejar migraciones de bases de datos u otras secuencias de comandos 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 tiempo de inactividad de, afortunadamente, solo un minuto podría no ser una mala idea. Puede mantener un "sitio de mantenimiento" alrededor (/ 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 ejecuta en un solo servidor, con bases de datos no grandes), a menudo es lo suficientemente bueno y simple.

Answer 2

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

yo para este tipo de escenario utilizar Hudson.

Hudson permitirá que usted tenga un auto desplegar/limpiar el directorio actual a cabo/añadir nuevos desde SVN proceso. A continuación, puede preocuparse por el desarrollo y menos sobre malabarismo e implementación de un lugar a otro.

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

cómo empezar con PHP for Hudson

Creo que debe obtener en el camino correcto, un poco de trabajo, como he dicho, pero vale la pena más adelante.

Answer 3

Si solo cambia el código del lado del servidor, 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 base de datos también cambia, entonces debe asegurarse de que no ocurran transacciones en la base de datos durante el tiempo en que está aplicando las secuencias de comandos de cambio de la base de datos.

En todos los casos, e independientemente de si está utilizando alguna herramienta de integración continua, creo que es más seguro ir por el tiempo de inactividad para aplicar estos cambios. Una de las razones por las cuales las personas tienen la etiqueta "beta" en sus sitios es para que puedan cerrar la sesión 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 tiempo de inactividad con semanas de anticipación, luego obtiene una ventana de 30 minutos a unas pocas horas para aplicar todos los cambios.

Para cosas subyacentes como parches de fallas de seguridad en el SO o software del sistema, agregar hardware, etc., se puede evitar el tiempo de inactividad si hay equilibrio de carga, y los parches se aplican uno por uno.