02 - Desarrollo de Business Central desde cero: Uso de GIT y DevOps

Durante mucho tiempo, los programadores de Navision, hemos trabajado sin herramientas para la gestión del código fuente.  Con Business Central, ahora tenemos la posibilidad de tener un control del código fuente. Al final, nuestro código sea una pequeña modificación o sea una extensión muy compleja, tendrá un ciclo de vida, durante el cual habrá que modificar, mejorar, trabajar en equipo, tener copias de seguridad,... Eso es lo que tenemos con DevOps y GIT.

Creando una cuenta de Azure DevOps

Si ya dispones de una cuenta en Azure Active Directory, puedes entrar en Azure DevOps desde:

https://dev.azure.com/

En caso contrario, puedes comenzar a usar Azure DevOps gratis o bien con una cuenta de GitHub.

Para empezar a "controlar" el código fuente de nuestra extensión, lo que haremos será crearnos un proyecto de DevOps e introducirlo en el repositorio (Repos).

Crear un nuevo proyecto en DevOps

Una vez autenticados en DevOps, crearemos un proyecto mediante el botón que encontramos en la parte superior izquierda:

Le introduciremos un nombre y una descripción:

Azure DevOps - Repos

Como hemos indicado, Azure DevOps dispone de muchas herramientas para gestionar proyectos: Pipelines, Artifacts, Test Plans,...  pero hoy solamente veremos Azure Repos.  ¿Que es Azure Repos?  Es un repositorio donde almacenamos el código fuente de forma segura.  Allí podremos almacenar diferentes versiones modificadas del código.

Azure DevOps

Descargar GIT

El verdadero gestor de código fuente es GIT.  Azure DevOps y Visual Studio Code, le dan un entorno gráfico, ya que al final GIT funciona con comandos en línea.

Podremos descargar GIT para Windows de la web https://git-scm.com/download/win/

Una vez descargado e instalado en nuestro equipo, podremos crear repositorios locales con control del código.  Para verificar que lo tenemos instalado, podemos ejecutar en la línea de comandos git --version

Una vez instalado, debemos configurar nuestro usuario git y nuestro correo electrónico con los siguientes comandos: 

git config --global user.name

git config --global user.email

¿Como funciona GIT?

El control de código fuente funciona con tres areas en el entorno local y un repositorio o varios en la nube:

Directorio de trabajo:   Donde tenemos nuestros ficheros que vamos modificando

Area de almacenamiento provisional:  Es un directorio donde se van guardando nuestros ficheros previo a almacenarlos en el repositorio local.  Podemos introducir o quitar ficheros según queramos que se guarden o no en el repositorio local.

Repositorio local:  Una vez confirmados las modificaciones mediante una instrucción "commit" se guardan en el repositorio local.  Eso significa que se guarda una copia tal cual se encuentra en este momento.

Repositorio remoto:  Cuando tenemos almacenado el código en el repositorio local, podemos "sincronizarlo" con uno o varios repositorios remotos.

Ya tenemos instalado DevOps y GIT.  Hemos creado un proyecto dentro de DevOps, y ahora lo que tenemos que hacer es rellenar de código nuestro repositorio.

Nueva extensión en VS Code

Si necesitas saber como desarrollar un extensión, puedes ver aprenderlo aquí (https://blog.msdyn365bc.es/2022/05/esarrollo-en-business-central-desde-cero.html) o bien en mi canal de Aprende Business Central en Español https://www.youtube.com/watch?v=7Gvb_PxSgdk.

El propio VSCode, ya dispone del interface para la gestión del código fuente mediante GIT, pero con la diferencia que no necesitamos aprender los comandos a ejecutar.

Estando en VSCode, lo que haremos será inicializar el repositorio GIT.  Es decir, indicarle a GIT que empiece a controlar los cambios realizados en la carpeta (directorio de trabajo).

Para ello usamos el comando git init o bien en la paleta de comandos usaremos:

Este comando nos pide la carpeta que vamos a controlar, por defecto la carpeta en la que hemos guardado nuestro proyecto.

Una vez ejecutado, ya vemos que disponemos de un control de cambios que nos dice que tenemos una serie de ficheros modificados con respecto al repositorio local (dado que lo acabamos de inicializarlo, todos son nuevos):

GitIgnore

Habrá casos en los que por la razón que sea, no queramos que se controlen todos los ficheros.  Cuando desarrollamos extensiones, es muy común que los Símbolos (los objetos descargados del estandard) no se necesiten llevar al repositorio.  Para eso tenemos el fichero GitIgnore.  Es un fichero en el que iremos incorporando lo que no queramos que se haga seguimiento.  Para incorporar ficheros, podemos crear el fichero gitIgnore e ir añadiéndolos o bien dejar que VSCode lo haga por nosotros, seleccionandolos y con el botón derecho indicarle "Añadir a GitIgnore"

Guardar los ficheros en el repositorio local: commit

Aunque podemos ir añadiendo los ficheros al area de almacenamiento provisional (pinchando sobre el símbolo más que aparece junto al nombre), lo normal que queramos guardar todo lo modificado en el repositorio local.  Para ello usaríamos el comando commit y añadiremos un comentario para tener más información sobre lo que estamos guardando.

En nuestro caso, como usamos VSCode, podemos hacer el procedimiento simplemente, introduciendo el comentario en el campo "mensaje" y pulsando el botón de confirmación:

Una vez ejecutado, el control de código fuente estará vacio, puesto que todos los ficheros modificados, ahora están en el repositorio local.

Perfecto, ya tenemos el código guardado en el repositorio local, pero está en nuestro equipo. Si mañana tengo un virus o se rompe, todo mi código estaría comprometido, por lo que para evitar en la medida de lo posible estas incidencias, el siguiente paso será "Publicar rama".  Es decir, subir nuestra "Rama" a la nube.  Obviamente en el caso de trabajar con otros desarrolladores, también subiríamos nuestro código al cloud para poder compartir nuestros cambios con ellos.

Por defecto, al inicializar nuestro repositorio, se ha creado una rama "master".  Sería como la rama inicial de nuestro código.  Lo podemos ver en la parte inferior de VSCode:

Cuando la rama que aparece allí, tenga un asterisco (*), significa que tenemos cambios pendientes de guardar en el repositorio local.  En caso de no tenerlo, significa que todos los cambios están almacenados.

Lo siguiente que debemos hacer es añadir a nuestro repositorio local un repositorio remoto.  Es decir, un lugar donde guardaremos los ficheros de forma segura y controlada.  Y como no, ese sitio, en nuestro caso, será DevOps.

Crear un GIT remote al nuevo entorno DevOps

Para poder relacionar nuestros dos repositorios (el local y el remoto) usaremos el comando:

git remote add <shortcut> <url>

donde:

shortcut:  Es el nombre que le damos al almacenamiento remoto.  Recordad que podemos tener varios repositorios remotos vinculados a nuestro repositorio local.

url: La url para localizar el repositorio remoto.  ¿Donde localizamos esta dirección?  Pues directamente en DevOps - Repos, como está vacio, nos da varias opciones para enlazar:

Con VSCode, en lugar de escribir el comando, usaremos la paleta de comandos y el comando "Agregar remoto":

Nos solicitará los dos parámetros:  La dirección que copiaremos de DevOps y el nombre (shortcut) que queramos poner.  Yo le pondré DevOps como nombre.  El comando que ejecuta internamente es:

git remote add DevOps https://aprendeBC@dev.azure.com/aprendeBC/Prueba01/_git/Prueba01

Una vez vinculados el repositorio remoto y el local, ya podemos guardar o publicar los ficheros en nuestro DevOps en la nube:

Podríamos hacerlo pulsando cualquiera de los dos botones indicados:

O también escribiendo en la línea de comandos:

git push -u DevOps --all

Una vez realizado el proceso, nuestro repositorio local se sincroniza con el repositorio en la nube, donde ahora tendremos los ficheros almacenados:

Cada cambio que hagamos en el directorio de trabajo, procederemos a guardarlos en nuestro repositorio local y luego en la nube (commits), de forma que siempre dispongamos en DevOps de la última versión.

Nos queda mucho por aprender:  crear ramas vinculadas a una tarea o bug, resolver problemas cuando desarrollamos varios programadores, integrar ramas en la rama principal..., pero para que no se nos haga muy largo el post, paramos aquí y seguiremos en el próximo.

Si quieres verlo en acción, te dejo el video en mi canal de YouTube Aprende Business Central en Español.

Cualquier duda, puedes ponerlo en los comentarios.