Tutorial hacer un release de la entrega

Descripción general

En este tutorial vamos a aprender a publicar un release de su proyecto. A lo largo del semestre van a tener que hacer esto varias veces (una por cada entrega), así que es importante que entiendan bien el proceso.

Vamos a ver dos formas de hacerlo:

1. Classroom50: la forma en que se marca oficialmente una entrega para que el sistema de calificación automática la revise.
2. GitHub: la forma “nativa” de publicar una versión de un proyecto en GitHub, usando la sección Releases del repositorio.

Las dos formas parten del mismo lugar: un tag (etiqueta) de git que apunta al commit que quieren entregar. La diferencia está en qué hace cada plataforma con ese tag. En Classroom50, el tag por sí solo dispara la revisión automática. En GitHub, además de crear el tag, ustedes van a convertir ese tag en un objeto Release visible en el repositorio, con su propio título, notas y (si quieren) archivos adjuntos.

Como van a tener varias entregas en el semestre, cada tag debe indicar el número de release al que corresponde, del 1 al 6 (release-1, release-2, …, release-6). En todos los comandos de este tutorial, reemplacen N por el número de la entrega que estén haciendo.

Objetivos de aprendizaje

Al finalizar este tutorial, cada estudiante debe ser capaz de:

1. Publicar una entrega (release) en Classroom50 usando etiquetas (tags) de git numeradas.
2. Crear el release equivalente directamente en GitHub, siguiendo el mismo tag y el mismo criterio de numeración.

Sección A: Hacer el release en Classroom50

Esta es la forma que siempre deben usar para que su entrega quede registrada y calificada.

Paso 1: Verificar que están en la rama correcta

Antes de subir nada, confirmen en qué rama están y que no tengan cambios sin guardar pendientes de revisar:

Ventana de terminal

git status

Si ven archivos en rojo (modificados o sin trackear) que sí deberían ir en la entrega, sigan al paso 2. Si ven archivos que no deberían subir (por ejemplo node_modules o archivos temporales), revisen su .gitignore antes de continuar.

Paso 2: Subir el resultado y entregar

Confirmen los cambios y súbanlos a main:

Ventana de terminal

git add .
git commit -m "Entrega release N"
git push

Entren al repositorio en GitHub y verifiquen que en main estén todos los archivos que la entrega pide (revisen el enunciado de la actividad para saber cuáles son). Si algo falta, corríjanlo y vuelvan a hacer push antes de seguir.

Paso 3: Etiquetar la entrega

La calificación solo se ejecuta cuando marcan la entrega con la etiqueta (tag) correspondiente al número de release. Cuando estén seguros de que main ya tiene la versión final, ejecuten (reemplazando N por el número de la entrega, de 1 a 6):

Ventana de terminal

git fetch origin main && git tag -f release-N origin/main && git push -f origin release-N

Por ejemplo, para la tercera entrega del semestre, el comando sería:

Ventana de terminal

git fetch origin main && git tag -f release-3 origin/main && git push -f origin release-3

Pueden repetir ese comando las veces que quieran antes de la fecha límite: la opción -f mueve la etiqueta al último estado de main y vuelve a lanzar la revisión. Cuenta la última ejecución antes del cierre.

¿Por qué usamos -f?

-f (force) le indica a git que, si la etiqueta release-N ya existe (por ejemplo porque la crearon antes con una versión anterior de su código), la mueva para que apunte al nuevo commit en lugar de fallar con un error. Esto es justamente lo que necesitan cuando corrigen algo y quieren volver a marcar la entrega.

Paso 4: Verificar la ejecución

En GitHub, entren a la pestaña Actions del repositorio y confirmen que la ejecución disparada por la etiqueta release-N haya terminado (idealmente en verde). También pueden revisar en classroom50.org que la entrega haya sido registrada.

Si la ejecución falla o no aparece, revisen que el tag realmente se haya subido con el comando del paso 3 (pueden confirmarlo con git ls-remote --tags origin desde su terminal).

Sección B: Hacer el release directamente en GitHub

Esta sección no reemplaza la Sección A: para que la entrega se califique, siempre tienen que hacer el proceso de Classroom50. Pero es útil saber cómo se hace un release “de verdad” en GitHub, porque es lo que van a usar en proyectos reales para marcar versiones publicadas (v1.0, v1.1, etc.) y porque, como ya subieron el tag en la Sección A, convertirlo en un Release de GitHub toma solo un par de pasos adicionales.

Paso 1: Verificar que están en la rama correcta

Igual que en la Sección A: confirmen que no les falten cambios por subir.

Ventana de terminal

git status

Paso 2: Subir el resultado a main

Si ya hicieron el Paso 2 de la Sección A, pueden saltarse este paso: el tag de GitHub se va a crear sobre el mismo main que ya subieron. Si no, súbanlo ahora:

Ventana de terminal

git add .
git commit -m "Entrega release N"
git push

Paso 3: Crear el release en GitHub

Aquí es donde cambia el proceso. En vez de solo mover un tag por línea de comandos, van a crear un objeto Release en GitHub, que queda visible en la pestaña Releases del repositorio con su propio título y notas.

Hay dos formas de hacerlo, elijan la que les resulte más cómoda.

Opción 1: desde la página de GitHub

1. Entren al repositorio en GitHub y hagan clic en Releases (en la barra lateral derecha, o en github.com/su-usuario/su-repo/releases).
2. Hagan clic en Draft a new release.
3. En el campo Choose a tag, escriban release-N (reemplazando N por el número de la entrega) y elijan la opción Create new tag: release-N on publish. Si ya crearon el tag en la Sección A, GitHub lo va a reconocer y solo tienen que seleccionarlo de la lista.
4. Confirmen que el Target sea main.
5. En Release title, escriban algo como Release N.
6. Hagan clic en Generate release notes para que GitHub arme automáticamente la descripción a partir de los commits desde el release anterior (si es su primer release, va a listar todos los commits).
7. Si necesitan adjuntar algún archivo (por ejemplo un .zip con un build, o un reporte), arrástrenlo al final del formulario.
8. Hagan clic en Publish release.

Opción 2: desde la terminal, con gh (GitHub CLI)

Si tienen instalado gh y ya iniciaron sesión (gh auth login), pueden hacer lo mismo con un solo comando:

Ventana de terminal

gh release create release-N --target main --title "Release N" --generate-notes

Por ejemplo, para la tercera entrega:

Ventana de terminal

gh release create release-3 --target main --title "Release 3" --generate-notes

Deberían ver algo similar a esto:

estudiante@ism-vm:~/modulo/bookstore-front-new$ gh release create release-3 --target main --title "Release 3" --generate-notes
✓ Created tag release-3
✓ Release created
https://github.com/su-usuario/su-repo/releases/tag/release-3

Este comando crea el tag release-3 (si no existía) y el release en un solo paso.

Paso 4: Verificar que el release quedó publicado

Entren a la pestaña Releases del repositorio y confirmen que release-N aparece publicado, con el título y las notas que esperaban. Si el repositorio tiene un workflow de GitHub Actions configurado para correr cuando se publica un release (evento release: published), revisen también la pestaña Actions para confirmar que esa ejecución haya terminado bien.

Consideraciones finales

Fíjense que ambos procesos comparten el mismo tag (release-N): eso no es casualidad. Pueden hacer primero el proceso de Classroom50 (Sección A) para que su entrega quede calificada, y luego, sobre ese mismo tag, crear el Release de GitHub (Sección B) sin tener que repetir el push ni volver a etiquetar nada.

La diferencia clave para recordar es que Classroom50 solo necesita el tag —no le importa si existe un Release “bonito” en GitHub o no— mientras que un Release de GitHub es un objeto adicional, con notas y archivos, pensado para que cualquier persona que visite el repositorio entienda qué cambió en cada versión. En proyectos reales fuera del curso, van a usar el segundo proceso constantemente; el primero es específico de la forma en que se califica este curso.