En capítulos anteriores hablamos sobre cómo
instalar y configurar Team Foundation Server, así como las posibilidades que ofrece para
gestionar tareas y
administrar el código fuente desde nuestra instancia de
Microsoft Dynamics AX 2012. Comentamos las funciones básicas ,aunque imprescindibles, para proteger y desproteger el código en el servidor y las ventajas que ello suponía en cuanto a almacenar todo el histórico de cambios de los objetos, como por ejemplo: revisar el historial de cambios de un objeto, volver a una versión anterior, descartar cambios sin confirmar, etc.
Sin embargo hay ciertos problemas que una gestión básica del código fuente no es capaz de solucionar. Por ejemplo, en una instalación normal de nuestro ERP, a la vez que damos el soporte diario y realizamos pequeñas modificaciones para solucionar problemas, estamos llevando a cabo desarrollos de mayor o menor impacto. Estos desarrollos paralelos necesitan ser integrados en el código de producción de alguna forma, pero si usamos el mismo servidor para desarrollar y para hacer el mantenimiento, tendremos que llegar a un punto en el que todos los desarrollos estén totalmente terminados para pasar a producción de forma limpia y segura.
De la misma forma, si nuestra empresa desarrolla un producto final, es necesario avanzar el desarrollo de las siguientes versiones mientras damos soporte a las versiones publicadas en el pasado, incluso para diferentes versiones de AX. ¿Cómo estar seguro que un
hotfix urgente desarrollado para un cliente llega a todas las versiones de nuestro producto que la necesitan, de forma limpia y estable?
Por supuesto hace falta un buen método de trabajo para que todo esto pueda realizarse de forma ordenada y sin errores, pero también hace falta la ayuda de alguna herramienta y para eso tenemos las ramas (
Branches) disponibles en casi todos los sistemas de control de versiones del mercado, y por supuesto en nuestro
Team Foundation Server.
Estrategias de branching
Existen infinidad de estrategias para definir las ramas que necesitamos en nuestros equipos, y ello va a depender de la cantidad de equipos que tengamos, la cantidad de productos, de versiones, etc.
NO HAY una estrategia de ramas estándar o válida para todos y es algo que se debe pensar con cuidado ya que la estrategia elegida nos va a suponer ventajas e inconvenientes. Lo más recomendable es empezar por la lectura de la guía
Version Control Guide escrita por el grupo
Visual Studio ALM Rangers donde explican la mayoría de opciones con sus pros y sus contras.
Ya está disponible la revisión mensual de Microsoft Dynamics Lifecycle Services (LCS). Los cambios más importantes son sin duda las primeras funcionalidades disponibles para el manejo de diferentes versiones del nuevo Microsoft Dynamics AX.
