Git GitHub Actions, Buenas Prácticas de Integración Continua

Antes de iniciar es importante tener presente que dentro del ámbito de DevOps existen multiples definiciones con la palabra continua y para evitar confusiones te voy a aclarar la diferencia entre las dos principales , Integración continua y Entrega continua.

Vamos a definir que es integración continua y cuales son sus principales beneficios.

Para implementar la integración continua lo primero que necesitamos es escoger una suite o plataforma en la cual vamos a automatizar los procesos y logicamente definir un flujo de trabajo claro y coherente para todos los implicados en el proceso de integración continua.

Si quieres tener éxito trabajando con Git, primero debes comprender sus conceptos fundamentales, cual es su estructura interna, su arquitectura descentralizada y sobretodo como gestiona los archivos para mantener múltiples versiones.

Se explica en detalle en que consiste una nueva versión del repositorio representada por un commit y como gestiona git su base de datos.

Se explican las tres secciones principales de un proyecto de Git: El directorio de Git (Git directory), el directorio de trabajo (working directory), y el área de preparación (staging area), Donde se ubican los archivos gestionados por git segun van cambiando de estado confirmado (committed), modificado (modified), y preparado (staged).

Es importante conocer los principales conceptos de uso cotidiano en git como commit, master, main, branch, tag, refs, ref, origin y HEAD para poder trabajar como parte de un equipo en un repositorio compartido y evitar conflictos.

Git flow y trunk based son las dos principales metodologías para gestionar repositorios compartidos, analizamos sus pro y sus contras y explicamos su estructura.

Lo más habitual es que al momento de incorporarte a un equipo inicies por clonar un repositorio existente, aquí te enseño como hacerlo y sobre todo como identificar sus ramas y como empezar a trabajar.

Los mensajes de commit deben ser útiles y seguir un entandar acordado por el equipo, te enseño de manera practica como hacerlo.

Te enseño como moverte por las ramas, haciendo checkouts a comits específicos y regresando al HEAD sin causar problemas en tu repositorio.

Los cambios de todos los des arrolladores deben ser integrados en una rama común de integración (normalmente develop) y deben pasar por un proceso de revisión para su aprobación y rechazo según corresponda, esto normalmente se conoce como pull request o solicitud de integración , aquí te enseño todo el proceso sobre pull request.

Independientemente de la metodología se debe seguir un flujo común para contribuir en un repositorio de código y evitar los conflictos para evitar perdidas de tiempo innecesarias, aquí te explico cual es esa secuencia de pasos recomendada.

Te enseño como crear un workespace de trabajo alternativo para incluir un nuevo desarrollador al equipo, poner el practica el flujo correcto de la metodología y simular conflictos.

Una vez se presenta un conflicto lo ideal es resolverlo usando las herramientas que nos ofrece git y las extensiones de los IDEs pensadas para tal fin, aquí te enseño como resolver de manera correcta un conflicto.

Los TAG sirven para marcar momentos importantes en el repositorio(hitos) como salidas a producción, cambio de responsable de un repositorio por ejemplo, en esta clase vamos a crear un tag que apunte al primer commit que hemos hecho.

Un merge normalmente combina los cambios de una rama en otra y existen dos técnicas para hacerlos con fast-forwar o no-fast-forward, te explico el concepto y como es en la practica.

Con la opción --no-fast-forward lo que hacemos es crear un nuevo commit que nos representa la combinación de las dos ramas.

El numero y nombre de las ramas , así como su ciclo de vida, varían en dependencia de la metodología que se escoja,  pero también existen algunas buenas practicas generales independientes de la metodología de flujo de trabajo que te recomiendo en base a la experiencia y las buena practicas.

La rama por defecto se debe elegir en base a las necesidades practicas del equipo y teniendo en cuenta que ayude a agilizar el trabajo, también te explico como eliminar de menara automática las ramas de ciclo de vida corto o ramas temporales (ramas feature)

Un push directo a una rama principal como main, master o develop, podría generar serios problemas que podrían poner el equipo en apuros, aquí hacemos una demostración de como se da este caso las implicaciones que puede tener.

En los equipos siempre va a existir quien desea saltarse las normas o se olvida de las bueans practicas, en esta clase te enseño como forzar a que se cumplan las buenas practicas y establecer políticas correctas para la integración y proteger tus ramas principales.

En determinado momentos nos podemos encontrar con que es necesario descartar un cambio especifico del repositorio sin perder cambios posteriores, la buena practica es hacer un git revert.

Si por alguna razón de peso es necesario regresar a un punto especifico del historia del repositorio y convertirlo en el head, bien sea para descartar una serie de cambios o hacer un rollbak , es necesario hacer un hard reset en el repositorio local y confirmarlo al repositorio remote, aquí te enseño como hacerlo.

Te enseño que es, como y para que usar un stash como memoria temporal de un repositorio de git en tu local, como modificar o emendar un commit y como resetar tu repositorio local a lo ultimo en el repositorio remoto.

En muchos casos puede ser necesario tener un repositorio dentro de la compañía que sea una copia y se sincronice con un repositorio de un cliente final sin perder el historial de cambios, para eso usamos los múltiples orígenes remotos.

Se explican otros comando útiles sobre el manejo de repositorios remotos y se explica como visualizar los principales comando de git, entregados en formato markdown.

Se explica las principales buenas practicas para trabajar de manera colaborativa con git.

Se explican técnicas y estándares como semver, calver y shaver para el versionado de objetos.

Github Actions es una suite de integración continua que nos ofrece github y que cuenta con multiples aplicaciones personalizadas para llevar a cabo tareas repetitivas y comunes sobre los repositorios y la integración continua en general.

Para comprender de una manera más sencilla como trabaja la suite de github Actions en esta clase se crea un workflow sencillo para compilar el código de una aplicación de java con maven mediante la consola de administración de github.

Lo mejor para aprender a trabajar con una suite en particular es comprender los principales conceptos y como funcionan todos de manera conjunta.

Antes de avanzar te explico como podrías crear workflows de una manera más ágil usando la asistencia de la inteligencia artificial con las extensiones de copilot y chatgpt

Todas las actions se publican en el merketplace de github actions para que puedan se utilizadas por los repositorios de git, existen miles de actions y lo mas importante es saber como buscarlas e identificar las que mas nos conviene para nuestros workflows.

Es común que los workflows puedan presentar errores en su ejecución, por este motivo debes aprender a identificar y corregir los errores haciendo uso del log que nos ofrece github actions.

Lo pull request deben ser solicitados en el momento adecuado para evitar conflictos y no es una buena practica automatizar la solicitud de pull request, aquí te explico el porque y repasamos de manera gráfica el workflow que se ha creado.

Se repasan los conceptos del flojo de trabajo con github y se alinean las ramas del repositorio.

La clave par escribir workflows útiles pasa por hacer un buen diseño y planificar de manera correcta las tareas a automatizar, aquí vamos ha hacer el pipeline de integración continua que luego dividiremos en múltiples workflows.

Se explica como iniciar un workflow en un evento de pull request sobre ramas especificas y como descargar el código de la rama que dispara el pull request.

En esta clase se incluye un segundo job al workflow de para realizar las tareas de merge automático de la rama feature en la rama por defecto y se explican otros conceptos relevantes de los workflows como variables, expresiones y aspectos de seguridad.

Se explica en detalle el job y las actions para realizar un merge automático de una rama origen en una rama destino.

Es común que necesitemos invocar la ejecución de un workflow desde otro workflow anterior y en algunos casos enviar parámetros entre los workflows, en esta clase te explico como hacerlo.

Los recursos adicionales al código fuente como librerías, módulos y datos sensibles no deben se incluidos en el repositorio de código, para ello debe hacerse uso del fichero .gitignore para excluirlos y de los secrets para almacenar contraseñas.

Con el objetivo de poder empaquetar la aplicación para distribuirla de una manera más standard y eficiente se hace uso de las imágenes de docker y de github packages para publicarlas.

Se crea un workflow para publicar imágenes de docker en el modulo de github packages, en esta primera clase se enseña como descargar el artefacto del workflow anterior para usarlo y empaquetarlo en una imágen.

Se define un nuevo job cont odas las actions necesarias para construir y publicar una imagen de docker en github packages, y se explica como procesar los parámetros desde la action a la imagen de docker.

Se enseña como guardar datos sensibles en github secretes y como utilizarlos tanto en los workflows como en las imagenes de docker y finalmente en las aplicaciones.

Se comentan los posibles errores que se pueden encontrar y cual debe ser el proceso correcto para abordarlos.

Se hace una ejecución y comprobación de todos los workflows del pipeline de CI y se evidencia como se publica la imagen de docker en Github packages.