¿Por qué 🤬 pido a los alumnos que entreguen las tareas en git?

Andrés Hernández - tonejito

Contexto

• Doy clases a los alumnos de Ciencias de la Computación en la Facultad de Ciencias

• Imparto materias de tronco común 😴

  • Sistemas Operativos
  • Redes de Computadoras

• La gran mayoría de mis alumnos quieren ser programadores 💻 y no les interesan tanto mis materias

Contexto

• Allá afuera piden mucho más que algoritmos y estructuras de datos

  • Control de versiones
  • Revisión de código (peer review)
  • Estándares de código
  • Documentación
  • Automatización (CI/CD)
  • Trabajo en equipo y otros soft-skills

Contexto

• Siempre dejamos la documentación “para después” y nunca se escribe
• La documentación no es entregar un documento sin texto que sólo tenga capturas de pantalla
• Los alumnos no están familiarizados con las revisiones de código
  • Tampoco con escribir documentación
  • Y aún así quieren ser programadores
    full-snack 🥨

¿Y por qué no entregamos las tareas en %s?

Entrega de tareas vía correo electrónico

Entrega de tareas vía correo electrónico

• Formato libre (y rebelde)
• No hay control sobre quién envía un correo, a quién va dirigido y el contenido del mensaje
  • Asunto, Para, CC, BCC
  • Responder vs Responder a todos
    • (excepto a los que no)
  • En el archivo adjunto…
    • (pero el correo no tiene archivo adjunto)

Entrega de tareas vía correo electrónico

Entrega de tareas vía correo electrónico

• ¿«Quién» entrega?
• ¿«Qué» está entregando?
• ¿«Cuándo» lo mandó?
• ¿Mandó archivo adjunto?
• ¿Es válida la entrega?
• ¿Entrega individual o en equipo? (CC, BCC)

Entrega de tareas vía correo electrónico

• ¿Qué pasa si hay correcciones?
• ¿Qué pasa si no mandó los archivos adjuntos?
• ¿Cuánto pesan los archivos adjuntos?
• ¿Adjuntas nuevos archivos cada vez que hay correcciones?

Entrega de tareas vía correo electrónico

• ¿Qué pasa si enviaste tu correo con un adjunto “fake” para cumplir con la fecha de entrega?
  • Y “lo arreglas después” enviando otro correo “con el adjunto corregido”
• ¿Qué pasa si el correo electrónico «nunca llega»?
  • Profe, el servidor de correo se comió mi tarea

Entrega de tareas vía correo electrónico

Nombre de los archivos : Expectativa 🧐 🤓

• tarea-1-AndresHernandez-prog.c
• tarea1-ALHB-programa-1.c
• AndresHdz-tarea-1.c
• programa-AndresH-tarea-1.c

Entrega de tareas vía correo electrónico

Nombre de los archivos : Realidad 🤨 🤦 🔥

• tarea/prog.c
• modificado2/prog.c
• vers-28sep/prog.c
• Proyecto_2023-1_(Andres)/prog1.c
  • 🚩 Estamos en el semestre 2023-2 🚩

Entrega de tareas en una carpeta compartida

Entrega de tareas en una carpeta compartida

• Pones tu archivo en un “lugar externo” y mandas la liga para que se pueda descargar la tarea desde tu “servidor local” 💻 o en “la nube” ☁️

• No necesitas mandar nuevos archivos adjuntos si corriges tu tarea 😎

  • Incluso puedes corregir tu tarea después de la fecha límite de entrega

Entrega de tareas en una carpeta compartida

• ¿Qué pasa si “ese otro lado” donde almacenas tu tarea queda fuera de línea?
  • Mamá, ¡Te dije que no apagaras la laptop!.
    Ahora el profe ya no puede bajar mi tarea.
    • 💻 I’m in danger 🔥
• ¿Qué pasa si te suspenden la cuenta de “ese otro lado” y nadie puede acceder a los archivos que tengas allá? ⛈️ ⛔

Entrega de tareas en una plataforma

• No hay una interfaz de línea de comandos para las plataformas

  • Moodle
  • Google Classroom
  • etc.

• Eso complica la automatización de las revisiones

¿Existe otra solución?

⌗SpoilerAlert: Si

git

• Software libre y de código abierto para control de versiones distribuido
• Es utilizado por proyectos «muy grandes» con «muchos» desarrolladores
  • Kernel Linux, GNU coreutils, Kubernetes, etc.
• https://git-scm.com/

Características de git

• Velocidad
• Diseño simple
• Soporte para múltiples ramas
• Enfoque distribuido
• Capacidad de alojar grandes proyectos
• Varios desarrolladores pueden trabajar en el mismo proyecto
• Incluye verificación de integridad en los archivos

Entrega de tareas en un repositorio de git

📓 📝 📋 ⇒

Hospedaje de repositorios

Entrega de actividades en git

• Elegí GitLab para que los alumnos entreguen sus actividades
• ¿Por qué no %s?
  • Porque GitLab puede ser utilizado en la nube y también puedes instalar una instancia local si quieres

Evolución de las entregas

• Repositorio central compartido
• Publicación de las entregas en una página web
• Repositorios individuales en un “subgrupo”
• Repositorios fork individuales
  • Una rama de trabajo por cada entrega
  • Los alumnos conservan copia de sus actividades
• Verificación de las entregas
  • De manera local y en el servidor

Repositorio central compartido

• Hay que darle acceso a todos al repositorio
• Cada quién tiene “su carpeta” o “su rama” y sube ahí sus entregas
  • ¿Qué pasa si borras las tareas de alguién que no te cae bien?
• ¿Cómo se resuelven los conflictos en el repositorio?
• ¿Los alumnos tienen copia de sus actividades entregadas?

Repositorios individuales en un “subgrupo”

• Hay que darle acceso a todos al grupo
• Cada quién sube sus tareas “como quiere”, “donde quiere” y “cuando quiere”
• ¿De qué manera sé que ya entregaron sus actividades?
• Ahora hay que monitorear manualmente «N» repositorios
  • Se complica bastante hacer correcciones

Repositorios fork individuales 🔱

• Hay un solo repositorio central de actividades
• Cada alumno hace una copia del repositorio (fork) asociado a su cuenta
• Los alumnos suben sus tareas a su propio repositorio (fork)
• Las actividades se entregan vía merge request al repositorio central

Ramas de trabajo en el repositorio

• Hay una “rama base” para todas las entregas que da un entorno de trabajo “limpio”
• Los alumnos utilizan esa “rama base” para crear la rama de trabajo para su actividad
  • tarea-1, practica-2, proyecto-3, etc.
• Los alumnos envían su actividad a una rama con el mismo nombre cuando crean su merge request

Entrega de actividades con merge requests

• Los alumnos envían sus actividades en un merge request desde su repositorio fork al repositorio central

  • Se puede hacer revisión de código para pedir correcciones
  • Existe un historial del merge request
  • Notificaciones por correo electrónico

Revisión de código

• Se verifica la entrega y se piden correcciones

  • Nombre de archivos y carpetas
  • Formato de archivos
  • No deben existir conflictos
  • El pipeline debe ser exitoso

• Los alumnos corrigen, envían sus cambios al servidor, se actualiza merge request y eventualmente se acepta la entrega

Manejo de conflictos

• Conflictos en el repositorio fork ❗
  • Cada alumno o equipo lo soluciona por separado sin afectar a los demás
• Conflictos en el merge request ❌
  • Se piden correcciones al alumno o equipo
  • No se acepta la entrega hasta que se solucionen ⚠️

pre-commit

• Verifica errores comunes y repara los archivos antes de versionarlos

• Se instala en el repositorio y se ejecuta cada vez que se hace commit

  • Requiere que los alumnos lo instalen en su copia local de trabajo

• Se puede ejecutar pre-commit desde el pipeline de CI/CD en GitLab

GitLab Pages

• Permite publicar un sitio web hospedado en GitLab

  • NOMBRE.gitlab.io/repositorio
  • NOMBRE.gitlab.io/grupo/repositorio
  • NOMBRE.gitlab.io/grupo/subgrupo/repositorio

• Se puede versionar diréctamente el código HTML, o bien convertirlo en un pipeline de CI/CD

GitLab Pages

• Decidí que utilizaramos mkdocs porque me gusta utilizar Markdown 📝 y Python 🐍

• El contenido del sitio se convierte utilizando un pipeline de CI/CD ⚙️

  • La conversión se hace utilizando un Makefile que invoca mkdocs 🔧

• Las entregas todas las actividades se publican en un sitio web 🌎

Pipeline de CI/CD

• CI/CD: Continuous Integration / Continuous Deployment

• Automatización para ejecutar acciones “del lado del servidor” después de un evento (push, etc.)

• Configuración específica para GitLab:

  • El pipeline define las acciones (jobs) y los estados (stages) que contienen las acciones a ejecutar para reaccionar a un evento

Pipeline de CI/CD

• Convierte el sitio de Markdown a HTML utilizando mkdocs

• Se pueden ejecutar verificaciones adicionales

  • pre-commit del lado del servidor

• Todas las acciones se invocan utilizando un Makefile y un script de shell

Pipeline de CI/CD

• Idealmente se ejecuta cada vez que los alumnos hacen push al servidor

• Por desgracia ya no es así porque abusaron del servicio de CI/CD de GitLab

• Cada pipeline se ejecuta en un runner de GitLab (compartido o propio)

• Muchos de los alumnos no pueden ejecutar el pipeline

GitLab Runner

• Es una aplicación que se conecta a GitLab para ejecutar los trabajos de CI/CD
• Antes GitLab daba acceso a los runners compartidos, pero ya no lo hace porque abusaron del servicio 🔥
• Los usuarios pueden configurar runners propios (self-managed) para correr sus pipelines

GitLab Runner

GitLab Runner

GitLab Runner

• Hay varias maneras de ejecutar gitlab-runner

  • Shell, SSH, Docker, Kubernetes

• Terminé ejecutando mis runners con Docker 🐳

Configuración de GitLab Runner

• Los project runners se autentican con GitLab utilizando un tóken

• Necesitas permisos de maintainer para configurar los runners en un repositorio

• Puedes registrar un project runner en un repositorio y después habilitarlo en otros

  • Incluso en repositorios de otros usuarios 🎉

Evolución

Antes 🖋️ 🤔

• El perro se comió mi tarea (física) 🐶 📁 📝
• El perro se comió mi memoria USB 🐶 💾 💿
• El servidor de correo se comió mi tarea ✉️

Ahora 💻 😅

• El repo local de git se comió mi tarea 👩‍💻 ❌
• El servidor de git se comió mi tarea 🌎 🚸
• El merge request se comió mi tarea 🧑‍🏫 ⛔

Resumen

• Los alumnos hacen fork del repositorio central
• Los alumnos crean una rama para su actividad
• Los alumnos entregan con un merge request
• Se hace revisión de código en cada entrega
• Pipeline de CI/CD: Ejecuta pre-commit y mkdocs
• GitLab runner compartido con los alumnos
• Las entregas se publican en un sitio web

Ventajas para los alumnos

• Aprenden a trabajar con git
• Se acostumbran al manejo de ramas
• Conocen cómo hacer un merge request
• Se familiarizan con las revisiones de código
• Pueden revisar la configuración del pipeline
• No necesitan ejecutar su propio GitLab runner
• Ven sus entregas en un sitio web

Ventajas para el profesor

• Formato estándar de contenido (Markdown)
• Estructura definida para archivos y carpetas
• Una rama por actividad entregada
• Un solo mecanismo de revisión (merge request)
• Historial de cambios en el repositorio
• Correcciones puntuales en la revisión de código
• pre-commit reduce los problemas comunes
• El pipeline detecta problemas en las entregas

Siguientes pasos

• Uso de mkdocs serve
• Detección de conflictos utilizando el pipeline
• Instrucciones para resolución de conflictos
• Automatización de configuración de runners
  • Esto se puede hacer con Ansible
• Instrucciones para W＊nd＊ws y CygWin/WSL 😞
• Uso de glab, la herramienta CLI de GitLab

Curso actual: Redes

• https://Redes-Ciencias-UNAM.gitlab.io/
• https://gitlab.com/Redes-Ciencias-UNAM/

¿Preguntas?

Gracias

Andrés Hernández

tonejito