Qué doloroso es una implementación del proyecto Django a un sitio en producción (puesta en escena)? [cerrado]

Question

He conseguir bastante rápido con un pequeño proyecto Django mío, que estoy desarrollando a nivel local, por supuesto. Pero, ya que nunca había trabajado con Django antes, no soy consciente de lo que implica para subirlo y probarlo en un servidor de producción. Y estoy bastante curioso, ya que estoy muy ansioso por probar una liberación anticipada en vivo.

Sé que es este documento, que creo que será muy útil: http: / /djangobook.com/en/2.0/chapter12/

Sin embargo, hay algunos detalles que debería tener en cuenta antes, durante y después de la implementación? Cualquier consejo o mejores prácticas?

Gracias.

Answer 1

Haga su entorno de desarrollo / prueba coincide con el entorno de implementación lo más cerca posible. Esto significa utilizar por ejemplo PostgreSQL y mod_wsgi en lugar de SQLite y el servidor incorporado. Este software es libre así que no hay razón por la que no puede conseguir sus manos en él.

Answer 2

sur para eliminar dolores de migración de base de datos, y considerar algo así como o href="http://docs.fabfile.org/0.9.0/" rel="nofollow noreferrer"> tela para el despliegue si tiene un proyecto razonablemente complejo (o tienen el tiempo para aprender estas herramientas), ya que permitirán a los despliegues de secuencias de comandos fácilmente reproducibles.

Answer 3

Es posible tener problemas si sirven a su sitio en un subdirectorio de un dominio: evitar la escritura de direcciones URL absolutas con la mano, utilice el etiqueta del URL lugar.

Si se basa en los datos iniciales en la base de datos, utilice accesorios .

Si va a utilizar su servidor para múltiples sitios, considera el empaque de su sitio con virtualenv a evitar dependencias conflictos con los otros sitios.

También debe utilizar el mismo sistema de base de datos en sus servidores dev y de producción para evitar sorpresas.

Answer 4

Creo que muchos se cuelga en el cambio del modelo de base de datos. Django puede añadir nuevas columnas con syncdb, o generar una secuencia de comandos para hacer eso, pero no va a eliminar columnas y no creo que vaya a eliminar las restricciones de clave externa de la base de datos, incluso si ya no se aplican.

Así que la migración de base de datos puede hacer mejor guión, y se prueba en una copia de la base de datos de producción o algún conjunto de datos se parece mucho a los datos de producción (el mismo esquema, por supuesto).