Control de fuente: compatible con múltiples versiones de un software

El control de fuente que utiliza mi proyecto .NET WPF es TFS. Los clientes del proyecto son todos internos de la empresa. En un futuro próximo, vamos a lanzar una versión a un solo cliente debido a un set de requisitos especiales.

Por lo tanto, planeamos crear otra sucursal en TFS e incorporar estos requisitos. El problema es que el cliente puede exigir soporte a largo ploop para esta versión y solo puede querer soluciones de defectos para entrar en el producto y no nuevas características que incorporamos en la twig principal.

Aunque esto es bastante manejable en la actualidad, mi temor es que 1-2 años después, podamos terminar teniendo múltiples twigs de código fuente que crearán un dolor de cabeza de mantenimiento de soportar n número de versiones.

¿Podría sugerir forms de mantener manejable toda esta situación, o si nuestro enfoque de crear varias sucursales en sí mismo es erróneo en primer lugar?

Yo diría que la pregunta es mucho más sobre un negocio que sobre la tecnología a usar.

¿Está seguro de que este es su único cliente que necesitará ese tipo de tratamiento de su empresa (me imagino que es un cliente importante)?

  • Sí. En este caso, solo haz una twig. Configurar scripts de testing automatizados. En cada confirmación que haya realizado en la twig principal que debería estar presente, también la twig de cliente int realizará una combinación. Ejecuta tus scripts nocturnos para verificar la integridad

  • No. Diría que no hagas branch, en este punto (al final cuántas twigs vas a gestionar contemporáneamente …) y usa la opción de configuration en el código . Eso significa una clara separación de las características disponibles para un cliente o para otro. Las características pueden estar disponibles en function de alguna opción de configuration disponible en el file de configuration de su aplicación. Si desea hacer las cosas más complicadas, ya que los clientes pueden manipular los files, puede devise types de licencia (keys) que computaron agregados de hash, no disponibilidad de características compartidas .

Desafortunadamente, la bifurcación siempre es un dolor de cabeza en los sistemas centralizados de control de versiones de código. En los sistemas distribuidos se maneja de una manera mucho mejor, pero, dicho sea de paso, se evitan por completo los conflictos, especialmente a largo ploop, es casi imposible en ambos casos.

Buena suerte.

Sugeriría que crearas la twig para la versión lanzada, y en cada lanzamiento posterior que realices desde esa twig (ya que solo estás corrigiendo errores), cada vez que salgas de esa "twig de reparación de fallas", no vuelvas a intentarlo. twig, pero crea una label para que puedas hacer reference fácilmente.

Mi sugerencia es que estudies la guía de ramificación TFS de Visual Studio ALM Rangers . Es bastante lectura, pero buena, y debería poder encontrar un escenario allí que le convenga, y es aconsejable cuando usa TFS. Lo encuentras aquí: http://vsarbranchingguide.codeplex.com/