Avanzar en un proyecto DevOps con GitHub exige disciplina con los detalles: registrar tareas, mover issues entre columnas y mantener el repositorio limpio. Aquí verás cómo pasar una tarea de ready a done, crear un proyecto de API en .NET y subir tu primer commit sin romper la metodología.

Por qué los detalles definen tu metodología DevOps

La metodología DevOps se sostiene en hábitos pequeños que, si los descuidas, se convierten en deuda técnica. Guardar tareas, crear issues y mover tarjetas en el panel parece trivial, pero abandonar esos pasos diluye los beneficios del flujo.

Antes de avanzar conviene que tengas tus tareas cargadas en el proyecto. Si no lo has hecho, pausa, súbelas y regresa. Solo así el panel de control reflejará el estado real del trabajo.

¿Qué pasa si no actualizo mis issues en DevOps? Pierdes trazabilidad. La metodología depende de que cada tarea tenga estado visible (ready, in progress, done) para que el equipo y tú mismo sepan en qué enfocarse.

Cómo mover una tarea de ready a in progress en GitHub Projects

El panel de GitHub Projects organiza el trabajo en columnas. Cuando una tarea ya tiene definición clara, pasa a ready. En el ejemplo había dos tareas listas: crear un método para agregar contactos y crear el proyecto de API con .NET.

El flujo correcto al iniciar el día es directo:

• Identificar la tarea prioritaria en ready.
• Moverla a in progress para señalar foco.
• Abrir el detalle del issue y autoasignártelo.
• Confirmar que la iteración esté configurada.

Cuando autoasignas el issue, GitHub registra responsabilidad. Eso elimina la ambigüedad sobre quién está tocando ese código en ese momento.

Cómo se vinculan los issues con el repositorio

Los issues creados en el proyecto aparecen también dentro del repositorio asociado. En el ejemplo, el issue número seis, crear el proyecto de API con .NET, ya estaba señalado con su assignee visible. Esa visibilidad cruzada entre proyecto y repositorio es lo que mantiene la coherencia del tablero.

Cómo crear un proyecto de API con .NET y estructurarlo bien

Con la tarea en progreso, el siguiente paso es crear el proyecto. Desde la terminal, dentro del repositorio, el comando inicial es dotnet new webapi -n contactosapi. Aquí se eligió C# con .NET por preferencia, pero el mismo flujo aplica con TypeScript, Go o PHP.

El primer intento mostró un error común: crear el proyecto directamente en la raíz del repositorio. La corrección fue eliminarlo con rm -rf contactosapi y rehacerlo dentro de una carpeta src, que es la convención para source code.

El orden quedó así:

1. Crear la carpeta con mkdir src.
2. Entrar a esa carpeta.
3. Ejecutar dotnet new webapi -n contactosapi.
4. Volver al nivel raíz y abrir el editor con code ..

¿Por qué usar una carpeta src en lugar de la raíz? Porque separa el código fuente de archivos de configuración, infraestructura y documentación. Mantiene el repositorio escalable cuando se sumen más servicios.

Para verificar que todo compila, dentro de contactosapi se ejecuta dotnet build. Si la compilación pasa, el proyecto está listo para versionarse.

Cómo configurar gitignore para subir solo lo esencial

El archivo .gitignore decide qué se sube al repositorio y qué no. En el ejemplo era un archivo personalizado que excluía:

• Las carpetas bin y obj generadas por .NET al compilar.
• Los archivos de compilación de Terraform, que se usarán más adelante para infraestructura.

Cuando .gitignore está bien configurado, las carpetas excluidas aparecen en gris dentro del editor. Esa señal visual confirma que no viajarán al repositorio remoto.

Cómo hacer el primer commit y sincronizar cambios

Con el proyecto compilando y el .gitignore correcto, el flujo de versionado es:

• Abrir el panel de control de versiones en Visual Studio Code.
• Escribir un mensaje breve, por ejemplo primer commit.
• Ejecutar el commit.
• Sincronizar e ingresar la frase del SSH cuando la pida.

El mensaje no necesita ser extenso en este punto inicial, pero sí descriptivo conforme el proyecto crezca.

Cómo cerrar un issue manualmente y por qué no es lo ideal

Una vez que los cambios están en el repositorio, el issue asociado debe cerrarse. La forma rápida es entrar al issue y darle close issue. Al hacerlo, el proyecto detecta el cambio y mueve la tarjeta automáticamente de in progress a done.

En el ejemplo, la tarea curso DevOps número seis, crear proyecto de API quedó marcada como done sin intervención adicional en el tablero.

¿Está bien cerrar issues manualmente en GitHub? Funciona, pero no es la mejor práctica. Lo recomendable es que el commit o pull request cierre el issue automáticamente mediante referencias como closes #6.

Esa diferencia entre cerrar a mano y cerrar por referencia es justo lo que separa un flujo DevOps básico de uno refinado. ¿Cómo crees que cambia tu trazabilidad cuando cada commit documenta qué issue resuelve? Cuéntame en los comentarios cómo gestionas tus tareas hoy.