Gestión de Código Fuente e Integración Continua 22-23

De Wiki de EGC
Revisión del 09:30 11 oct 2022 de Ajramirez (discusión | contribuciones)
(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)
Saltar a: navegación, buscar

Página_Principal -> 2022/2023 -> Prácticas - 22/23

Prerrequisitos

Puedes utilizar este repositorio para basarte: Repo con Actions


Uso de Git

Para repasar y aprender más

Ejercicio 1. git branch -d

Para preparar el entorno de decide en vuestro GitHub, es recomendable limpiar el proyecto quedarnos únicamente con las ramas relevantes para el desarrollo.

  1. Visualiza las ramas desde tu repositorio local. ¿Cómo mostramos las ramas que están en el repositorio remoto (GitHub)?.
  2. Borra una rama diferente a la de master y comprueba que se ha borrado en GitHub.
  3. Haz lo mismo con todas las ramas que no creas útiles. Puedes automatizar esta tarea haciendo uso de instrucciones de Linux como grep, cut o xargs

Ejercicio 2. git rebase y git merge

  1. Trabajando en local, crea una rama con el objetivo de desarrollar alguna nueva funcionalidad. Haz algunos commits ahí.
  2. Muevete a la rama master y haz algún commit más.
  3. Ahora quieres subir los cambios al servidor remoto con push, pero no te interesa que la rama que has creado exista en el remoto, ya que era algo local tuyo. ¿Qué consideras más oportuno antes de hacer un push? ¿Rebase ó Merge hacia master?
  4. ¿Qué diferencias habría en la rama master?

Ejercicio 3. git cherry-pick

  1. Trabajando en local, crea una rama y haz varios commits.
  2. Vuelve a la rama master.
  3. De todos los commits que has hecho en la rama anterior, sólo te interesa uno o dos de ellos, pero no la rama entera, ¿cómo puedes traerte esos cambios a la rama master?
  4. ¿Crees que es buena práctica usarlo?

Ejercicio 4. git reset

  1. Trabajando en local, haz varios commits sobre la rama master pero no lo subas al servidor remoto.
  2. Suponiendo que los cambios de código que has hecho están bien, pero que los commits y sus mensaje no te parecen tan correctos, ¿cómo deshacemos esos commits sin perder el código fuente?
  3. Y, si quieres desahacer también los cambios hechos en el código, ¿cómo podemos hacerlo?
  4. ¿Podemos hacer esto con commits que hayan sido enviados al servidor remoto? ¿Por qué? ¿Qué habría que hacer entonces si quiere revertir cambios en el servidor remoto?

Más ejercicios de Git aquí

Uso de Github Actions

Revisa antes los Conceptos básicos para poder usar Github Actions. Puedes utilizar este repositorio para basarte: Repo con Actions

Ejercicio 5. CI/CD de decide

Siguiendo estas instrucciones:

  1. Revisa que al hacer push se lanza el worflow de integración continua de decide.
  2. Crea una rama donde reduciremos la carga de tests. Comentaremos los tests de mixnet y el test_complete_voting del módulo Voting.
  3. Crea un pull-request siguiendo estas instrucciones (Fíjate bien que la pull request la haces a la rama master de tu repositorio y no a otro repositorio ni a EGCETSI/decide).
  4. Si abres la pull request que se ha creado, podrás observar abajo cómo se ejecuta el workflow de Github Actions con la pull request.
  5. ¿Es exitoso o fallido? ¿Por qué?

Ejercicio 6. Matriz con diferentes versiones de python

Siguiendo estas instrucciones:

  1. Configura el workflow para que lanze las pruebas en varias versiones de Python y Django.
  2. ¿Cuántos jobs se están lanzando?

Ejercicio 7. Badges de workflows

Siguiendo estas instrucciones

  1. Configura el README.md de tu proyecto para que muestre una imagen con el estado de la construcción.
  2. Si tienes varios workflow, ¿puede generarse un badge general o tiene que generarse un badge para cada workflow?

Ejercicio 8. Reutilización de workflows y creación de releases

Siguiendo estas instrucciones:

  1. Crea un nuevo workflow con una etapa de buildTest, (que invoque al workflow django.yml) y otro job de release.
  2. Haga que este workflow se dispare sólo cuando se cree un tag.
  3. Haga que el workflow django.yml sea "invocable" requiriendo el parámetro de secrets CODACY_PROJECT_TOKEN.
  4. Cree un tag.
  5. ¿Cuántos workflows se disparan?
  6. ¿Cuántos jobs se ejecutan del nuevo workflow?
  7. ¿Se crea correctamente la release? ¿Por qué?

Uso de Codacy

Ejercicio 9. Calidad de código

  1. Analiza el reporte de Codacy para el proyecto.
  2. ¿Crees que el estado de los problemas (Issues), cobertura y duplicidad de decide son importantes?
  3. Siguiendo estas instrucciones configura el README.md de tu proyecto para que muestre el estado de la calidad del proyecto y su análisis de cobertura de tests.

Archivo:03-Codigo y GActions.pdf