¿Qué estrategia de ramificación debería usar durante el desarrollo / mantenimiento de una aplicación web?

Estoy tratando de decidir sobre la mejor estrategia de ramificación para un proyecto de aplicación web. Esto es lo que se me ocurrió hasta ahora y agradecería cualquier comentario o experiencia.

La forma en que lo veo allí son dos estrategias principales de ramificación: "ramificación por lanzamiento" y "ramificación por function".

"Branch by release" : el desarrollo tiene lugar en el tronco. Cuando se acerca el momento de una publicación, se crea una twig para esa versión. Esta twig se estabiliza / testing y finalmente se realiza una liberación. Después del lanzamiento, la twig se fusiona de nuevo en el tronco, mientras mantiene viva la twig de liberación para corregir errores. Se aplica una corrección de error, luego se fusiona en el tronco (si el desarrollo en el tronco no ha eclipsado el error por otros medios). Las nuevas funciones se agregan al tronco y no afectan a la twig de lanzamiento. Cuando se acerca el momento de una nueva versión, se crea una nueva twig de publicación,

"Branch by feature" : el tronco siempre es el tronco de "producción" (el código que está activo). Las correcciones de errores se envían directamente al tronco. Las características para la próxima versión se desarrollan en las twigs de características. Las correcciones de errores se combinan de vez en cuando en las twigs de características. Cuando llega el momento del lanzamiento, las twigs de características se fusionan en el tronco y el ciclo de la vida continúa.

Ahora bien, la gran diferencia práctica entre estas dos estrategias es que "por lanzamiento" le permite mantener diferentes versiones de producción de su software (cuando el cliente A tiene la versión 1 y el cliente B versión 1.5, el cliente es el cliente que paga en este caso). Por el contrario, al utilizar la estrategia "por function", solo puede admitir la versión de producción actual (todos los clientes utilizan la última versión).

Dado que en una aplicación web típica todos los clientes están utilizando la misma "última" versión (ya que todos acceden al mismo server), supongo que el enfoque "por características" es el más utilizado. Elimina la necesidad de fusionarse "a través de la jerarquía", por ejemplo, cuando una corrección de error debe aplicarse a las 3 versiones de lanzamiento.

Entonces mi estado actual es que debería ir con "twig por function". Si es importante, mi equipo no es muy hábil.

Si solo tiene una versión en vivo en cualquier momento, y realiza todo el desarrollo en una única twig de características, estos enfoques son efectivamente los mismos.

Si twig por característica para usted significa tener varias twigs sobre la marcha a la vez, lo evitaría como la peste. Más twigs significa más fusión, que es un dolor en sí mismo, y más infierno de integración. Es mucho mejor hacer una continuous integration a una única línea de código.

Si su process de implementación está más involucrado que la sucursal, la testing, la puesta en marcha, una ventaja de la sucursal es que puede tener varias sucursales de publicación al mismo time, en diferentes fases: una en vivo y corregida cuando sea necesario, y otro está siendo estabilizado, probado, pasando por la aceptación, etc., mientras el desarrollo continúa en el tronco. Si tiene un enlace troncal activo, por otro lado, una vez que fusiona una twig de características con el fin de publicarlo, ha perdido la capacidad de realizar correcciones de errores en el sistema activo actual. La fusión de la twig de características se convierte en un punto sin retorno.

¿Qué tipo de software estás desarrollando? ¿Envoltura retráctil? ¿Proyecto de código abierto? De ser así, elija el enfoque "ramificación por liberación" o "tronco inestable". Especialmente si sus ciclos de lanzamiento son cada seis meses a un año de diferencia.

Pero si mantiene un proyecto basado en la web que tiene cambios que salen en frecuencias más cortas, como una vez cada pocas semanas o less, vaya con el enfoque "twig por function" o "tronco estable". El problema con este enfoque es la integración de múltiples cambios de funciones que tienen cambios radicales que hacen que el process de fusión sea less que divertido. Realmente se pone difícil.

Pero ambos funcionan bien, pero ¿y si necesitas ambos? Es decir, tiene un proyecto que se implementa cada 20 días con grandes cambios de funciones, pero descubre que tiene una serie de correcciones de errores que no puede esperar para que los cambios de características estén listos. Trunk es su twig de lanzamiento con el enfoque "twig por function". ¿Qué pasa si puede get ambos lanzamientos y presenta su propia twig?

Echa un vistazo a esta input de blog de Bob Archer de CollabNet. Su estrategia de lanzamiento ágil te ofrece lo mejor de ambos. Yo he usado esto Es extremadamente flexible. Aunque Bob no lo muestra en su diagtwig, puede tener varias twigs de lanzamiento al mismo time. Esto significa que podría tener una twig de publicación que esté list para su lanzamiento a producción, y otra que esté siendo preparada para las verificaciones finales de control de calidad. Pero dos cosas a considerar:

En primer lugar, ¿qué tan buenos son sus desarrolladores en la fusión? No puedes hacer el enfoque de la estrategia de lanzamiento ágil por ti mismo, incluso si se trata de un equipo pequeño. Todos tienen que hacer su parte y realmente deben entender la fusión y las herramientas que están usando para fusionar.

En segundo lugar, vas a necesitar una buena comprensión de los cambios que están listos y de los que están por llegar. La gestión de versiones es key para hacer que esto funcione como el reloj. Cada function cuando esté list deberá asignarse a una twig de publicación y fusionarse.

Cualquier enfoque que elijas, se networkinguce a lo que estás desarrollando y la frecuencia de los cambios que estás liberando para ese desarrollo.

A riesgo de confundirlo aún más: puede tener twigs de publicación y realizar todos los cambios en las twigs de características. Estas cosas no son mutuamente excluyentes.

Dicho esto, parece que no necesita familias de versiones paralelas y desea implementarlo a menudo, incluso de forma continua . Entonces querrás tener un "maletero estable" que puedas liberar en cualquier momento. Las twigs de características ayudan a mantener el tronco estable, ya que solo se fusiona con el tronco cuando se realizan los cambios y se ha comprobado su eficacia.

Entonces diría que su elección es una buena opción.

Estas opciones no son mutuamente excluyentes: use ambas. Ellos resuelven diferentes problemas:

"Sucursal por publicación" : la twig de publicación se utiliza para garantizar que puede volver a la fuente utilizada para producir la versión actual en vivo (o versiones anteriores) mientras la siguiente versión está en desarrollo. Por ejemplo, esto es para realizar cambios en la versión de lanzamiento para correcciones de errores o funciones de respaldo del tronco de desarrollo actual.

"Branch by feature" : se usa para mantener un tronco de desarrollo estable en todo momento, lo que es particularmente útil para múltiples desarrolladores y para características experimentales de "tal vez".

Yo usaría ambos, pero puede renunciar a uno de los enfoques si el problema que resuelve no se aplica a usted o si tiene una solución diferente a ese problema.

Recomiendo usar un DVCS moderno como git o Mercurial. Están diseñados para el desarrollo paralelo, por lo que almacenan los cambios de forma diferente que los sistemas anteriores, lo que hace que la fusión sea mucho más sana.

Tiendo a usar Git para mis proyectos, pero el process que suelo seguir es el siguiente (y también debería funcionar para Subversion):

  • para cada característica nueva, crea una twig para esa característica.
  • Cuando todo funcione, combínalo en la twig de staging y despliégalo en el server de transición (tienes uno de esos, ¿no?)
  • Una vez que estamos seguros de que el cliente está contento con lo que está sucediendo, fusionamos la twig de etapas en la twig de producción, la labelmos como production_release_22 o production_release_new_feature_x , y luego implementamos esa label en el server de producción.

Las tags nunca se actualizan, una vez que se implementa algo, se mantiene así hasta que se generan, testingn y labeln más cambios, y luego se implementa la nueva label. Al asegurarme de que se implementan las tags y no las twigs , evito que yo mismo (u otros) haga cosas como "Voy a cometer este cambio rápido y actualizar el server sin probarlo".

Me ha funcionado bastante bien hasta ahora.