Control de Versiones de Código en Dynamics NAV
¿Un sistema de control de código en Dynamics NAV?
Como probablemente sabréis, Dynamics NAV no dispone de ningún componente para control ni versionado de código, ni lo va a tener de momento. Hay que hacerlo manualmente a base de exportar los objetos, depositarlos en algún repositorio donde los programadores del proyecto tengan acceso controlado, y posteriormente si se desea restaurar a un punto anterior, o incorporar alguna nueva funcionalidad, trabajar con el “version list”, la fecha y hora de modificación, y utilizar una buena herramienta de comparación de ficheros.
Está claro que en este escenario el propietario del código del proyecto tiene serias dificultades para controlar las ramas, puntos de restauración, copias y saber cuál es la última versión buena conocida (Master). Además, estas dificultades se trasladan a los distintos programadores que tampoco saben con exactitud si el código con el que están trabajando es el adecuado y cuál es el bueno.
Se hace necesario entonces que en proyectos de cierta envergadura, y sobre todo para los ISV que crean, corrigen y evolucionan producto (add-on), dispongan de una buena herramienta que ayude a gestionar todos estos problemas. Para más info http://betterexplained.com/articles/a-visual-guide-to-version-control/
Para desarrollar este artículo se ha escogido Git https://git-scm.com y la plataforma GitHub https://github.com por su sencillez y efectividad, aunque existen otras herramientas muchísimo más completas, como Visual Studio Online (antes Team Foundation Server).
¿Qué es Git?
Git es un sistema distribuido de control de código fuente o SCM (en inglés Source Code Management). Distribuido significa que el repositorio no está centralizado y que existen varias copias distribuidas que Git sincroniza. Más info en https://git-scm.com/about
Beneficios:
• Auditoría del código: saber quién ha tocado qué y cuándo
• Control sobre cómo ha cambiado el proyecto en el transcurso del tiempo
• Volver hacia atrás de una forma rápida
• Control de versiones a través de etiquetas: versión 1.0, versión 1.0.1, versión 1.1, etc.
• Seguridad: todas las estructuras internas de datos están firmadas con SHA1
• Mejora la capacidad de trabajar en equipo
• Merging y branching extremadamente eficientes
Su metodología se basa en la creación de ramas a partir del proyecto principal denominado Master siguiendo una tipología: Feature, Release, HotFix, su posterior “mergeado” y “tageado”.
El repositorio local se basa en un workflow de 3 estados: las modificaciones efectuadas en el directorio de trabajo serán efectivas cuando se manden al Staging Area, área en la que en cualquier momento se podrá decidir si descartar o “commitear” el código. Las sincronizaciones siempre se efectuarán desde los repositorios locales.
¿Qué es GitHub?
GitHub utiliza el sistema de control de versiones Git para proporcionar una plataforma de desarrollo colaborativo de software que se enfoca hacia la cooperación entre desarrolladores e integradores para la creación y difusión de software.
Dispone de un cliente Windows https://windows.github.com para, gráficamente, gestionar los 3 estados del repositorio local, sincronizarlo y ver el histórico de cambios.
Sincronizar el código con el servidor de GitHub permite que en algún momento, un integrador dirija y maneje los cambios y posibles conflictos en el código provenientes del resto de repositorios de los demás programadores para, mediante un espacio de discusión, descartar, aparcar, corregir o incorporar estos desarrollos en el tronco principal o Master. Lee esta informaciónhttps://guides.github.com/introduction/flow para comprender mejor su funcionamiento.
Como curiosidad añadir que la flamante plataforma de Business Intelligence Microsoft PowerBI https://powerbi.microsoft.com/#connect-wrapper permite escoger entre sus múltiples orígenes de datos a GitHub. De esta manera se podrá acceder a los Issues, Milestones, Pull Requests, etc.
Integración con Dynamics NAV
Todo lo que necesita el cliente Git para controlar el código de cada programador, y por tanto el proyecto, son ficheros de texto y Dynamics NAV permite la exportación en formato texto de cualquiera de sus objetos.
En este punto la exportación de objetos al directorio de trabajo controlado por Git ha de hacerse manualmente pero podría hacerse un script que se ejecutara cada cierto tiempo y que hiciera la exportación de los objetos en NAV al directorio de trabajo controlado por Git.
Creo que la mejor forma de comprender Git, GitHub y la integración con NAV es a través de un sencillo tutorial. Para realizar el tutorial a continuación es indispensable haberse registrado en la plataforma GitHub y haber instalado su cliente. https://windows.github.com
Paso 1 – Creación del Repositorio principal (Master)
Desde el cliente GitHub crearemos un repositorio al que denominaremos “Practica GitHub-NAV”. Cuidado, no incluir acentos ni en GitHub ni en el nombre de los objetos o el versión list en NAV, tiene efectos “extraños”.
Desde NAV exportaremos los objetos al directorio local creado en el paso anterior. La exportación de objetos debe realizarse uno a uno para facilitar posteriormente el seguimiento de código en cada objeto, aunque cabe recordar que en el Development Shell de NAV disponemos del comando Split-NAVApplicationObjectFile para dividir todos los objetos contenidos en un único fichero. Puedes utilizar estos objetos para realizar esta prácticahttp://www.tipsdbits.com/Downloads/tabid/57/ItemID/95/Default.aspx
Una vez el cliente GitHub haya identificado los objetos, procederemos a realizar el commit, indicando “Paso 1 – Creación del Repositorio” en el summary.
Ahora al publicar el repositorio, Git mandará todos los commit efectuados. El objetivo es que nuestro código esté disponible al resto de programadores. Notar que la rama será la principal, o sea, Master.
A partir de este instante ya aparece el repositorio en nuestra página principal de GitHub.
Paso 2 – Creando una rama y añadir funcionalidad
Vamos a crear una nueva rama a partir de la Master con el objetivo de incorporar funcionalidad al desarrollo.
Publicaremos de nuevo.
Para que GitHub refleje la creación de la rama y esté así disponible para el resto del equipo.
Desde NAV Development Environment añadiremos los siguientes campos a la tabla 94000, Blocked de tipo boolean, Blocked By de tipo texto y Blocked On de tipo fecha. En la página 94000 añadiremos el campo Blocked creado anteriormente.
Exportaremos los 2 objetos al directorio de trabajo correspondiente al repositorio. En este instante el cliente GitHub ya debe mostrar los cambios efectuados en la rama.
Realizaremos un nuevo commit poniendo “Paso 2 – Creando una rama y añadir funcionalidad” en el summary.
Pero nos damos cuenta que los campos “Blocked By” y “Blocked On” no los vamos a necesitar con lo que decidimos que debemos borrarlos. Para ello haremos un Revert del último commit.
Desde NAV importaremos los objetos desde el directorio de trabajo ya que al hacer el revert los objetos están igual que en el primer commit, Git los ha revertido, lógicamente. Añadiremos el campo Blocked de tipo Boolean en la tabla y en la página, exportaremos los objetos y desde GiHub realizaremos un nuevo commit poniendo “Paso 2b – Creando una rama y añadir funcionalidad” en el summary.
Observar como en este instante tenemos 3 commits pendientes de sincronizar, 1-el que añade los campos, 2-el que los quita (por que revierte) y 3-el que añade tan solo el campo Blocked.
Sincronizamos y vamos a ver lo sucedido en la plataforma GitHub donde podemos apreciar que la rama Master sigue intacta (está en el Paso 1), pero hay una propuesta de mergear la rama Feature 1.
Paso 3 – Mergear con Pull Request
Ahora de lo que se trata es de hacer llegar la funcionalidad añadida en la rama “Feature 1” al tronco principal “Master”. Para ello GitHub dispone de la acción Pull Request. Esta acción creará un espacio de trabajo donde el resto de programadores involucrados podrán discutir acerca de este merge e incluso aportar nuevos commits si fuera necesario, con el objetivo de hacer el merge.
Haremos click en Compare & Pull Request GitHub, que nos permitirá:
• Comprobar que el merge de la Feature 1 se puede realizar automáticamente.
• Escribir comentarios visibles al resto.
• Asignar etiquetas, hitos y recursos al Pull Request.
• Ver todos los commits y los cambios en cada uno de los commit.
• Ver los ficheros afectados y comparados, en este caso con la Master ya que es de donde partió la rama.
El hacer click en Create Pull Request, no hace el merge, crea el espacio de trabajo para que con la ayuda de los demás se pueda realizar el merge con garantías.
Es importante destacar que aunque se haya creado el Pull Request, la rama sigue admitiendo commits con el fin de adecuarse a los requerimientos que pudieran surgir en la discusión sobre el merge.
En nuestro caso vamos a imaginar que alguien sugiere que si el campo Blocked es boolean, alguna otra funcionalidad no funcionaría adecuadamente y que por tanto debemos cambiar el tipo de campo de boolean a option: bloqueado, semi-bloqueado y desbloqueado.
Hacemos la modificación desde el NAV Development Environment y exportamos los objetos al directorio de trabajo (no hace falta modificar ni exportar la página). Commiteamos con el summary “Paso 3 – Mergear con Pull Rquest” y sincronizamos.
En GitHub vamos a revisar el Pull Request y ahora incluye un nuevo commit que soluciona la sugerencia del tercer desarrollador o consultor del proyecto.
Destacar que hasta este momento el tronco principal Master ha permanecido intacto, si alguien hubiera modificado alguno de los ficheros que hemos modificado nosotros a través de la rama “Feature 1”, tendríamos un conflicto y el merge no podría automatizarse.
Finalmente pulsaremos sobre la acción “Merge pull request” y una vez realizado el merge nos da la opción de borrar de forma segura la rama. Es de forma segura porque en todas las trazas se mantiene en qué rama se hizo tal o cual modificación.
Si ahora volvemos a la página principal del proyecto en GitHub y seleccionamos la rama Master, la principal, podremos comprobar como los commit se han incorporado.
Paso 4 – Hacer una Release
Accederemos a la opción Releases y desde aquí crearemos una nueva release, en nuestro caso, la primera.
Observar cómo podremos incluir otro tipo de ficheros en el paquete, en el caso de proyectos en Dynamics NAV podríamos incluir add-ins con el objetivo que la descarga incluyera todos los componentes necesarios para la ejecución del código del proyecto.
Ahora necesitamos trasladar manualmente el tag asignado anteriormente al trigger Documentation, al version list o a ambos, en nuestro proyecto en Dynamics NAV. En cualquiera de los casos el cliente GitHub lo identificará como un cambio con lo que en algún momento deberemos realizar un commit para hacer llegar esta modificación a GitHub.
Está claro entonces que el momento de asignar el tag a los objetos de NAV es justo antes de crearlo en GitHub para evitar el conflicto descrito en el párrafo anterior.
Conclusiones
En demasiadas ocasiones he acudido a algún cliente y cuando he puesto las manos en su base de datos de NAV he visto que “no había por dónde cogerla”. Me refiero a que, y yo soy el primero en hacerlo, para ir rápido y buscando la eficiencia (resultado deseado con el menor coste posible), nos hemos puesto a toquetear copiando y documentando lo mínimo.
El resultado es que después de unas semanas, y después de que hayan pasado también varios de tus compañeros, lo único que se sabe con certeza es que el código bueno es el que está en producción, pero, ni rastro de trazabilidad, ni ramas para el añadido de nuevas funcionalidades o arreglo de bugs, ni histórico de releases… ni nada de nada.
Efectivamente es parte del “beauty of simplicity” en Dynamics NAV que tantas veces defiendo y que con orgullo comparo con otros ERPs más complejos, técnicamente hablando. Aunque he de reconocer que en ocasiones esta misma belleza de la simplicidad es un arma de doble filo si no la utilizamos con orden y disciplina.
fuente : https://www.linkedin.com/pulse/controlando-c%C3%B3digo-en-dynamics-nav-josep-pages
Share