Python. Project Structure (V)

#python #ci #cd #docker

Índice:

Sección A. Estructurar un proyecto: apartado I, apartado II, apartado III, apartado IV, apartado V, apartado VI, apartado VII, apartado VIII.

Vamos a realizar nuestra primera aprobación de fusionado de una rama. Aunque haremos tanto la petición como la aprobación, hay que tener en cuenta que en un equipo serán distintos integrantes quienes realicen cada una de las acciones, ya que no solo es poner un filtro para evitar que alguien introduzca código no deseado, sino también para revisar si el trabajo realizado es correcto o merece ser revisado nuevamente.

Subir los cambios y hacer la petición de fusionado (Merge Request)

Lo primero es subir la nueva rama:

git add .
git commit -m 'Añadida interfaz web con NiceGUI'
git push -u origin 'release/000-nicegui'

Ahora vamos a Gitlab, visualizamos la pantalla principal del repositorio y veremos que nos ha aparecido la posibilidad de hacer un Merge Request. También podemos acceder a través de Pinned o Code.

Pulsamos el botón Create merge request y veremos que nos aparece New merge request.

Primero debemos cerciorarnos de qué rama se fusiona con cual: verificamos que en Source branch tenemos la rama de 'release' y en Target branch la rama 'main', si no es correcto pulsamos Change branches y lo corregimos.
Después pulsamos Compare branches and continue.

Para continuar debemos indicar qué tipo de MR será:

En este caso el MR será definitivo, por lo que desmarcaremos 'Mark as draft' si estuviera marcado.
Actualizamos el título. La visibilidad del texto que pongamos aquí dependerá de si hacemos un 'Squash commits' o no: si hacemos un 'Squash' se verá solo este título y todo el contenido de la rama se verá fusionado en este único commit; si no hacemos 'Squash' no se verá este título ya que serán los commits individuales de la rama los que se verán reflejados en la fusión.
Actualizamos la descripción.
Asignamos el encargado de aprobarlo en el desplegable Assignee.
Establecemos un revisor en el desplegable Reviewer.
Indicamos el Milestone y cualquier Labels que necesitemos.

Las dos siguientes opciones son verdaderamente importantes para el flujo de trabajo en equipo:

Merge can start nos permite desplazar el MR a un momento posterior para mejorar el flujo de trabajo del equipo, en caso contrario lo dejamos con 'Anytime'.
En Merge options podemos activar:
- 'Delete source [...]' para borrar la rama 'release' después del fusionado con 'main'.
- 'Squash commits [...]' para que en la rama de destino solo se vea el título del merge, de tal forma que los commits solo quedan referenciados en la rama de origen. Si hemos aceptado borrar la rama intermedia también nos desapareceran del histórico las referencias a los commits de dicha rama.

Pulsamos Create merge request y pasamos al siguiente paso.

Resolver una petición de un Merge Request

Como decíamos, este paso de aprobación debería hacerlo otra persona del equipo.

En este paso realizaremos lo siguiente:

Marcar con un icono la percepción del MR (te gusta, no te gusta, ...).
Ver el estado del pipeline, el cual debe terminar en verde para poder ser fusionado (si lo hubiere).
Pulsar Approve para aceptarlo.
Confirmar, si procede, Delete source branch, Squash commits y realizar un Edit commit message. Si realizamos un 'Edit' tenemos la posibilidad de cambiar el mensaje, con lo que el título del último commit será la primera línea del comentario; teniendo en cuenta que puede afectar al pipeline (añadiendo un tag podemos hacer que se lance una tarea adicional).
Pulsar Merge para completar el fusionado, tras lo cual volverá a lanzarse el pipeline.

Por último, existe la opción de poner un comentario adicional en el apartado Activity.

Tras la finalización de un Merge Request

Una vez fusionado un MR, nuestra rama local de 'main' tendrá nuevos commits, por lo que es fundamental que quien vaya a continuar trabajando se actualice la rama principal:

git checkout main
git pull

Apuntes

En Gitlab hablamos de Merge Request, sin embargo, en GitHub se llaman Pull Request. Como ves, cada plataforma tiene sus nomenclaturas.

En cuanto a las buenas prácticas, podemos nombrar unas cuantas sobre los MR/PR:

Mantener peticiones de MR/PR lo más pequeñas posible. Cada línea de código será revisada por un compañero.
Describir con claridad qué se ha hecho y el porqué de los cambios. Es importante que quien lo revise sea consciente del resultado que queremos obtener.
Revisa tu código antes de hacer una petición de MR/PR.
El equipo puede utilizar pre-commit hooks para normalizar ciertas acciones.
Como equipo, es preferible tomarse como rutina la revisión de código en equipo (Code Review) para estar al corriente y verificar que se está yendo por el camino apropiado.
Utilizar squash commit solo cuando son pocos commit, ya que en una densa maraña de commit y mucho código perderíamos la capacidad de revisión de forma práctica y rápida.