¿Cómo liberar aplicaciones web?

Question

Realmente no sé cómo realizar la implementación desde el desarrollo fuera de línea al servidor web en vivo correctamente en el desarrollo web. Principalmente recurro a la intuición, pero esto es más o menos lo que hice hasta ahora: tengo una aplicación web en python, o php, y la estoy hospedando en un servidor web en vivo. Utilizo una versión de desarrollo fuera de línea cuyo origen está bajo svn.

Ahora, a medida que desarrolle la versión fuera de línea, realizaré confirmaciones para el svn. Cuando ha llegado el momento de la liberación, que pude ya sea:

1. copiar el código desde el servidor sin conexión a un directorio temporal en el servidor web en directo, a continuación, cambiar el antiguo código base con la nueva (por ejemplo, con un enlace.), o ...
2. tienen el servidor web en vivo trabajando en un check-in svn, y simplemente ejecute svn update.

Normalmente yo el segundo, aunque si tengo que actualizar la base de datos antes del despliegue en vivo, yo suelo escribir actualización de secuencias de comandos SQL, y ejecutarlas en la primera base de datos activa, entonces la salida.

¿Cuáles son las mejores prácticas para esta tarea?

Answer 1

Recomiendo aprovechar la exportación de SVN en lugar de finalizar la compra. De esta forma, no expondrá ninguno de los archivos SVN al mundo. También generalmente crea una estructura de carpeta más limpia.

He aprovechado rsync antes al mover archivos entre el escenario y la producción.

mis ingresos típicos de implementación de la siguiente manera:

• planta de producción de copia de seguridad
• Restaurar desde copia de seguridad a la etapa servidor
• bloqueo del servidor desde todas las direcciones IP externas
• exportar el código desde el repositorio en una carpeta temporal (opcionalmente diferencia las dos carpetas para pequeños cambios)
• archivos rsyc de la carpeta temp a la carpeta del servidor de escenario
• Valida que solo hayan cambiado los archivos que esperas haber cambiado.
• Aplicar scripts SQL a la base de datos
• Prueba de la actualización
• Desbloquear el servidor web

Ahora, para implementar en la producción, reproducir estos pasos en el avance rápido. Usar scripts lo hace mucho más fácil.

Answer 2

En teoría, exportaría el svn a una nueva área en el servidor web. Luego, reconfigure el servidor web para usar el área nueva y reiniciar.

Answer 3

Debería considerar algunos scripts de implementación para automatizar todo esto. le ayudará a evitar que cometa errores. Los scripts de actualización SQL son una forma de vida, pero siempre debe probarlos en una copia de la base de datos en vivo antes de ejecutarlos en la versión real.

Lo que podría considerar tener es un servidor de almacenamiento intermedio. Realiza los cambios locales, luego svn checkout en el servidor de transición y también ejecuta los scripts de actualización. Haz tu prueba de aceptación en el servidor de transición. Cuando todo está bien, implementa everhting en el servidor en vivo. Esto debería ser tan simple como ejecutar algunos scripts. es decir, update-staging.pl y update-prod.pl.

Puede hacer que su script sql sea más fácil de automatizar agregando una tabla de versiones a su db. cada vez que crea un script de actualización, lo etiqueta con una versión. a continuación, la secuencia de comandos de implementación puede examinar la versión de su secuencia de comandos de actualización y la versión de la base de datos y aplicar las actualizaciones según sea necesario. esto también hace posible la restauración de copias de seguridad. Si ha realizado cambios, luego restaure a una copia de seguridad, solo ejecuta su secuencia de comandos de actualización y la actualiza y la actualiza a la versión actual.

Answer 4

Yo uso Capistrano para la secuencia de comandos & automatizar el proceso de implementación. Aquí hay un resumen de lo que sucede cuando ingreso cap deploy desde mi estación de trabajo local:

Capistrano will. . .

1. Pedido última versión de la fuente en un directorio con marca de tiempo (por ejemplo, a /var/http/mywebsite.com/releases/20090715014527) en mi servidor web, me llevó a @ mi estación de trabajo local para cualquier contraseña, si es necesario.

2. ejecutar secuencias de comandos pre-procesamiento (por ejemplo, esquema de base de actualización)

3. enlace suave del sitio a un directorio en vivo:

   En -sf /var/http/mywebsite.com/releases/20090715014527/var/http// mywebsite.com actuales guiones post-procesamiento

4. Run (por ejemplo, tal vez usted necesita para reiniciar Apache o algo así)

Si hubo algún problema en el camino, Capistrano retrocederá a la versión anterior de trabajo.

Aunque Capistrano está escrito en Ruby, puede implementar aplicaciones web en cualquier idioma/marco. Consulte el "Deploying non-rails apps" section of the tutorials para obtener ideas. El railsless-deploy parece particularmente útil para usar Capistrano para administrar la implementación de aplicaciones PHP y Python.

Answer 5

para pequeños sistemas, basado en PHP, lo que solíamos hacer es esto:

de cambios en el código, se utiliza una secuencia de comandos de hormigas corriendo de eclipse que compara el sistema local (dev) con el mando a distancia (QA/prod/whatever) sistemas, luego comprime todos los archivos modificados, baja el zip al sistema remoto y descomprímelo en el objetivo. Por supuesto, hemos automatizado copias de seguridad y cosas así. Si esto es de interés, podría publicar un script de ejemplo en los próximos días.

para cambios sql, tratamos de mantener un scripts para cada cambio (por lo general en nuestro error-rastreador) y ejecutamos manualmente cada cambio en el sistema de destino.

para sistemas grandes, realmente deberías usar algo más robusto.

tenga en cuenta que si su sistema prod está extrayendo directamente de svn, está descargando cambios que podrían no haber sido probados correctamente (puede olvidar comprometer algo, probar su sistema local, y todo se rompería en prod ...)

Answer 6

Recomendaría la primera opción. Si tiene una estructura donde puede poner versiones del código y cambiar entre ellas cambiando un enlace, es mucho más fácil retroceder que si solo tiene un check de svn. Con svn, debes fusionarte con una versión anterior para revertir.