Automatizar la construcción de imágenes Docker con GitHub Actions transforma tu flujo de trabajo DevOps en un proceso continuo y sin fricciones. Aquí aprendes a configurar un pipeline de integración continua que ejecuta el build de tu imagen de forma remota cada vez que fusionas cambios a la rama principal, ideal si trabajas con .NET y quieres profesionalizar tus despliegues.

Qué hacer después de fusionar tu pull request con Docker

Después de fusionar el pull request que añade Docker al proyecto, el siguiente paso lógico es crear una tarea nueva para sumar el flujo de integración continua. En el tablero del proyecto de DevOps, la tarea anterior aparece terminada y se abre una nueva: agregar CI para imágenes de Docker, registrada como el issue número 10.

Esta organización por issues es lo que mantiene la trazabilidad. Cada cambio en el repositorio responde a una tarea concreta, y cada pull request cierra ese issue automáticamente cuando se fusiona.

¿Qué es un pull request en GitHub? Es una propuesta de cambios al repositorio que permite revisión antes de fusionar. Documenta qué se modificó, quién lo revisa y qué issue cierra.

Cómo crear un workflow de GitHub Actions para Docker

Dentro de la pestaña Actions del repositorio ya existe un action previo de run test. Para el nuevo flujo, eliges crear un workflow desde cero y, en lugar del clásico main.yaml, lo nombras container_deployment.yaml. Ese nombre describe con precisión su propósito: desplegar contenedores.

El contenido del archivo viene del bloque preparado en Visual Studio Code, dentro de la carpeta clase 10. Lo copias y lo pegas directamente en el editor de GitHub.

Qué configura el archivo container_deployment.yaml

El action se llama API contactos CI/CD y define varios elementos clave:

• Se ejecuta solo en la rama principal, evitando builds innecesarios en ramas de trabajo.
• Define como image base name el valor aminspinoza-api-contactos, el mismo nombre que se usó al desplegar la imagen local.
• Corre sobre Ubuntu como sistema operativo del runner.
• Apunta al working directory src/contactos-api, donde vive el código fuente.

El working directory es lo que reemplaza la necesidad de moverte manualmente con comandos de Bash. GitHub Actions se posiciona automáticamente en esa carpeta antes de ejecutar los pasos.

Qué pasos ejecuta el pipeline de integración continua

Los pasos del workflow siguen una secuencia clara:

1. Checkout del repositorio para obtener el código.
2. Listar archivos para confirmar la ubicación correcta.
3. Ejecutar build docker net image, que construye la imagen Docker en el entorno remoto.

Es el mismo comando que se corrió en local, pero ahora orquestado por GitHub en cada fusión a main.

Cómo fusionar el pull request y verificar el despliegue automatizado

Una vez guardado el archivo, creas una rama nueva llamada aminespinoza/10, donde el número coincide con el issue asociado. El commit message es simplemente create, y propones los cambios para abrirlos como pull request.

Copilot ayuda a redactar el resumen del pull request, y tú solo añades closes #10 para vincularlo al issue. Asignas a Oscar como reviewer y a ti mismo como responsable.

¿Qué hace closes #10 en un pull request? Vincula el pull request al issue número 10. Cuando se fusiona, GitHub cierra automáticamente ese issue sin intervención manual.

Por qué los checks verdes confirman el éxito del CI/CD

Después de la aprobación de Oscar, los checks pasan en verde. Confirmas la fusión, eliminas la rama y vas corriendo a la pestaña Actions. Ahí aparece el action API contactos CI/CD ejecutándose en tiempo real.

El proceso construye la imagen .NET y completa los primeros pasos del flujo de integración continua dentro de la etapa de release. Todo termina en verde sin que tengas que tocar nada más después de la fusión.

¿Cuándo se ejecuta el CI/CD en GitHub Actions? Solo al fusionar cambios a la rama principal. Esa es la condición definida en el workflow, lo que evita ejecuciones innecesarias en ramas secundarias.

Qué ganas al automatizar el build de Docker en la nube

La diferencia con el modo local es enorme. Antes ejecutabas el comando manualmente desde tu máquina; ahora el runner de Ubuntu lo hace por ti cada vez que apruebas un pull request. Tu tarea dentro del proyecto se marca como terminada y la ejecución queda registrada de forma automatizada.

Esta es la esencia de DevOps aplicado: tareas vinculadas a issues, pull requests documentados con ayuda de Copilot, revisiones humanas y pipelines que se disparan solos. Cuéntame en los comentarios qué herramienta vas a sumar tú a tu próximo workflow.