Vaya por delante que no soy, ni mucho menos, un experto en gestión del código ni Azure DevOps. Todo lo que viene a continuación es fruto, como comentaba antes, de la experiencia (y las meteduras de pata) de casi 3 años trabajando con MSDyn365Ops. En este artículo de la documentación sobre estrategias de branching hay más información sobre branching y links a artículos del equipo de DevOps. Y en la Biblioteca de herramientas y guías de los DevOps Rangers hay incluso muchísimo más!
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!