Antes de entrar en profundidad a explicar qué es GIT y por qué usarlo en proyectos de Business Central, hagamos un pequeño repaso a los cambios que Business Central ha sufrido en su pasado reciente en cuanto a la forma de programar.
🔵 De FOBs a ficheros
El nuevo entorno de desarrollo, Visual Studio Code se basa en ficheros de texto.
Esto ha supuesto un gran cambio comparado con los .FOB, formato en el que se guardaban los objetos en el antiguo C/SIDE… que ahora parece como volver a la prehistoria de la programación.
Los ficheros de texto con los que trabajamos ahora nos han abierto las puertas a una variedad de herramientas a las que antes no podíamos recurrir. GIT es una de esas herramientas.
🔵 Por qué usar GIT
Personalmente no me gustaría tener que volver a un sistema en el que GIT no estuviera en la ecuación.
Las ventajas de usar GIT como sistema de control de versiones de nuestro código fuente son muchas. Aquí te detallo algunas de las razones por las que utilizar GIT:
- Nos permite ver qué cambios se han producido en el código, quién ha hecho esos cambios, cuándo y por qué. Se trata de una trazabilidad completa de los proyectos que nos dan mucha más información de la que teníamos antes en los proyectos de C/SIDE.
- Facilita que dos o más programadores trabajen en un mismo proyecto. Nuestro código fuente se guarda ahora en ficheros de texto en la máquina del programador. GIT nos facilita el intercambio de código fuente de una forma muy fácil y ágil.
- Ramas. GIT nos permite crear ramas para cada nueva funcionalidad en la que estamos trabajando. De esta forma, el trabajo de un programador no interfiere con el de los demás, incluso si dos personas están trabajando en la misma parte de la funcionalidad, modificando los mismos ficheros.
- Pull Request y Code Review. Una vez el desarrollo en una rama ha finalizado, haremos un pull request para que nuestro código se integre en la rama principal. Esta es una ocasión perfecta para introducir el concepto de Code Review: que un programador senior se encargue de revisar y aprobar el trabajo del resto de compañeros, incrementando así la calidad del código.
- Comparar código y hacer merging. GIT ofrece una gran capacidad para comparar código entre dos versiones distintas y ver cuáles son las diferencias. Además, el sistema es capaz de resolver de forma efectiva muchos de los conflictos de merge que surgen, y nos da herramientas ágiles para resolver manualmente el resto de conflictos.
- Copia de seguridad del código. Los repositorios de GIT actúan también como copia de seguridad del código, de forma que no tenemos que preocuparnos de tener que hacer copias de seguridad adicionales.
- Todos los entornos tienen el mismo código. En el antiguo C/SIDE solíamos tener múltiples bases de datos: una de producción, una de pruebas, una de desarrollo, etc. Podíamos tocar el código en todas ellas, por lo que con el tiempo acabábamos con diferencias entre ellas, de tal manera que nadie sabía ya qué entorno tenía qué funcionalidad. Ahora con GIT es mucho más fácil mantener todos los entornos con el mismo código.
- No perdemos código. Relacionado con el anterior punto, era muy habitual que en un intento de llevar a producción cambios que habíamos hecho en desarrollo, cargábamos un fob y acabáramos machacando alguna modificación, de la que muchas veces no teníamos ni copia de seguridad. Esto provocaba que perdiéramos código y tuviéramos que volver a empezar. ¿Por qué no teníamos copias de seguridad? Porque el código estaba embebido en la base de datos, por lo que las copias eran demasiado grandes y no podíamos guardar muchas, además de que restaurar las copias y comparar las diferencias en el código era extremadamente costoso. Con GIT esto ya no nos pasa. Con GIT es imposible perder código… ¡lo tenemos que hacer muy mal para perderlo!
- Código mucho más limpio. En C/SIDE solíamos usar los comentarios como nuestra forma particular de control de versiones. Usábamos el trigger OnDocumentation para describir los cambios, y ya en el código, comentábamos las líneas anteriores y escribíamos nuevas líneas. En partes del código que habían sufrido unos cuantos cambios acababas con más líneas comentadas que líneas funcionando, por lo que era difícil de leer y mucho más aún trazar los cambios. Ahora con GIT no necesitamos comentar las líneas anteriores, por lo que únicamente tenemos en el código líneas ejecutables, haciendo que lectura y revisión del código sea mucho más sencilla.Los ficheros de texto con los que trabajamos ahora nos han abierto las puertas a una variedad de herramientas a las que antes no podíamos recurrir. GIT es una de esas herramientas.
🔵 Más razones para utilizar GIT
El resto de los motivos por los que trabajar con GIT entran en el terreno de lo subjetivo, pero no por ello menos importante.
- Sé en qué están trabajando los demás. Antes resultaba muy difícil ver el código en el que estaban trabajando el resto de compañeros. Cada uno trabajaba en su parte del proyecto, pero nadie tenía la visión general de todos los cambios que se habían producido a nivel de código. Ahora GIT me permite ver los commits de los demás, hacer una comparación muy rápida y estar al tanto de todos los cambios.
- Tranquilidad. Con GIT sé que el código está a buen recaudo. Nadie va a machacar mi código al subir un FOB. Con cada pull request voy a poder ver qué cambios se están introduciendo. Y si hubiera un incidente y parte del código acabase funcionando mal, sería muy sencillo volver a un commit anterior. Todo esto me da una tranquilidad que antes no tenía. Y se agradece.
- Volver a coger el flow. Todos hemos experimentado ese estado de flow, en el que estás programando con la máxima concentración posible y el tiempo parece que se detiene. En algún momento tienes que parar, ya sea por una interrupción o porque se ha terminado la jornada. ¿Qué pasa cuando retomas el desarrollo? Pues que GIT te da una visión rápida de los últimos cambios que estabas haciendo, de forma que es muy fácil ver por dónde ibas y volver a retomar ese estado de flow mucho más rápido que antes.
- Una última revisión. Cada vez que hago un commit y cada vez que hago un Pull Request, utilizo las herramientas de GIT para hacer una última revisión y asegurar que no me he dejado nada. Esta última revisión me da tranquilidad y en muchas ocasiones también me ha permitido descubrir que me estaba dejando algo, pudiendo así acabar de completarlo antes de llevar el código a producción.
Como ves, hay muchos motivos por los que usar GIT.
Ahora bien, solo con un correcto manejo de GIT podrás sacarle el máximo rendimiento. Y lo digo con conocimiento de causa: he visto a gente usar GIT de forma incorrecta a los que el sistema de control de versiones les acabó resultando en un problema más que en una solución.
🔵 ¿Quieres aprender GIT? Apúntate a nuestra masterclass gratuita
Apúntate a nuestra masterclass gratuita “GIT en el desarrollo de Business Central” donde aprenderás cómo esta herramienta puede ayudarte a mejorar la gestión y productividad de tus proyectos de desarrollo para Business Central.
Se celebrará el miércoles 23 /11/2022 a las 15.30h a cargo de Cristina Nicolàs, cofundadora de ClipPlatform, programadora y consultora de Navision, Dynamics NAV y Business Central, con más de 15 años de experiencia.
¡Más de 2h de formación gratis!
Te esperamos.

Soy Laura Nicolàs, una de las gemelas del Navision.
Llevo más de 14 años trabajando con Business Central (antes conocido como Dynamics NAV o Navision). Hago consultoría, análisis, desarrollo, implantación, migraciones, actualizaciones de versión (upgrade), instalación, soporte y formación.
La formación es una de mis pasiones, así que estoy siempre grabando cursos que tienes disponibles en ClipPlatform.com
+40 cursos y +450 lecciones. Hay cursos para usuarios, para consultores y para programadores.
Comentarios