Hay dos enfoques:
- disciplina
- Herramientas
En mi experiencia, # 1 sólo puede llegar tan lejos.
Así que la solución es probablemente herramientas. En tu caso, el obstáculo es la Subversión. Reemplácelo con un DVCS como Mercurial o Git. Eso permitirá que cada desarrollador trabaje en su propia rama sin las pesadillas de fusión de Subversion.
De vez en cuando, un desarrollador marcará una función o rama como "completa". Ese es el momento de fusionar la rama de características en la rama principal. Introdúzcalo en un depósito de "etapas" que su servidor de CI vigila. El servidor de CI puede extraer los últimos commit (s), compilarlos y probarlos y solo si esto pasa, empújelos al repositorio principal.
Así que el bucle es: repo principal -> desarrollador -> puesta en escena -> principal.
Hay muchas respuestas aquí que le dan los detalles. Haga clic aquí: Mercurial workflow for ~15 developers - Should we use named branches?
[EDIT] Así que decir que no tiene el tiempo para resolver los grandes problemas en su proceso de desarrollo ... Te dejaré adivinar la forma que suena a cualquiera ...; -)
De todos modos ... Usa hg convert para obtener un repo Mercurial de tu árbol Subversion. Si tiene una configuración estándar, no debería tomar mucho tiempo (solo necesitará mucho tiempo en su computadora, pero es automática).
clon que repositorios para conseguir un acuerdo de recompra de trabajo.El proceso funciona así:
- Desarrolla en tu segundo clon. Crea ramas de características para eso.
- Si necesita cambios de alguien, conviértelos en el primer clon. Pasa de eso a tu segundo clon (de esa manera, siempre tienes una copia "limpia" de subversión por si te equivocas).
- Ahora combine la rama Subversion (
default) y su rama de características. Eso debería funcionar mucho mejor que con Subversion.
- Cuando la fusión es correcta (todas las pruebas se ejecutan para usted), cree un parche desde un diff entre las dos ramas.
- Aplique el parche a una caja local de Subversion. Debería aplicarse sin problemas. Si no lo hace, puede limpiar su pago local y repetir. No hay posibilidad de perder trabajo aquí.
- Confirme los cambios en subversión, conviértelos de nuevo en el repositorio n. ° 1 y acceda al repositorio n. ° 2.
Esto suena como un montón de trabajo, pero dentro de una semana, se le ocurrirá un guión o dos para hacer la mayor parte del trabajo.
Cuando se da cuenta de que alguien rompió la compilación (las pruebas ya no se ejecutan), deshaga la combinación (hg clean -C) y continúe trabajando en la rama de la característica operativa.
Cuando sus colegas se quejan de que alguien rompió la construcción, dígales que no tiene ningún problema. Cuando la gente comienza a notar que tu productividad es mucho mejor a pesar de todos los obstáculos que tienes que saltar, menciona "sería mucho más simple si rasguñáramos el SVN".
Aceptando esta respuesta simplemente por el juego de integración continua. Envié esto a los otros gerentes y la gente estaba muy entusiasmada con esa idea. Hay una buena posibilidad de que cambiemos a Jenkins después de nuestro próximo lanzamiento. Mientras tanto, en su mayoría solo intentaremos cambiar la cultura. ¡Gracias a todos por sus comentarios! – Morinar
Vine aquí para obtener una ayuda antes del compromiso, pero me encantaron los párrafos sobre CIG, esa es una buena idea, la enviaré a mi administrador de CI ^^ – Ethenyl