Nuestro entorno de producción incluye lo siguiente:
- 3 interfaces que sirven a nuestro sitio web
- 2 backends de bases de datos (Master-Slave, replicación)
- 1 mixto que ejecuta httpd y la base de datos para la publicación de datos
Nuestro entorno de desarrollo es un servidor único que ejecuta bases de datos y httpd, en cuanto a la configuración, tenemos diferentes espacios de trabajo para todos los usuarios y nuestro VC es subversión. La estadificación es bastante simple también: se ejecuta en una de las interfaces.
base de datos cambia
Inicialmente pasamos mucho tiempo en el diseño de bases de datos y parece que realmente han dado sus frutos. No hemos cambiado nada importante en cinco meses. La mayoría de los cambios que implementamos están en la interfaz. Ahora, hasta ahora, ejecutamos todos los cambios en la base de datos de forma manual y siempre escribí un pequeño script para revertir.
Si tuviera más de esos, usaría Doctrine y Migrations aquí. Nunca he tenido la oportunidad de usarlos en producción, pero ya los jugué mucho y parecen ser muy poderosos.
despliegue
Así que cuando hacemos uso de una nueva versión creamos una etiqueta del código que nos la salida en la puesta en escena, a continuación, pasar por un par de listas de cheques, etc., y luego desplegar el código en el Fronteras de producción. Para hacer todo el despliegue, tengo un par de configuraciones de tareas en Capistrano.
Salida esta muestra capfile:
role :www, "web01", "web02", "web03"
role :web, "web01", "web02", "web03", "web04"
role :db, "db01", "db02"
desc "Deploy sites"
task :deploy, :roles => :www do
run "cd /usr/www/website && sudo svn --username=deploy --password=foo update"
end
Capistrano también le permite ejecutar cualquier otro comando sin definir una tarea:
cap invoke COMMAND="uptime" ROLES=web
(Requiere la papel "web" para ser configurado . Vea el ejemplo anterior.)
Estilo y documentación de codificación
Nos adherimos bastante al PEAR Coding standard, que comprobamos usando PHP_CodeSniffer (phpcs). Cuando digo más o menos, me refiero a que bifurqué los olfateos provistos y agregué algunas excepciones de mi propio gusto.
Además del estilo de codificación, phpcs también verifica la documentación en línea. Esta documentación es creada por phpDocumentor al final.
CI
tengo tanto de esas herramientas de configuración en nuestro CI-servidor (continua integración), que es phpUnderControl usando lo anterior y climatizador, phpUnit, Xdebug (un código pareja métricas .. .), etc.
pruebas de la unidad es algo que actualmente nos falta. Pero lo que hacemos ahora es que con cada error que encontramos en nuestro motor de análisis sintáctico (analizamos el texto en ciertos formatos), escribimos una prueba para asegurarnos de que no vuelva a aparecer. También escribí algunas pruebas básicas para verificar el enrutamiento de URL y la API XMLRPC interna, pero esto está realmente sujeto a mejoras. Empleamos tanto las pruebas de estilo phpUnit como phpt también.
El servidor de CI construye una nueva versión un par de veces al día, genera gráficos, documentos y todo tipo de informes.
Además de todas las herramientas mencionadas, también utilizamos Google Apps (principalmente para correo electrónico) y guardamos una wiki de Google Sites con toda la demás documentación. Por ejemplo, procedimiento de implementación, listas de prueba de QA, etc.
Tu pregunta es errónea. CI describe más una cuestión de control de calidad. P.ej. pruebas unitarias, comprobación de la cobertura de códigos, documentación de construcción, comprobación de estilo de codificación, PMS, etc. ¿Realmente está buscando asesoramiento sobre la implementación? – Till
He eliminado la integración continua, porque eso no es lo que está pidiendo. – Till