Cuando trabajas con metodologías ágiles y descubres que falta una pieza técnica, como un Dockerfile para crear la imagen de tu proyecto .NET, lo correcto es registrar ese trabajo como un nuevo issue dentro del sprint. Así mantienes la trazabilidad, evitas duplicar esfuerzos con tu equipo y documentas tu progreso real.

Por qué debes crear un issue antes de programar?

Antes de tocar código, abre el issue en tu repositorio. Esa es la regla que sostiene el trabajo colaborativo y el seguimiento del backlog.

Hay una distinción clave que debes entender: no puedes agregar funcionalidades nuevas a mitad del sprint, porque esas ya estaban planeadas desde el inicio. Pero sí puedes crear tareas nuevas cuando descubres detalles técnicos que omitiste al desglosar tus issues. El Dockerfile es un ejemplo perfecto de esto.

¿Qué pasa si trabajo sin crear un issue? Tu equipo no sabe en qué estás, no puedes registrar progreso en el proyecto y arriesgas chocar con el trabajo de alguien más. En la práctica, es como si no hubieras hecho nada.

En la demostración [02:10] se crea un blank issue llamado "Agregar imagen de Docker", se mueve a In progress y se toma su número, en este caso el ocho, para nombrar la rama de trabajo.

Cómo configurar el Dockerfile para una API en .NET 8?

Con el issue creado, el siguiente paso es crear una rama dedicada con la convención amin-es/8 y dentro de la carpeta src/ContactosApi agregar el archivo Dockerfile.

El archivo debe apuntar al SDK 8, referenciar correctamente el proyecto ContactosApi (respetando mayúsculas y minúsculas), restaurar dependencias, compilar y publicar la DLL final que ejecutará el contenedor.

• Verifica que el nombre del proyecto en el Dockerfile coincida exactamente con el del .csproj.
• Asegúrate de tener Docker Desktop ejecutándose antes de compilar.
• Posiciónate con cd en la carpeta donde vive el Dockerfile antes de correr el build.

Un detalle que suele tropezar a muchos: confundir ApiContactos con ContactosApi. La consistencia en los nombres no es estética, es funcional. Si te equivocas, el build falla.

Cómo construir y correr la imagen de Docker localmente?

Desde la terminal, ya posicionado en src/ContactosApi, ejecutas el comando de construcción y luego corres la imagen para validar que todo levante.

bash docker build -t aminespinosa/contactosapi . docker images docker run -it --rm --name apicontactos -p 8080:8080 aminespinosa/contactosapi

El primer comando empaqueta la aplicación con el tag aminespinosa/contactosapi. El segundo lista las imágenes disponibles para confirmar que se creó. El tercero la ejecuta exponiendo el puerto 8080 [05:30].

¿Por qué probar la imagen en local antes de subirla? Porque si funciona en tu máquina, hay altísima probabilidad de que la GitHub Action la compile sin errores. El entorno local es tu primer ambiente de validación.

Por qué Swagger no aparece al ejecutar el contenedor?

Al abrir localhost:8080/swagger después del primer run, la pantalla aparece vacía. La causa está en Program.cs: Swagger está envuelto en un if que solo lo activa en modo desarrollo.

Docker no corre tu aplicación en modo desarrollo, así que necesitas quitar esa condicional para que la plantilla de Swagger se exponga siempre. Tras eliminar el if, vuelves a ejecutar docker build y docker run con el mismo tag.

Ahora sí, al visitar localhost:8080/swagger/index.html aparece la documentación interactiva de la API.

¿Qué hace el flag --rm en docker run? Elimina automáticamente el contenedor cuando lo detienes, manteniendo limpio tu entorno local sin contenedores fantasma acumulados.

Qué sigue después de tener la imagen funcionando?

Con el contenedor corriendo y Swagger respondiendo, tienes todo lo necesario para abrir un pull request que cierre el issue número ocho.

El flujo completo queda así:

1. Detectas el trabajo faltante y creas el issue en el backlog.
2. Generas la rama con la convención del equipo (amin-es/8).
3. Implementas el Dockerfile y validas localmente con build y run.
4. Ajustas el código necesario, como liberar Swagger del modo desarrollo.
5. Subes los cambios y abres el pull request para revisión.

Este hábito de trabajar siempre desde un issue registrado es lo que diferencia a un colaborador que aporta valor visible al equipo de uno que se pierde en el ruido. Cuéntame en los comentarios: ¿en tu equipo registran cada tarea o todavía hay quien programa fuera del backlog?