¿Alguien tiene un flujo de trabajo de desarrollo/estadificación/implementación con php/mysql?

Question

Estoy pensando en un buen flujo de trabajo para el desarrollo web de php/mysql.

¿Alguien tiene algunos consejos?

Answer 1

Esto es lo que hacemos:

1. Cada uno trabaja en sus proyectos en su rama (código, pruebas, etc.)
2. Cuando todo se ve bien, que se combina en tronco
3. phpUnderControl reconstruye Tronco , se ejecuta todos nuestros phpUnit pruebas, construye la documentación, db actualizada, etc
4. Si todo lo que pasa, que se funden en Estable Estable
5. consigue totalmente reconstruida como la trompa
6. estable se promovió de forma manual a nuestro servidor de producción

Tenemos algunos scripts personalizados que se ocupan de nuestras actualizaciones de bases de datos y nuestro empuje a la producción. Para nuestra base de datos, mantenemos todos los deltas en una única carpeta y el script comprueba el nivel actual de la BD con los deltas disponibles y, si es necesario, los aplica.

Para la promoción de producción, tenemos otra secuencia de comandos que extrae todos los datos de producción y luego ejecuta rsync para impulsar los cambios.

No menciona qué nivel de control tiene sobre los servidores, pero el proceso general sería el mismo para el desarrollo general.

Answer 2

Creo que todo el mundo hace estas cosas ligeramente diferente, dependiendo de la aplicación exacta. Aquí está nuestra configuración:

Antes de un comunicado:

• Todo el mundo se compromete a /trunk.
• Cuando queremos rodar un lanzamiento, copiamos el tronco al /tags/yymmddhhiiss.
• Estabilizamos la etiqueta.

Una vez que se estabilizó, se corre el script deploy:

• En el servidor de producción, obtener de la nueva etiqueta.
• Haga un volcado de la base de datos.
• Detener daemons y cerrar la (s) aplicación (es) web.
• Cambie el enlace simbólico /current para que apunte a la etiqueta recién desprotegida.
• Ejecutar scripts de migración.
• Reinicia demonios y aplicaciones.

Si tenemos que empujar un pequeño cambio rápidamente, nos acoplamos a la etiqueta actual, y que a continuación, puede ejecutar un proceso de revisión mucho más simple en el servidor:

• demonios de parada y apagar la (s) aplicación (es) web.
• Ejecutar svn update
• Reiniciar daemons y aplicaciones.

Tenga en cuenta que hay ciertas herramientas que están destinadas a la estructuración/automatización de estos procesos. Phing es uno, y Symfony tiene su propio batch system, que solía ser un proyecto independiente llamado pake. Y como si eso no fuera suficiente, Zend Framework está a punto de crear their own variant. Todo es realmente un desastre, pero Phing es probablemente el más utilizado. También puede usar algo que no sea específico de php, como Ant o Capistrano. Solo usamos scripts de shell, que básicamente satisfacen la misma necesidad.

También tenemos un desarrollo de compilación continuo, que se ejecuta desde el tronco y ejecuta todas las pruebas. Actualmente solo tenemos una colección básica de scripts de shell que lo hacen, pero estamos considerando cambiar a PhpUnderControl o xinc.

El migraciones paso tal vez merece una explicación. Estos contienen cambios en la base de datos, así como otras tareas que deben ejecutarse para la nueva versión. Nuestras migraciones son un poco simples en este momento; Simplemente tenemos una carpeta con un conjunto de scripts .php y .sql y durante la migración, estos se ejecutan en secuencia. La forma en que hacemos un seguimiento de los cambios que se han ejecutado es vaciando la carpeta migrations justo después de que se haya hecho una nueva etiqueta. Probablemente sería más inteligente usar la base de datos para registrar qué cambios se han realizado. Se considera adoptar algo como ruckusing para este propósito.