Las mejores prácticas con el código fuente ramificado y el ciclo de vida de la aplicación

10

Somos una pequeña tienda de ISV y generalmente enviamos una nueva versión de nuestros productos cada mes. Usamos Subversion como nuestro repositorio de código y Visual Studio 2010 como nuestro IDE. Soy consciente de que muchas personas abogan por Mercurial y otros sistemas de control de fuentes distribuidas, pero en este momento no veo cómo podríamos beneficiarnos de ellos, pero podría estar equivocado.

Nuestro principal problema es cómo mantener sincronizadas las ramas y el tronco principal.

Así es como hacemos las cosas hoy:

  1. Lanzar nueva versión (crear automáticamente una etiqueta en Subversion)
  2. Continúe trabajando en la troncal principal que se lanzará el próximo mes

Y el ciclo se repite todos los meses y funciona perfectamente. El problema surge cuando un lanzamiento urgente del servicio necesita ser lanzado. No podemos liberarlo de la troncal principal (2) ya que está bajo un desarrollo intenso y no es lo suficientemente estable como para ser liberado con urgencia.

En tal caso hacemos lo siguiente:

  1. Cree una rama a partir de la etiqueta que creamos en el paso (1)
  2. Arreglo del fallo
  3. Prueba y lanzamiento
  4. Empuje el cambio de regreso al tronco principal (si corresponde)

Nuestro mayor problema es fusionar estos dos (rama con main). En la mayoría de los casos, no podemos confiar en la fusión automática porque, por ejemplo:

  • Se han realizado muchos cambios en el tronco principal
  • fusionar archivos complejos (como archivos XML de Visual Studio, etc.) no funciona muy bien
  • otro desarrollador / equipo realizó cambios que no comprende y no puede simplemente fusionarlos

Entonces, ¿qué crees que es la mejor práctica para mantener estas dos versiones diferentes (rama y principal) en sincronía. ¿Qué haces?

Toni Frankola
fuente
1
Asegúrese de consultar tfsbranchingguideiii.codeplex.com (no se publica como respuesta, ya que no responde directamente a su pregunta, pero siempre la recomiendo a las personas que buscan mejorar su rama-fu de TFS). Quizás uno de sus planes de sucursal le dará una idea sobre cómo mejorar su configuración.
nlawalker

Respuestas:

2

Creo que su enfoque para bifurcar y fusionar está bien, pero si el problema principal es que la base del código es bastante inestable, eso es en lo que debe concentrarse y minimizar.

Lo principal para garantizar es que la base del código tiene una buena separación de preocupaciones . Las dependencias entre varios componentes deben aislarse y reducirse. Esto debería resolver la mayoría de tus problemas. También será útil seguir prácticas como el principio de responsabilidad única.

Si es necesario que ocurra un cambio arquitectónico importante, debe tener lugar en su propia rama, y ​​luego fusionarse nuevamente en main una vez que esté completamente probado y sea 'estable' (dentro de lo razonable). Esto puede ser doloroso y desafiante, pero también debería ser raro. Si tiene buenas prácticas de prueba, el riesgo se minimiza.

También puede ayudar cambiar a un sistema de control de versiones distribuido. Esto debería darle un tronco estable, con diferentes características fusionadas de diferentes ramas cuando estén listas. Aún tendrá problemas para fusionarse si el código es demasiado interdependiente, pero tendrá más control.

Mirando esto desde otra perspectiva, también considere una mayor comunicación entre su equipo. Ejecute reuniones periódicas de estilo ágil. Considere dónde se sientan los miembros del equipo y cómo eso puede ayudar. Si es necesario realizar una fusión compleja, puede que no sea tan malo: utilice un enfoque de programación en pareja que les permita comprender a ambas partes.

Alex Angas
fuente
2

Tiendo a mirarlo de manera bastante opuesta:

  • Trunk siempre debe ser un código listo para producción (después de su primer lanzamiento inicial, es decir).
  • Debe haber una rama de tipo de desarrollo que se ejecute en paralelo al tronco, donde ocurre su desarrollo mensual. Todos los meses, cuando se trata del tiempo de lanzamiento, se fusiona en el tronco, se prueba y luego se libera.
  • Las revisiones se pueden hacer fácilmente en su troncal y registrarse, y siempre se pueden implementar con éxito. Luego haga un parche a partir del hotfix y aplíquelo a su rama de desarrollo.

Por supuesto, este flujo de trabajo se adapta mucho mejor a algo que no es SVN, porque una buena ramificación y fusión es algo bastante doloroso en SVN, independientemente de su flujo de trabajo. En mi experiencia, la fusión en SVN casi siempre debe hacerse manualmente, porque simplemente no funciona y no hay forma de evitarlo.

sevenseacat
fuente
1

Últimamente, he estado abogando por una filosofía de "ramificar y fusionar" como último resultado. Creo que es una verdad desafortunada que lidiar con las fusiones de código de las ramas no es un problema técnico, pero es una tarea cognitivamente difícil: creo que es simplemente que el cerebro humano no rastrea suficientes detalles para facilitarlo. Además, todavía tengo que ver que la ramificación y la fusión realmente funcionan en la práctica. Una vez que el código se ramifica, la experiencia me dice que no es más que un problema fusionarlo nuevamente.

smithco
fuente
2
¿Qué VCS has probado? La facilidad de una fusión depende en gran medida del VCS que se utilice.
alternativa
Muchos VCS más nuevos realmente manejan la fusión realmente bien. A veces los conflictos seguirán ocurriendo, pero tienden a ser conflictos reales, no los falsos que SVN informó mucho tiempo.
sevenseacat
He probado varios sistemas SCM. La mayoría de las herramientas de combinación pueden juntar dos fragmentos de texto con diferentes cantidades de éxito. Sin embargo, ninguna herramienta de fusión puede decir si obtuvo el resultado correcto. He visto pasar demasiados errores porque algún programador decidió confiar en una herramienta de fusión.
smithco
1
No se supone que las herramientas de combinación junten dos piezas de texto. Se supone que deben fusionar los cambios del commit padre; gran diferencia.
alternativa
Las herramientas de fusión no entienden el código. Todo lo que pueden hacer es tomar dos textos diferentes e intentar conciliarlos inteligentemente. Sin embargo, no puedo enfatizar lo suficiente cuántas veces he visto que las fusiones incorrectas se deslizan y causan fallas de compilación y errores. Cada fusión debe considerarse arriesgada y los resultados deben ser revisados ​​por un humano y pasar la batería de pruebas antes de cometer los cambios combinados. Es un proceso complicado y debe hacerse con poca frecuencia.
smithco
1

Un enfoque disciplinado de lanzamiento en principal funciona bien.

La ramificación SVN no está diseñada para ser flexible. Sugeriría su primer problema radica en SVN; pasar de eso abrirá nuevas opciones.

Paul Nathan
fuente