¿Cómo ejecuto una versión de una aplicación web mientras desarrollo la próxima versión?

Question

Acabo de terminar una aplicación de Django sobre la que deseo recibir comentarios de usuarios externos. Me gustaría lanzar una versión y luego bifurcar una versión privada para poder incorporar comentarios y agregar más funciones. Estoy planeando hacer muchas pequeñas iteraciones de este proceso. Soy nuevo en el desarrollo web; ¿cómo los sitios web suelen hacer esto? ¿Es simplemente una cuestión de copiar mi carpeta de proyecto Django a otro directorio, iniciar el servidor allí y continuar mi trabajo de desarrollo en el directorio original? ¿O me gustaría usar un sistema de control de versiones en su lugar? Mi intuición es que es lo último, pero si es así, parece ser un tema enorme con muchos usos (por ejemplo, colaboración, que no se aplica aquí) y realmente no sé por dónde empezar.

Answer 1

1) Separadas las URL www.yoursite.com vs test.yoursite.com. también puede hacer www.yoursite.com y www.yoursite.com/development, etc. También puede crear un/beta o/staging ...

2) Mantener bases de datos separadas, una para producción y otra Para desarrollo. Escriba una secuencia de comandos que copiará su base de datos en vivo en una base de datos de desarrollo. Mantenga una base de datos para cada tipo de sitio que cree. (Es posible que desee crear una base de datos beta o provisional para su tester). Haga su propio trabajo en la base de datos de desarrollo. Si cambia la estructura de la base de datos, guarde los cambios como un archivo .sql que puede cargarse y ejecutarse en la base de datos del sitio en vivo cuando active esos cambios.

3) Fusiona funciones en tus diferentes sitios con control de versiones. Actualmente estoy jugando con una configuración de subversión para aplicaciones web que tiene mi estable (troncal), una para organizar y otra para el desarrollo. Las etiquetas de desarrollo + ramas se fusionan en etapas, y luego las etiquetas/ramas de etapas se fusionan en estables. El control de versiones le permitirá administrar su código fuente de la manera que desee. Tendrás que encontrar una metodología que funcione para ti y usarla.

4) Considere la automatización de compilación. Publicará su sitio automáticamente. Eche un vistazo al http://ant.apache.org/. Puede impulsar una gran cantidad de comprobación automática de su código y subirlo a cada sitio específico que pueda necesitar.

5) Juguete del mes: Hay una utilidad llamada cUrl que puede ser valiosa. Hace mucho desde la línea de comando. Esto podría estar bien para usted en caso de que no quiera usar todo o ninguno de Ant.

¡Buena suerte!

Answer 2

Normalmente usaría el control de versiones y tendría dos dominios: su-site.com y test.your-site.com. Luego, su sitio web siempre se actualizará a trunk, que es la última versión de envío. Haría su desarrollo en una rama de trunk y test.your-site.com se actualizaría a eso. Luego, periódicamente fusiona los cambios de su rama de desarrollo a troncal.

Answer 3

Lo que hago es exportar una copia de mi repositorio SVN y poner los archivos en el servidor de producción en vivo, y luego mantener una máquina virtual con una copia de trabajo de desarrollo, y enviar los cambios al repositorio cuando termine.

Answer 4

Jas Panesar tiene la mejor respuesta si estás preguntando esto desde el punto de vista del desarrollo, sin duda. Es decir, si solo está preguntando cómo mantener fácilmente sus nuevos desarrollos separados del sitio que ya se está ejecutando. Sin embargo, si su pregunta en realidad era preguntar cómo ejecutar ambas versiones simultáneamente, entonces aquí están mis dos centavos.

Su configuración tiene mucho que ver con esto, pero siempre recomiendo ejecutar servidores web basados ​​en procesos en primer lugar.Es decir, no usar servidores con subprocesos (menos relevante para esta pregunta) y no incrustar en el servidor web (es decir, no usar mod_python, que es la parte relevante aquí). Por lo tanto, tiene uno o más procesos que reciben solicitudes HTTP de su servidor web (Apache, Nginx, Lighttpd, etc.). Ahora, cuando desee probar algo en vivo, sin afectar su sitio de ejecución normal, puede abrir un proceso que atiende solicitudes que nunca obtienen las solicitudes regulares representadas como lo hacen las demás. Es decir, los usuarios normales no lo ven.

Puede configurar un subdominio que apunte a este, y puede instalar el middleware que redirige al usuario "especial" a la versión beta. Esto le permite desplegar nuevas funciones para algunos usuarios, pero no para otros.

Ahora, los mayores problemas se presentan con los cambios en la base de datos. La migración de esquemas es un gran problema y la mayoría de nosotros nunca le prestamos atención. Creo que correr uno al lado del otro es genial, porque te obliga a realizar migraciones de esquema correctamente. Es decir, no puede cerrar todo y ejecutar largos cambios de esquema antes de volver a subirlo. Nunca verías ningún sitio remotamente importante haciendo eso.

La clave está en esos pequeños pasos. Siempre debe tener dos versiones de su código que puedan acceder a la misma base de datos, por lo que los cambios que realice en el nuevo código no deben romper el código anterior. Esto se divide en unos pocos pasos que siempre puede realizar:

• Puede agregar una columna con un valor predeterminado, o que es opcional. El nuevo código puede usarlo, y el código anterior puede ignorarlo.
• Puede actualizar la versión en vivo con un código que sepa que debe usar una nueva columna, en cuyo punto puede hacerlo necesario.
• Puede hacer que la nueva versión ignore una columna, y cuando se convierta en la versión principal, puede eliminar esa columna.

Puede realizar estos pequeños pasos para migrar entre cualquier esquema. Puede agregar iterativamente una nueva columna que reemplaza a una anterior, implementar el nuevo código y eliminar la columna anterior, todo sin interrumpir el servicio.

Dicho esto, ¿es tu primera aplicación web? Probablemente puedas romperlo. Probablemente tengas pocos usuarios :-) Pero es fantástico que incluso estés haciendo esta pregunta. Muchos "profesionales" son justos de preguntar, y aún así pocos lo responden.