Flujo de trabajo efectivo para permitir a los diseñadores acceder a una parte del repository SVN

Tenemos un equipo de desarrolladores y un equipo de diseñadores. Déjame ser muy claro. Los desarrolladores NO son artistas y los diseñadores NO son tan conocedores del código.

Los desarrolladores trabajan en una aplicación web en un repository SVN localmente en su máquina. Tenemos estaciones de trabajo con Windows 2003 que permiten que cada desarrollador aloje cada website en IIS para fines de debugging. Usamos TortoiseSVN y Visual Studio con VisualSVN.

La function del desarrollador es conseguir que una nueva característica funcione y funcione, y luego un diseñador necesita ingresar y hacer cambios a páginas, máscaras, CSS, etc. para hacerlo más bonito, pero los cambios que hacen necesitan ser comprometidos. al repository para que los desarrolladores puedan verlos y no sobrescribirlos.

Tener a cada diseñador con su propio server IIS para jugar no es sostenible desde una perspectiva de soporte. La mejor solución que podemos encontrar actualmente es tener un server de layout configurado con un pago compartido independiente de la parte del sitio SVN, y permitir que todos los diseñadores realicen cambios en este sitio a través de un recurso compartido de UNC y luego comprometer su cambios usando TortoiseSVN solo. Luego, los desarrolladores se actualizarán para recibir estos cambios y publicarlos en Prueba y, finalmente, en vivo.

Esto parece más viable: el problema más grande es que los diseñadores deben tener cuidado de no pisar uno al otro y comprometer solo sus cambios.

¿Hay otros problemas en los que no estoy pensando?

¿Alguien más ha presentado una mejor solución para este tipo de flujo de trabajo?

(Luché con las tags en este caso, cualquier ayuda para volver a labelr sería muy apreciada).

Lo desalentaría fuertemente de la opción de ramificación propuesta. Esto a veces es complicado para los desarrolladores, así que te dejo imaginar el desastre que terminarás si todos tus diseñadores comienzan a fusionar sus twigs una encima de la otra. Y si los desarrolladores están trabajando en el tronco, es posible que deba fusionar periódicamente TRUNK en las twigs de algunos diseñadores.

Una posibilidad podría ser tener un IIS para todos sus diseñadores, pero cada uno (por ejemplo, johndoe) estaría trabajando en su propia aplicación (digamos http: //johndoe.ueberserver.local/application ) que está desprotegida en una unidad de networking ( eg i: / johndoe / aplicación). De esa forma, John puede trabajar en algunos files y ver el resultado en el browser.

Cuando es hora de que John revise sus cambios, puede dejar que lo haga o designar un "cheque en amigo" que lo haga por él.

A less que haya omitido algo en su descripción, debería poder lograrlo usando twigs.

No ha entrado en detalles sobre cómo se ramifica actualmente para el desarrollo / lanzamiento de características, así que supongo, por mi ejemplo, que los desarrolladores una vez que han completado su function lo han fusionado nuevamente al enlace troncal.

Una vez que esto ha ocurrido, el tronco debe estar ramificado y los diseñadores deben confirmar sus cambios en esta twig.

Cuando hayan terminado, los desarrolladores pueden revisar todos los cambios y fusionar lo necesario para el lanzamiento del trunk.

Si quería asegurarse de que el diseñador no comprometiera nada accidentalmente, también podría restringir su acceso de escritura solo a la ruta de la sucursal en el repository.

¿Los diseñadores usan Visual Studio? Si es así, entonces puede usar el server web incorporado que viene con VS de esa manera no necesita IIS en absoluto. Así es como hago todo mi desarrollo.

Si utiliza las funciones de bifurcación de Subversion, cada diseñador puede crear su propia sucursal y trabajar dentro de ella hasta que se sienta cómodo fusionándose con el tronco o cualquier twig de la versión en la que el rest de los desarrolladores esté trabajando.

Mantener a todos tan aislados como sea posible tiende a mantener las cosas en movimiento más suave. Eso significa que no hay server web compartido. Esta es realmente la metodología para la que se construyó Subversion de todos modos.

Una estrategia que me gusta es usar un policía de líneas externas. Asigne a uno de sus desarrolladores el trabajo de administrar el enlace troncal. Tal vez podría permitir que solo esa persona escriba acceso al enlace y su trabajo es asegurarse de que todas las fusiones en el enlace se realicen correctamente. Obviamente, querrás que alguien con habilidades sea fuerte en desarrollo y conceptos de administración de código fuente (específicamente Subversion).

"El mayor problema es que los diseñadores deben tener cuidado de no pisar uno al otro y comprometerse solo con sus cambios"

  1. ¿Puede proporcionarles espacios de trabajo separados en el mismo área de server IIS? (¿con áreas de espacio de trabajo revisadas en una carpeta que lleva su nombre?) De esta forma solo comprometerán su trabajo desde sus propios espacios de trabajo. Por supuesto, esto supone que están trabajando en código no superpuesto y, por lo tanto, no sobrescribirán el trabajo de los demás cuando se comprometen. También necesitarán ser educados para hacer un svn udpate antes de comenzar su trabajo para que tengan los últimos cambios de otros en su espacio para evitar cualquier conflicto. (Siempre estoy nervioso cuando varias personas usan el mismo área de trabajo)

  2. Puede hacer que hagan sus cambios pero no necesariamente hacer que ejecuten un commit. Una sola persona designada puede ejecutar svn commit una vez al día o más a menudo, para evitar errores desafortunados. No me gusta demasiado esta opción, ya que creo que es bastante fácil para las personas usar múltiples espacios de trabajo y seguir hábitos sencillos de order, como comprometerse con posts relevantes, etc. (para ayudar a rastrear / revertir): una session breve puede cubrir fácilmente las lagunas conocimiento me parece.

No veo cómo podrá get un esquema mejor que el que mencionó si no relaja la restricción "como máximo un server IIS". ¿No es posible usar máquinas virtuales para que cada diseñador pueda get su propio server? Todas esas máquinas podrían compartir el mismo file de configuration. Entonces los diseñadores no tendrían que preocuparse por los cambios de los demás …