¿Usando Git a la versión Microsoft Dynamics NAV?

Question

Soy desarrollador de .NET, pero en nuestra organización también tenemos un par de desarrolladores de Microsoft Dynamics NAV. Actualmente no usan ningún control de fuente. Sé muy poco acerca de NAV, pero, según tengo entendido, puede secuenciar objetos desde NAV e importar desde los scripts.

En ese caso, ¿alguien está usando Git con NAV? ¿Te has encontrado con algún problema en el camino? Me pregunto si esta es una buena solución para sugerirles, y si es más complicado de administrar que usar Git con .NET (lo cual he encontrado razonablemente fácil).

Answer 1

Sí, estamos utilizando Git junto con Dynamics NAV con gran éxito.

Lo malo es que todos los objetos se deben exportar a txt antes de que Git dé significado. Esperemos que Microsoft cree un enfoque más fácil para exportar objetos a txt. Estamos usando este modelo. Cree un repositorio de Git con un maestro general y una rama para cada objeto que cambiemos. Todos los archivos fuente deben tener el mismo nombre que el archivo superior de la rama para hacer que Git rastree las diferencias. Usando Git de esta manera, nunca fusionamos nada en master. Después de comenzar a usar Git es mucho más fácil trabajar en objetos compartidos y rastrear lo que otros NSC han hecho con el código. Y IT-Revision está contenta porque todo el código está bien documentado y el camino para cualquier repliegue es mucho más fácil. Daré mi total respaldo para usar Git con Dynamics NAV.

Navision Consultant, en aceite & Industria Energía

Answer 2

estoy usando Dynamics NAV y Git, sin embargo no al mismo tiempo. Déjame explicar por qué.

El Git sí es fresco (con GitHub se pone aún mejor), pero el puerto de Windows es pobre, a menos que no le gusta que se adhieren a la línea de comandos Unix, ya que es el método recomendado para configurar msysGit. Las herramientas de GUI en Windows no son buenas, desafortunadamente.

Para mí fue difícil hacer entender a mi jefe, por eso usar el control de versión distribuida es mejor que el TFS habitual. Para los chicos orientados a los negocios, un gran repositorio central se siente más seguro (porque pago mi propio servidor, controlo el acceso) y soy más robusto (contraté a un administrador de sistemas que ejecutará los procedimientos de mantenimiento).

Decidí no luchar contra esta voluntad. Estamos utilizando el control de versión distribuida como área de ensayo. Todos los cambios inestables se almacenan en esta área y hacemos pruebas dentro de nuestro equipo. Después de finalizar la estabilización, los objetos se fusionan en el repositorio central. Todos se ven felices.

En cuanto a Git: Recientemente he pasado a otro control de versiones distribuido - fossil debido a las siguientes razones:

• Se puede hacer todo lo que puede Git;
• Se ve, se siente y actúa de forma nativa en Windows;
• Tiene una interfaz web incorporada y puedo hacer que funcione fácilmente como un servicio nativo de Windows;
• Ha integrado el seguimiento de problemas, por lo que ya no necesito herramientas de terceros;
• El repositorio es un archivo único, por lo que puedo llevarlo conmigo en un pen drive donde quiera;

En cuanto a nuestra solución NAV. Son más de 1000 objetos, más de 20 MB.

EDIT: Algunas actualizaciones después de más de medio año de codificación.

Cambiamos de nuevo a git. Dado que su combinación automática es AWESOME. Solo para ganar la apuesta moví una solución (objetos estándar modificados y nuevos) de NAV7CTP3 a NAV7CTP5 en 4 horas. Mientras que un equipo de cuatro desarrolladores logró el mismo resultado que necesita casi tres semanas de trabajo diario.

Git realmente hace la diferencia. Creo que los mismos resultados son posibles con otros sistemas de control de versiones distribuidas.

La razón es: Git y otros sistemas distribuidos ahorrar mucho más información durante una confirmación de esto es TFS y SVN. No es tan importante durante el desarrollo regular, pero cuando se trata de fusionar, toda esta información 'redundante' de Git hace la diferencia.

Durante la combinación, Git encuentra la revisión común que inició una rama y luego aplica los cambios de ambas ramas paso a paso, de la misma forma que el desarrollador cambió el código, a todos los archivos en solución.

Si la misma línea se ha cambiado en ambas ramas que muestra el conflicto. Si no, solo guarda los archivos en la carpeta de trabajo lista para la confirmación.

Aquí algunas estadísticas:

• El número total de archivos procesados ​​en ambas bases de código CTP3 y CTP3 es de alrededor de cuatro mil cada uno;
• El número total de objetos de la solución fusionados es 1170;
• El número total de archivos en conflicto es 140;
• La tasa de fusión automática exitosa es de aproximadamente el 88% (1170 - 140)/1170 * 100 = 88%;
• La mayoría de los conflictos son cambios en las versiones del objeto: trivial;
• Conflictos no triviales en aproximadamente 20 archivos;
• Trivial buscar y reemplazar se hizo en todos los objetos fusionados (para fijar RunFormOnRec -> RunPageOnRec, etc.);
• El resultado es un conjunto totalmente importable de los objetos de solución más recientes basados ​​en CTP5;
• El número de errores de compilación después de la importación es aproximadamente 50;
• La mayoría de estos errores se relacionan con cambios en objetos estándar hechos desde CTP3 a CTP5;
• La tasa de objetos con fallas es de alrededor del 4% (50/1170 * 100% = 4%);

Answer 3

Estamos utilizando git con Dynamics NAV con gran éxito.

pero tengo que decir que no fue fácil. Dynamics NAV (utilizamos la versión 2013) no está optimizado para git o desarrollo basado en archivos. El desarrollo generalmente se realiza directamente en el entorno de desarrollo (cliente clásico) que guarda el código fuente directamente en la base de datos.

Así que lo que hicimos para apoyar Git es: Construimos un montón de comandos de PowerShell útiles que ayudan a los desarrolladores para sincronizar una base de datos NAV con una carpeta local de Git. F.e. tenemos un comando que exporta todos los objetos con un indicador modificado en la carpeta git local, o un comando que importa todos los objetos entre a las confirmaciones de git.Incluso usamos eso para actualizar automáticamente nuestra base de datos de prueba con un git push en la máquina de desarrollo.

Pero eso es lo siguiente: no fue fácil desarrollar todos estos procedimientos y crear scripts.

Así que le recomiendo que lo piense dos veces acerca de la decisión de usar git con Dynamics NAV. El software no está diseñado para funcionar con git, por lo que tendrás que trabajar mucho, y la pregunta es si tu jefe está dispuesto a darte el tiempo para construir las herramientas necesarias para trabajar sin problemas.

Eche un vistazo también en Object Manager Advanced. Esa es una herramienta que utilizamos antes. Vi una vez una vista previa de idyn (Compañía) donde reemplazaron el clásico cliente de entorno de desarrollo con Visual Studio. Cambiamos de Object Manager Advanced a git como herramienta de desarrollo principal porque no era adecuado para nuestros casos comerciales. Pero todavía lo estamos usando, es decir, para la función Where Used ¡la bruja es genial! (La película es de una versión NAV antigua, lo siento)