En el post anterior vimos como controlar el código fuente de nuestra extensión de Business Central, mediante VSCode y DevOps, lo que nos permitía tener copias de seguridad en un repositorio en la nube o volver para atrás en el caso de que nuestra modificación deje de funcionar correctamente.
Pero, ¿que ocurre si trabajamos varios programadores en diferentes errores y/o nuevas características de nuestro software? Desarrollaremos a diferentes velocidades en función de la complejidad. Entonces, ¿como conseguimos subir nuestras soluciones a producción adecuadamente? La solución es el uso de Ramas (Branch).
MASTER: La rama principal
Por defecto, cuando se crea un repositorio, DevOps (o más bien GIT) crea una rama Master. Esta será nuestra rama principal y que debería de ser la que tenemos en producción. Cuando necesitamos hacer una modificación por errores o mejoras, lo que hacemos es una rama, que sería "como una copia" de la rama master (realmente es un puntero que apunta a un commit determinado). Cuando tengamos la rama con el error solucionado, lo que tenemos que hacer es combinarla con la rama master, ya que puede ser que otros programadores hubiesen realizado allí cambios y por tanto, ya no corresponda a la misma copia que teníamos nosotros.
Estas ramificaciones hacen que los procesos de mejora continúa del software sean mucho más eficientes con Azure DevOps.
Comandos GIT para la gestión de ramas
Para empezar veremos los comandos GIT para el uso de las ramas, aunque luego veremos que DevOps y VSCode con su entorno gráfico nos evita tener que conocerlos.
git status Nos muestra en que rama estamos trabajando.
git branch Nos muestra las ramas que tenemos en el repositorio local
git branch <branchname> Nos permite crear una rama, basándonos en el puntero en el que estemos trabajando. Es decir, si estamos en la rama master, nos creará una rama sobre master.
Este comando no nos coloca en la nueva rama recien creada, por lo que necesitaríamos ejecutar un nuevo comando:
git checkout <branchname> Este comando nos coloca en la rama indicada en branchname.
Podemos agregar parámetros para que cree la rama y nos coloquemos en ella:
git checkout -b <branchname>
El siguiente gráfico muestra una rama Master con tres commits. En el último, decidimos hacer una nueva característica. Si ejecutamos el siguiente comando, estaremos desarrollando sobre la "copia" llamada "caracteristica-23":
git checkout -b caracteristica-23
Una vez realizados los cambios en caracteristica-23 ejecutariamos un commit D, pero la rama master seguiría apuntando al commit C.
Para combinar las modificaciones en la rama master, tendríamos que ejecutar los comandos:
git checkout master (para colocarnos en la rama master)
git merge caracteristica-23 (para combinar las modificaciones en la master)
Una vez que ya hemos combinado las nuevas modificaciones en la master, ya podemos eliminar la rama caracteristica-23, puesto que los cambios ya estarán en la rama principal.
git branch -d caracteristica-23 (borramos la rama caracteristica-23)
Si queremos enviar una rama al repositorio remoto, deberemos usar el comando:
git push -u <remotename> <branchname>
Creando ramas en DevOps
Como he comentado, si usamos DevOps o VSCode, no es necesario conocer estos comandos ya que la interface de usuario hace el trabajo por nosotros.
Podemos crear una rama desde el menú de Azure DevOps, Repos, Branches, New Branch.
Nos pedirá el nombre y la rama de la que queremos partir. Lo habitual será que sea de master:
Usando Boards para crear ramas
Otra de las funcionalidades de DevOps es la creación de tarjetas Boards. En ellas, además de poder crear un registro de las nuevas funcionalidades, errores o modificaciones que creamos conveniente realizar en nuestro proyecto, podemos incluir el usuario al que está asignada esta tarea y desde la misma tarjeta, podemos crear la rama:
Una vez creada, ya podemos ir a VSCode y trabajar sobre ella.
Trabajar sobre una rama remota en VSCode
En el punto anterior hemos creado la rama desde una tarjeta (Board), ahora lo que hacemos es abrir VSCode y empezar a realizar modificaciones sobre ella.
Para eso, pincharemos en la parte inferior izquierda donde tenemos la rama seleccionada. En este momento la "master". Automáticamente se nos abre la barra de comandos para permitir seleccionar las ramas disponibles:
Si acabamos de crear la rama en DevOps, puede ser que todavía no aparezca, por lo que sería conveniente realizar un "refresco" mediante el comando fetch.
La nueva rama (RCB-001) aparecerá como la activa:
Ya podemos empezar a desarrollar nuestra nueva funcionalidad.
La rama aparece con un asterisco indicando que tiene modificaciones y en el control de código, nos aparece la tabla Coches en verde, indicando que es un fichero nuevo.
Ahora ya podemos registrar los cambios (commit) en la nueva rama:
Después haremos una sincronización (push) para subir las modificaciones a la rama remota, con lo que ya nos debe aparecer en DevOps:
Bien, ya tenemos la rama remota guardada, pero la master sigue siendo la misma que había, por lo que tenemos que hacer una combinación para ver como afectan los nuevos cambios a la rama master. El propio DevOps está detectando que deberías de hacer dicha combinación para disponer de los cambios en master:
En la pestaña files, nos indica las diferencias que tenemos:
Cuando pulsamos "Crear" nos revisa si hay algún conflicto a resolver y en el caso de que no los tengamos podemos completar la combinación (Pull request):
El sistema nos indica si queremos borrar la rama, una vez combinada:
Con este proceso, hemos incorporado la nueva tabla a la rama master. Este ha sido un caso muy sencillo, solo con ampliaciones de objetos enteros, pero para ver el funcionamiento es más claro.
Ahora, si creamos una nueva rama RCB-002 basada en la master, ya dispondrá de esas nuevas características:
En el video de esta semana, haremos una nueva rama con modificaciones que debamos combinar para detectar y solucionar incidencias.
Recuerda suscribirte al canal de YouTube para que no te pierdas los nuevos videos que publique:
No hay comentarios:
Publicar un comentario