Diferencia entre revisiones de «Gestión de código fuente e Integración Continua»

De Wiki de EGC
Saltar a: navegación, buscar
(→‎Prerrequisitos)
(Se ha deshecho la revisión 8885 de Ajramirez (disc.))
 
(No se muestran 22 ediciones intermedias de 2 usuarios)
Línea 4: Línea 4:
  
 
* Ver video de presentación aquí: [https://hdvirtual.us.es/discovirt/index.php/s/XARpwL5AdG5nD6F aquí]
 
* Ver video de presentación aquí: [https://hdvirtual.us.es/discovirt/index.php/s/XARpwL5AdG5nD6F aquí]
−
* Configuración de GitHub
+
* [[ConfPreviasPractica3 | Configuraciones Previas]]
−
# Crea una cuenta en http://github.com
 
−
# Desde un terminal crear un par de clave pública y privada SSH:
 
−
<source lang="bash">
 
−
% ssh-keygen
 
−
</source>
 
−
# Esto genera un par de claves pública y privada en la carpeta /home/USUARIO/.ssh/. El fichero /home/usuario/.ssh/id_rsa.pub contiene la clave pública.
 
−
# Carga la clave pública SSH a github (Arriba a la derecha: zona de usuario -> 'settings' -> SSH keys). Basta con copia el contenido de /home/usuario/.ssh/id_rsa.pub en el formulario que aparece en github.
 
−
Recuerda: Con una clave pública por ordenador personal que tienes es suficiente. Por tanto, no hace falta que crees un par de claves pública y privada SSH cada vez que comiences un nuevo proyecto, puedes usar la misma siempre que nadie te robe tu clave privada.
 
  
−
La clave pública se almacena dentro de la carpeta .ssh en el home del usuario, tiene una apariencia similar a la siguiente.
+
= Uso de Git =
  
−
<source lang="bash">
+
[[Uso_de_git | Para repasar y aprender más]]
−
% cd .ssh
+
== Ejercicio 1. git rebase y git merge ==
−
% cat id_rsa.pub
+
# Trabajando en local, crea una rama con el objetivo de desarrollar alguna nueva funcionalidad. Haz algunos commits ahí.
−
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDrd[... bytes omitidos intencionadamente ...]BDA3z1C1 profesor@pc-14-142
+
# Muevete a la rama master y haz algún commit más.
−
</source>
+
# 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?
 +
# ¿Qué diferencias habría en la rama master?
  
−
Para saber más: [https://git-scm.com/book/es/v2/Git-en-el-Servidor-Generando-tu-clave-p%C3%BAblica-SSH]
+
== Ejercicio 2. git reset ==
 +
# Trabajando en local, haz varios commits sobre la rama master pero no lo subas al servidor remoto.
 +
# Suponiendo que te 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?
 +
# Y, si quieres desahacer también los cambios hechos en el código, ¿cómo podemos hacerlo?
 +
# ¿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?
  
−
Por cierto, github permite crear organizaciones en las que participan múltiples usuarios.
+
== Ejericicio 3. git cherry-pick ==
−
# Por último, Git necesita que se le especifique el nombre y el email del autor del cambio. Esto se hace con las siguientes órdenes:
+
# Trabajando en local, crea una rama y haz varios commits.
 +
# Vuelve a la rama master.
 +
# 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?
 +
# ¿Crees que es buena práctica usarlo?
  
−
<source lang="bash">
+
== [[Ejercicios_de_git|Más ejercicios de Git aquí]] ==
−
    git config --global user.name "Your Name"
 
−
    git config --global user.email you@example.com
 
−
</source>
 
  
−
Esto genera un fichero en /home/usuario/.gitconfig con tus preferencias de usuario. Puede ser modificado con un editor de texto.
+
= Uso de Travis =
  
−
Para l@s curios@s, las órdenes de arriba crean un fichero .gitconfig en la carpeta local del usuari@ con este contenido:
+
[[ Travis_CI_2021 | Conceptos básicos]]
  
−
<source lang="bash">
+
== Ejercicio 4. Análisis de pull-request ==
−
$ cat .gitconfig
+
# Crea una rama donde reduciremos la carga de tests. Comentaremos los tests de mixnet y el test_complete_voting del módulo Voting.
−
[user]
+
# Crea un pull-request siguiendo [https://help.github.com/articles/creating-a-pull-request/#creating-the-pull-request estas instrucciones] (Fíjate bien que la pull request la haces a la rama <code>master</code> de tu repositorio y no a otro repositorio ni a <code>EGCETSI/decide</code>).
−
name = Profe EGC
+
# Si abres la pull request que se ha creado, podrás observar abajo cómo se ejecuta una nueva build en Travis CI con la pull request.  
−
email = profeegc@gmail.com
+
# ¿Es exitoso o fallido? ¿Por qué?
−
</source>
 
−
# Prueba a clonar tu proyecto y hacer un push con algún cambio.
 
  
−
* Configuración en Travis
+
== Ejercicio 5. Notificaciones ==
−
# Usando tu cuenta de GitHub entra en https://travis-ci.com y acepta la confirmación de permisos de GitHub.
+
Siguiendo [[Notificaciones|estas instrucciones]]:
−
# Una vez que estés logueado en Travis CI y se hayan sincronizado tus repositorios de GitHub, ve a tu perfil y activa el repositorio que quieras construir.
+
# Configura el README.md de tu proyecto para que muestre una imagen con el estado de la construcción.
−
# Confirma que el <code>.travis.yml</code> existe en la raiz del repositorio. Éste indica a Travis CI lo que tiene que hacer.
+
# Configura Travis CI para que envíe un correo siempre que haya una nueva build, tanto si tiene éxito como si falla, y que además notifique siempre a tu correo electrónico independientemente de quién haya hecho el commit.
−
# Haz commit y push del <code>.travis.yml</code> para iniciar una build de Travis CI o Lanza el build con la opción "Trigger Build" desde Travis CI.
+
# ¿Te ha llegado el correo? ¿Por qué?
−
# Comprueba en la [https://travis-ci.com/ página de estado de la construcción] si tu build ha pasado o falla.
 
−
# En principio, es normal obtener un error de "CODACY_PROJECT_TOKEN missing"
 
  
−
* Configuración de Codacy
+
== Ejercicio 6. Build Matrix ==
−
# Usando tu cuenta de GitHub entra en https://app.codacy.com y acepta la confirmación de permisos de GitHub.
+
# Siguiendo [[Jobs_con_múltiples_builds_para_Decide| estas instrucciones]], configura Travis CI para que lanze las pruebas con varias versiones de Python y django.
−
# Obtener la Project API del repositorio dentro de Codacy.
+
# ¿Cuántos jobs se están lanzando?
−
[[Archivo:codacy_api.png|500px]]]
+
 
−
# En Travis, editar las propiedades del build y añadir la variable de entorno "CODACY_PROJECT_TOKEN"
+
== Ejercicio 7. Chrome ==
−
[[Archivo:codacy.png|500px]]
+
# Incluya alguna prueba de Selenium en su código.
−
# Trás realizar esto, ya podemos ver que el build termina correctamente y que envia los datos a codacy:
+
# Configura Travis CI para que instale las dependencias de python necesarias.
−
[[Archivo:codacy_success.png|500px]]]
+
# Configura Travis CI para que la máquina virtual disponga de Chrome. Puedes seguir [https://docs.travis-ci.com/user/chrome  estas instrucciones]
 +
# ¿Obtiene los resultados esperado? ¿Por qué?
 +
 
 +
= Uso de Codacy =
 +
== Ejercicio 8. Calidad de código ==
 +
# Analiza el reporte de Codacy para el proyecto.  
 +
# ¿Crees que el estado de los problemas (Issues), cobertura y duplicidad de decide son importantes?
 +
# Siguiendo [https://docs.codacy.com/repositories/badges/  estas instrucciones] configura el README.md de tu proyecto para que muestre el estado de la calidad del proyecto.
 +
----
 +
 
 +
[[Archivo:03-CodigoTravis.pdf]]
 +
 
 +
[https://thucnc.medium.com/how-to-show-current-git-branch-with-colors-in-bash-prompt-380d05a24745 Cómo mostrar la rama de Git en el promt de Bash]
 +
 
 +
= Grabación de la práctica en ASCII =
 +
 
 +
Video de la clase: [https://hdvirtual.us.es/discovirt/index.php/s/NbT6bifcneaRBtm aquí]

Revisión actual del 20:53 15 dic 2020

Página_Principal -> 2020/2021 -> Prácticas - 20/21

Prerrequisitos

Uso de Git

Para repasar y aprender más

Ejercicio 1. 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 2. git reset

  1. Trabajando en local, haz varios commits sobre la rama master pero no lo subas al servidor remoto.
  2. Suponiendo que te 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?

Ejericicio 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?

Más ejercicios de Git aquí

Uso de Travis

Conceptos básicos

Ejercicio 4. Análisis de pull-request

  1. Crea una rama donde reduciremos la carga de tests. Comentaremos los tests de mixnet y el test_complete_voting del módulo Voting.
  2. 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).
  3. Si abres la pull request que se ha creado, podrás observar abajo cómo se ejecuta una nueva build en Travis CI con la pull request.
  4. ¿Es exitoso o fallido? ¿Por qué?

Ejercicio 5. Notificaciones

Siguiendo estas instrucciones:

  1. Configura el README.md de tu proyecto para que muestre una imagen con el estado de la construcción.
  2. Configura Travis CI para que envíe un correo siempre que haya una nueva build, tanto si tiene éxito como si falla, y que además notifique siempre a tu correo electrónico independientemente de quién haya hecho el commit.
  3. ¿Te ha llegado el correo? ¿Por qué?

Ejercicio 6. Build Matrix

  1. Siguiendo estas instrucciones, configura Travis CI para que lanze las pruebas con varias versiones de Python y django.
  2. ¿Cuántos jobs se están lanzando?

Ejercicio 7. Chrome

  1. Incluya alguna prueba de Selenium en su código.
  2. Configura Travis CI para que instale las dependencias de python necesarias.
  3. Configura Travis CI para que la máquina virtual disponga de Chrome. Puedes seguir estas instrucciones
  4. ¿Obtiene los resultados esperado? ¿Por qué?

Uso de Codacy

Ejercicio 8. 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.

Archivo:03-CodigoTravis.pdf

Cómo mostrar la rama de Git en el promt de Bash

Grabación de la práctica en ASCII

Video de la clase: aquí

Obtenido de «https://1984.lsi.us.es/wiki-egc/index.php?title=Gestión_de_código_fuente_e_Integración_Continua&oldid=8888»