He escrito este post después de que lo sugiriera Mötz Jensen en un largo y muy interesante hilo de Twitter acerca de control de versiones para Dynamics 365 for Finance and Operations. Este es el tweet de Denis Trunin que lo ha iniciado todo:
New blog post – Understanding D365FO Version control system and why it is different from AX2012 https://t.co/S26JU99qtP
— Denis Trunin (@TruninDenis) May 27, 2020
Leed las respuestas porque es de lo más interesante que he visto en Twitter en meses!
También puedes leer mi guía sobre MSDyn365FO y Azure DevOps ALM!
Branching
Cuando decidas qué estrategia de branching vas a usar tienes que pensar en qué será lo que mejor le vaya a tu equipo y en seguir el principio KISS. Usa una estrategia lo más sencilla posible! Lo que no quieres es pasarte el día limpiando código y solucionando merges mal hechos no?
También ten en cuenta que tu estrategia de branching puede no ser la misma si trabajas en un proyecto de implantación para un cliente que desarrollando un ISV.
Main – Release
Esta es de las más simples, trabajaremos en la rama Main, todos los desarrolladores. Seguiremos el trabajo ahí hasta el arranque.
Cuando vayamos a arrancar haremos un branch de Main y crearemos Release. Esta nueva rama será la que usaremos para promocionar el código a producción. El desarrollo de nuevas características y bugs se hará en Main.
Cuando terminamos un desarrollo, o arreglamos un bug, haremos un merge del changeset (o changesets) a la rama Release. Sí, haremos cherry picking, sé que tiene mala reputación pero dependemos de que los clientes validen los cambios…
En nuestros proyectos solemos tener por lo menos 2 entornos Tier 2+. Usamos uno para testing y validación. En éste entorno desplegamos el DP creado con la rama Main. En el otro Tier 2+ los usuarios hacen sus pruebas y es el que usamos para promocionar el código a prod. Este segundo entorno es el que se actualizará con el código de Release.
Dev – Main – Release
Esto es algo que hemos estado haciendo últimamente para intentar emular las ramas de desarrollo tipo Git. Estamos usando una rama Dev para cada desarrollador. Trabajamos cada uno en nuestra rama, hacemos todos los check-ins que queremos mientras desarrollamos y, cuando está terminado, lo mergeamos todo en un único changeset a Main. Después hacemos Forward Reverse Integrate de Main a nuestra rama Dev para traer todos los desarrollos de los demás programadores.
Sí, esto implica un poco más de merges en la parte de Dev-Main. Pero la idea es tener una lista limpia de changesets únicos en nuestra rama Main para cada desarrollo. ¿Por qué? Porque… cherry picking…
Trabajaremos con Dev y Main hasta el arranque, entonces haremos branch de Main y crearemos la rama Release. Actualizaremos los entornos Tier 2+ de la misma manera que con la estrategia Main ‘ Release.
Como he dicho la idea es tener una lista limpia de changesets para mover los desarrollos de Main a Release y resolver todos los conflictos de merging en las ramas Dev. Cada desarrollador es responsable de su rama y de resolver los conflictos ahí.
Hemos estado trabajando unos meses de esta forma y los resultados son positivos y no estamos teniendo problemas con la gestión. En el futuro lo probaremos con Git pero esto lo va a explicar Juanan!
Consejitos
Primero de todo: fórmate a ti y a tu equipo. Recuerda, usar un VCS es obligatorio, esto ahora es parte de tu trabajo. Busca a alguien que os pueda ayudar, incluso si no trabaja con AX. Los problemas de desarrollo de software son parecidos independientemente del lenguaje que usemos.
No dejéis changesets pendientes de ser mergeados. La cantidad de conflictos que aparecen es directamente proporcional al tiempo que lleva el changeset esperando a pasar de rama.
Recuerda, Keep it simple, stupid (o Keep it stupid simple), KISS, no te compliques la vida!! No sigas ciegamente los consejos que te da un tipo por internet, porque puede tener problemas distintos que los que tienes en tu proyecto!
Así que así es como hago branching. ¿Hay formas mejores de hacerlo? Seguro que sí! ¿Se puede mejorar? No tengo la menor duda de que sí! Pero esto nos funciona, que es lo más importante.
