Python. Project Structure (VII)

#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.

Como hemos comentado en anteriormente, hemos cometido un par de errores en los archivos Dockerfile.

Ahora debemos corregirlo, pero, queremos hacerlo en la rama correspondiente y llevar los cambios a main.

¿Qué ocurre si no estamos en un estado 'limpio'?

Antes de continuar, como es habitual, debes estar sin ningún cambio en el repositorio: nunca debes empezar a trabajar teniendo código a medias, en ninguna rama.

Si estás trabajando y surge una urgencia que te obliga a dejar a medias un trabajo, tienes varias opciones:

Guardar el trabajo para continuar después sin ensuciar el histórico. Esta es la mejor opción.
Descartar lo trabajado.
Crear un commit (indicando claramente que el trabajo no está terminado). Esto es una mala opción.

Veamos la opción 1, cómo guardar el trabajo sin hacer commit:

git add .
git stash

Esto realiza un 'commit interno' que no existe en el histórico de las ramas.

Para consultar los commit internos que tienes en stash:

git stash list

Para recuperar el último commit interno que tienes en el stash:

git stash apply

Hay más opciones muy interesantes, revisa la documentación de git.

Sincronizar la copia local

Sabiendo que no tenemos código a medias, lo primero es tener actualizadas las ramas involucradas.

Nos situamos en main y la actualizamos:

git checkout main
git pull

Nos situamos en release/000-virtualization y la actualizamos:

git checkout 'release/000-virtualization'
git pull

Realizar los cambios y hacer el commit

Ahora realizaremos las correcciones de los errores que cometimos.

En el archivo Dockerfile:

Busca APP_FOLDER y sustituyelo por APP_PATH.

En el archivo Dockerfile.windows:

Busca APP_FOLDER y sustituyelo por APP_PATH.
Busca APP_VIRTUALIZATION y sustituyelo por APP_ENV.

Ahora realizamos el commit:

git add .
git commit -m 'Correcciones en los archivos Dockerfile'

Preparar la rama y subir los cambios

Primero nos traemos la rama main a la nuestra:

git merge main

Si existe algún conflicto git te lo avisará. Si esto ocurre tendrás que resolverlo, y hacer un nuevo commit.

Ahora debemos subir los cambios a origin:

git push origin 'release/000-virtualization'

Te estarás preguntando porqué hicimos el merge después de hacer los cambios y el commit. La explicación es sencilla: queremos tener en nuestra rama lo último que entró en main porque después debemos realizar el merge request y para que no haya problemas añadidos deberíamos tener lo último. Por ello, cuanto más tiempo pasa entre tu merge de main y tu push a origin , más posibilidades de que no sea lo último. Yo personalmente hago un merge antes de empezar y otro después, lo cual me garantiza trabajar sobre lo último y asegurarme que es lo último con lo que hago la petición de MR.

Crear el Merge Request

Esta parte ya sabes como funciona, lo vimos en un artículo anterior. Haz el MR y después descárgate a main los cambios.

Apuntes

Merge vs Rebase

En git hay una regla de oro: nunca hagas un rebase en ramas compartidas o públicas.

Estas son las razones:

Preservación del historial (acción no destructiva): con git merge preservamos el historial de forma cronológica y real.
Seguridad en el trabajo en equipo: la utilización de git merge no reescribe los commit por lo que es fácil llevar un seguimiento rápido y limpio. Sin embargo, el uso de git rebase reescribe el historial de la rama, por lo que en cualquier otro clonado existente del repositorio los ID's de los commits serán diferentes, provocando en el resto del equipo un considerable costo de tiempo revisando lo ocurrido.
Claridad en las auditorías de código: cuando utilizamos git merge, la utilización de herramientas como git bisect se facilita enormemente al mostrar exactamente qué ocurrió y cuando.