Flujo de trabajo de desarrollo web SVN

Question

He leído muchas de las preguntas aquí relacionadas con este tema, pero realmente no puedo encontrar ningún buen consejo que se adapte a nuestra situación. Heredé este flujo de trabajo, y estoy tratando de hacerlo mejor.

Nuestra configuración

• base de código PHP (Kohana en particular)
• potencias de base código de ~ 60 sitios, cada uno con plantillas únicas (es decir, 60 QA [garantía de calidad] dominios también)
• cada sitio tiene registros A para diferentes activos y recursos (es decir, 8 registros A para cada dominio)
• 3 desarrolladores
• 3 diseñadores
• los desarrolladores tienen la imagen de VMware del servidor de producción para el desarrollo local
• diseñadores no
• servidor de desarrollo físico compartido utiliza para control de calidad, actualizar un post-commit mantiene este servidor a la cabeza actual del tronco en todo momento
• producción servidor, actualizado a una mezcla y combinación de diferentes revisiones, dependiendo de qué características son en vivo

fluya Nuestro trabajo

• Los desarrolladores trabajan de forma local hasta que se complete una determinada función y luego comprometen toda la función con el tronco para el control de calidad interno.
• Los diseñadores solo realizan pequeños cambios en CSS/images/templates. Se comprometen directamente con el tronco, controlan sus propios cambios y actualizan los archivos correspondientes en el servidor de producción, en términos generales, inmediatamente después de su control de calidad.
• Cuando las funciones están listas para su activación, el servidor de producción se actualiza manualmente con los números de revisión adecuados para cada archivo relacionado con la función. A veces esto es simple, otras veces es bastante peludo (muchas llamadas a svn log para buscar dependencias ascendentes).

Nuestros problemas

• Con tres diferentes desarrolladores que trabajan en diferentes funciones que necesitan diferentes cantidades de control de calidad, nos encontramos corriendo en problemas de dependencia aguas arriba sobre una base regular.
• En un momento dado, no tenemos una forma de determinar programáticamente qué características están en el servidor de producción y cuáles no. svn status -u nos mostrará qué archivos no están actualizados, pero generalmente no es una imagen clara de las características.

Lo que sé

• Algunos de nuestros problemas podrían ser aliviados por tener una rama de producción. Al menos podríamos monitorear qué características se estaban agregando a la producción y cuándo, aunque esto no resolvería los problemas de dependencia de la cadena ascendente.
• Las ramas de funciones son una opción, y lo hemos intentado en el pasado.Debido a que nuestro software requiere 60 dominios de control de calidad por sucursal, aquí encontramos problemas de administración de procesos. Por ejemplo, la creación de 480 (60 dominios x 8 registros por dominio) registros A para cada rama de entidad.
• Las ramas de desarrollador también son una opción, pero los tiempos de control de calidad de nuestra característica varían. Definitivamente no puedo decir que una característica previa estará fuera del control de calidad antes de que tenga que cometer algo más.

Upstream Dependencia Ejemplo

• desarrollador A agrega una nueva función de presentación tanto en la administración y de extremo frontal.
• El desarrollador B agrega una nueva función de comentarios tanto en el administrador como en el front-end.
• Ambas características se entrelazan con la lógica de modelo/controlador de ubicación, por lo que se realizan cambios en esos archivos asociados para dar cuenta de ambas características nuevas.
• La función de pase de diapositivas ingresa a QA, pero se mantiene por alguna supervisión del desarrollo o desplazamiento del alcance.
• La función de comentarios ingresa al QA y se aprueba sin problemas.
• Queremos seguir la línea de tiempo y enviar la función de comentarios a la producción, pero no podemos hacerlo directamente porque ambas características requieren cambios en el modelo/controlador de ubicación. Es decir, no podemos simplemente hacer un svn update file1 file2 file3.
• Nota:Este es un ejemplo simple, y se puede solucionar haciendo una fusión inversa. A menudo, nuestros problemas son complejos.

multi-sitio de información de la estructura

• Tenemos una serie de temas estructurales predefinidos, que consta de puntos de vista, imágenes, archivos CSS, JS, etc
• Cada sitio se le asigna un tema
• Por motivos de marca y capacidad de expansión, cada sitio puede anular una vista de tema con una vista personalizada o incluir archivos CSS/JS específicos del sitio adicionales.

Estoy seguro de que hay otras personas que han tenido problemas similares, y espero obtener alguna información de ustedes, personas inteligentes, en Internet. ¡Por favor, siéntase libre de hacer preguntas si algo que dije parece claro como barro!

Answer 1

Su flujo de trabajo se puede mejorar, aquí hay una lista de mis consejos:

• Comenzar a utilizar ramas de SVN y las versiones de lanzamiento/despliegues en un ciclo regular.
• Averigüe cuánto tiempo debe durar su ciclo de implementación, dejando tiempo para QA. Entonces, por ejemplo, si va a lanzar una construcción cada mes, tendrá 3 semanas de desarrollo y 1 semana de control de calidad. Congele el desarrollo para esa compilación después de 3 semanas a excepción de las correcciones de errores.
• decidir sobre un esquema de numeración para su generaciones que permite espacio para crecer
• utilizan un sistema de tickets (ActiveCollab, JIRA, Mantis, etc ...) y hacer cumplir la regla de que cualquier compromiso tiene que estar asociado con un billete. Elija uno donde pueda hacer que sus confirmaciones aparezcan automáticamente en el ticket.
• Si va a comenzar a documentar sus requisitos antes de comenzar el desarrollo, no reúna sus requisitos en el sistema de tickets (por los dioses)
• Esto le ayudará a determinar qué características se encuentran en una compilación determinada. Así que haga algún tipo de notas de la versión con una lista de los números de los boletos o una descripción general de los boletos para cada compilación.
• Incruste sus números de compilación en su aplicación para que pueda rastrear implementaciones en cualquier sistema dado.
• Comience a trabajar con herramientas de prueba automatizadas PHPUnit para pruebas unitarias y Selenium para pruebas funcionales para acelerar el control de calidad y aumentar la calidad/estabilidad de la aplicación web al disminuir la probabilidad de que los cambios diarios introduzcan nuevos errores.
• Hudson y Phing pueden salvarle la vida para automatizar sus compilaciones y automatizar sus Pruebas.

Answer 2

bien, un par de reflexiones:

Para este tipo de flujo de trabajo, que haría mucho mejor con un SCM con un modelo de flujo, como Accurev o ClearCase. En un modelo de flujo, el trabajo fluye desde las transmisiones de cada desarrollador a las secuencias de integración, luego a las transmisiones de QA, y luego a las emisiones (o lo que mejor funcione). Solo el trabajo listo para avanzar a la siguiente etapa se mueve hacia arriba, y la integración se puede hacer solo con esos paquetes de trabajo.

Como dijo deceze, tiene que romper las cosas de forma más modular, pero también necesita combinarlo con un sistema de localización donde la funcionalidad específica del cliente puede anular partes específicas del código. Una forma en que he hecho eso en PHP es implementando un contenedor de importación de archivos PHP que primero busca una versión específica del cliente de un archivo PHP, y si no existe, cargue el archivo genérico en su lugar.

function importModule($module, $clientId){ 
    if(is_file("${clientRootDir}/${clientId}/${module}.php")) { 
     import("${clientRootDir}/${clientId}/${module}.php"); 
    } else { 
     import("${defaultRootDir}/${module}.php"); 
    } 
} 

Usando esta técnica, se puede sobrescribir con gracia partes de la forma en que el sitio web funciona sólo para ese cliente, y la persona que trabaja en esa funcionalidad para ese cliente está trabajando en un archivo completamente diferente para que no choquen Hola. No estoy seguro de si ya está haciendo esto y eso es lo que llama su "Modelo de ubicación"

Por último, con estos muchos "sitios web virtuales" para probar, se beneficiaría inmensamente al agregar pruebas unitarias automatizadas (a la PHPUnit) combinado con la integración continua para iniciar automáticamente las pruebas cuando el software avanza hacia la etapa de integración.