Haciendo cambios en un sitio en vivo (Codeigniter, pero no es específico para él)

Question

Estoy usando Codeigniter si esto lo hace más fácil. Me pregunto si un sitio web es en vivo con una base de datos poblada y usuarios accediendo, y tengo una nueva idea para implementar en el sitio web, ¿cómo debo hacerlo? ¿Trabajas directamente en el sitio en vivo?

O copia la base de datos y los archivos a un servidor local (MAMP/WAMP/XAMMP) y trabaja allí, si funciona, actualice el sitio en vivo con los cambios. Para este segundo método, ¿hay alguna forma de verificar cuáles son los archivos que se han cambiado y solo subirlos? ¿Qué pasa si funciona en el servidor local, pero después de actualizar el sitio en vivo no funciona?

La configuración de Codeigniter también tiene la opción de base de datos predeterminada y otra base de datos. Me pregunto cómo se pueden usar para las pruebas.

Answer 1

No trabaje directamente en el sitio en vivo. En su lugar, tenga un entorno de desarrollo (utilizando, por ejemplo, vmware o virtualbox en su máquina) y clone el entorno en vivo. Obtenga su código en control de versiones (lo diré de nuevo: OBTENGA SU CÓDIGO EN CONTROL DE VERSIÓN), desarrolle en la máquina de desarrollo, contra una rama de desarrollo en control de versiones. Una vez que haya finalizado la prueba y esté satisfecho con los cambios, envíelos a una rama de 'implementaciones' o 'en vivo', e impleméntelos en el sitio en vivo desde allí. Asegúrese de hacer una copia de seguridad de la base de datos antes de desplegar el nuevo código.

Editar: use enlaces simbólicos para organizar su nueva base de códigos en el sitio en vivo. Si no funciona, simplemente vuelva a colocarlo en el directorio anterior. Le ahorra mucha greif!

Answer 2

1. Lea más sobre el control de versiones (svn, git, et al.).
2. Nunca trabaje en un sitio en vivo, preferiblemente en otro servidor (para evitar while(1){..} cuelgues, etc.), pero en el mismo servidor al menos en otro documentroot/dominio, preferiblemente con acceso limitado a su IP solamente.
3. Normalmente solo copio las definiciones de tabla (mysqldump -t es bueno para eso) y tengo otra base de datos, si necesita la última información &, puede replicar su base de datos principal a una base de datos de prueba, que también le proporciona el ventaja de una copia de seguridad barata si aún no tienes una.
4. Normalmente establezco un interruptor en la configuración de Apache/Vhost (SetEnv DEV=1), de modo que en el código I puedo usar if(getenv('DEV')==1) para verificar si puedo simplemente volcar variables en condiciones de error, y que limitan la posibilidad de asignar/cargar código accidentalmente con un 'interruptor de desarrollo' todavía encendido por accidente.

Answer 3

La respuesta típica a esta pregunta va a ser hacer su trabajo en el entorno de prueba, no el entorno de producción. Y estoy de acuerdo en que esa es a menudo la mejor forma de manejar los cambios. Si tiene el lujo de un entorno de prueba, aproveche al máximo. Después de todo, eso es lo que está ahí para probar.

Sin embargo, eso no significa que trabajar en el entorno de producción esté completamente fuera de los límites. Su decisión debe basarse en algunos factores:

• ¿El funcionamiento de su sitio web es crítico para las necesidades de su negocio?

Si es así, haga todo su trabajo en un entorno de prueba y despliéguelo en su entorno en vivo cuando haya probado completamente sus cambios.

• ¿Los cambios que va a realizar van a tener un gran impacto en el resto del sitio web?

Por ejemplo, ¿está a punto de cambiar el esquema de la base de datos? ¿Estás a punto de cambiar la forma en que los usuarios inician o cierran sesión en tu sitio web? Si es así, haz tu trabajo en el entorno de prueba. Si está cambiando el comportamiento de una página que no tiene ningún efecto en otra parte, puede salirse con la suya haciendo el cambio en el entorno de producción.

• ¿Cuánto demorarán los cambios en implementarse?

Si no puede garantizar que los cambios no demoren más de 15-20 minutos, realice su trabajo en un entorno de prueba.