Configuración de un proceso de desarrollo eficiente y efectivo

Question

Estoy en el medio de configurar el entorno de desarrollo (PHP/MySQL) para mi puesta en marcha. Utilizamos tres conjuntos de servidores:

REALES - los servidores que proporcionan la aplicación real PRUEBA - proporcionar una versión de prueba antes de que sea lanzado en realidad DEV - los servidores de desarrollo

Los servidores de desarrollo se ejecutan SVN con cada desarrollador revisando su copia local. Al final de cada día, las reparaciones completadas se registran y luego usamos Hudson para automatizar nuestro proceso de compilación y luego transferirlo a TEST. Luego verificamos que la aplicación aún funcione correctamente con un probador y luego, si todo está bien, muévala a EN VIVO. Estoy contento con este proceso pero tengo dos preguntas:

• ¿Cómo recomendaría que hacemos pruebas locales - ya que cada desarrollador agrega nuevas páginas o cambios de funcionalidad que quiero que sean capaces de probar lo que están haciendo . ¿Configuraría localmente Apache y una base de datos local y los probaría localmente en su propia máquina?

• ¿Cómo recomendaría lidiar con los cambios en la capa de datos?

• ¿Hay algo más que recomiende hacer para realmente hacer que nuestro proceso de desarrollo sea lo más fácil y eficiente posible?

Gracias de antemano

Answer 1

1 a cada desarrollador dirigir su propia configuración, completo con Apache y la base de datos.

Mantenga el esquema de la base de datos bajo control de versión.

Posiblemente pueda mantener (tal vez en un repositorio separado) un pequeño pero representativo conjunto de datos, en una base de datos de prueba. Cada mañana revisa la última copia de esta base de datos de prueba y comienza a piratear. Cuando cambie los esquemas, actualice su repositorio de datos de prueba en consecuencia.

Answer 2

Cualquier persona que esté desarrollando DEBERÍA tener su propio entorno local. Uso Mac así que ejecuto MAMP para poder tener mi propio entorno LAMP local e independiente de cualquier otro entorno. Esto también me permitirá saber que nadie más está cambiando/trabajando en los mismos componentes que yo y elimina cualquier posible confusión. Si usted es un usuario de Windows, también hay versiones locales fáciles de instalar de la pila LAMP, como XAMP, etc. Si está ejecutando Linux como su escritorio, probablemente ya sepa cómo instalar LAMP para el sabor de Linux. estan corriendo.

La versión de esquema de la base de datos es una gran idea. Es lo que usamos también. Además del esquema bajo control de versión, agregamos una tabla de versión de esquema al esquema y la mantenemos actualizada para que podamos saber rápidamente qué versión hay en producción/qa/dev cuando necesitamos compararla.

En cuanto a los cambios en la capa de datos, hay dos cosas que recomendaría.

1. Cree siempre su ruta de migración, hacia adelante y hacia atrás. Esto significa que cuando tiene el esquema que desea poner en producción para actualizar un esquema existente, siempre debe hacerlo parte de la versión. Un proceso claro y conciso para ALTERAR las tablas. Por la misma razón, debe tener una versión ROLLBACK en funcionamiento y probada también en caso de que algo salga mal.

2. Lo que he encontrado útil es utilizar una copia de seguridad de producción para cargar en mi local (o QA/DEV) para tener los datos/esquemas más actualizados para jugar sin afectar la producción. Si no realiza copias de seguridad periódicas de la producción, tal vez este sea un buen momento para implementar una política. Entonces matarás dos pájaros de un tiro. Tendrás copias de seguridad para cualquier interrupción y un esquema en vivo útil con datos que puedes cargar para probarlos en otra máquina. Esto también se prestará a plantear posibles problemas con los cambios de esquema ya que los datos coincidirán con la producción. Entonces, si funciona localmente (y en DEV/QA), reduce el riesgo de que algo salga mal en la producción.