Dos enfoques para el control de versiones (TFS): necesita asesoramiento

Estamos llegando a un punto en nuestro proyecto en el que tenemos que hacer una implementación de producción, pero también necesitamos tener un desarrollo continuo para las características futuras. Nuestro control de fuente actualmente tiene una sola twig de desarrollo. En mi empresa anterior, se creó un sistema de 3 sucursales con Desarrollo, Integración, Producción. El desarrollo de características se realizó en Desarrollo, el análisis en Integración y Producción siempre fue el código que se ejecuta en el entorno de producción actual (excepto por un time breve cuando se realizó una fusión desde Integaración a Producción y se realizó la implementación).

Cada vez que se producía un cambio de Producción o una fusión en Producción que se implementaba en vivo, se sacaba una nueva twig de file Producción y se le asignaba un número de versión. Cualquier cambio en una sucursal más alta se fusionó para que los cambios en la Producción regresen al Desarrollo, por ejemplo. Funcionó pero nunca vi la necesidad de una twig de Integración y Producción en curso.

Dos aspectos de este sistema que realmente no me gustó: 1) la fusión de la twig de integración en la twig de producción: preferiría tener una twig de producción "limpia" cada vez, aunque deberían estar sincronizados después de una combinación y 2) este el sistema no permite múltiples implementaciones del sistema que ejecutan diferentes versiones del código al mismo time, aunque esto no ha sido un requisito en ninguno de los equipos para los que he trabajado (todavía).

He escuchado que este model es común, pero en el sistema que estoy configurando ahora propongo lo siguiente:

Tener una sucursal de Desarrollo, crear una nueva twig de Liberación cada vez que el Desarrollo esté listo para la próxima implementación en la producción. Las twigs de Release reciben un número de versión y luego se vuelven a ramificar a una twig de file. Las testings se realizan en la twig de Liberación. Una vez implementadas, cualquier corrección de producción se realiza en la twig de Liberación, luego se crea una nueva twig de file con un incremento de número de versión menor una vez que se atesting la implementación. Cuando una nueva implementación de Desarrollo está list, se crea una nueva twig de Versión …

Para mí, esto es más simple y en realidad es mejor: NO hay una twig de Integaración (less fusión) y hay una nueva twig de Producción (Versión) para cada implementación y abastece las versiones de Producción actuales. ¿Qué me estoy perdiendo? ¿Por qué elegir el model de Desarrollo, Integración y Producción?

Gracias

La ventaja del sistema de 3 sucursales es que sus desarrolladores, probadores y clientes tienen cada uno su propia versión / twig aislada del código. Esto proporciona un desarrollo "cerrado" donde las características solo se pueden promocionar a la siguiente twig cuando pasan una cierta barra de integridad / calidad, lo que da una gran security de que la twig de publicación siempre se encuentra en un estado adecuado para enviar a un cliente.

Pros:

  • Usted (casi) siempre tiene una compilation que podría enviarse a un cliente en cualquier momento.
  • Sus probadores (casi) siempre tienen una compilation activa para probar
  • La twig de publicación es estable, por lo que no suele tener que corregir errores y fusionarlos de forma inversa en las twigs de testing / desarrollo.

Contras:

  • Debe fusionarse frecuentemente para promocionar las funciones completadas hasta la twig de publicación. Esto no es tan malo, ya que esta combinación es simplemente una operación de copy rápida (siempre que no realice ediciones en las twigs de testing / versión, nunca tendrá que combinar un conflicto de fusión)

Si toma el enfoque de una única twig de desarrollo desde la que se divide una twig de publicación solo cuando se requiere una versión, entonces está trabajando efectivamente en un sistema no ramificado la mayor parte del time. Es decir, tiene una compilation de trabajo en progreso inestable en su twig de desarrollo, que luego copy en una twig de publicación, donde trabaja en ella como un trabajo en progreso hasta que se estabiliza para liberar calidad. Si continúa desarrollando las funciones en la twig de desarrollo mientras corregimos la bifurcación de la versión, entonces obtendrá una gran cantidad de conflictos de fusión para resolver. Pasas mucho time sin una buena construcción para probar, y sin una versión desmontable que puedes enviar si es necesario.

Tampoco hay mucha necesidad de ramificar el código en una twig de file cuando lo lanzas: todo lo que necesitas hacer es labelr el código cuando realices un lanzamiento para get una "instantánea" fiable que puedas recuperar en el futuro.

Su sugerencia no está muy lejos de las recomendaciones. La principal diferencia en el model es que está sugiriendo que se desarrolle directamente en lo que anteriormente era la twig de 'integración'. Mucha gente sugiere tomar una sucursal de esta sucursal para hacer su trabajo y luego volver a fusionarse. Pero depende del tamaño de su equipo.

Un recurso invaluable para trabajar con la ramificación TFS es aquí:

http://tfsbranchingguideiii.codeplex.com/

Su propuesta suena exactamente de la manera en que estoy trabajando:

  • Me desarrollo en la twig principal hasta que mis desarrollos estén listos
  • Luego se crea una twig de lanzamiento, digamos lanzamiento 1.5
  • Después de que la twig de lanzamiento ha sido probada, se ramifica nuevamente, llamándolo 1.5.1
  • La corrección de errores se realiza en la twig principal y en todas las twigs de liberación activa (p. Ej., 1.3, 1.4, 1.5)
  • Se crean y envían regularmente nuevas versiones (sucursales) de las twigs de publicación a los clientes (por ejemplo, 1.5.2, 1.5.3, …)

En mi experiencia, esto funciona bastante bien, pero probablemente también depende de cómo esté organizada su empresa.

Un lugar donde solía trabajar tenía una twig para cada lanzamiento. Pasamos más time ramificándonos que fusionándonos. Fue un poco excesivo.

Si piensa en un model mental con un gráfico de nodos conectados, la twig Producción es simplemente otro nodo conectado a la twig principal de Integración.