Wiki de EGC - Contribuciones del usuario [es]

Despliegue de aplicaciones: PaaS y Despliegue Continuo 22-23

2022-11-23T16:21:59Z

Ajramirez:

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

'''Nota: En esta práctica se hacen uso de los servicios de CleverCloud, el cual no ofrece capa gratuita pero sí da [https://www.clever-cloud.com/blog/company/2015/04/14/why-isnt-t-there-a-free-tier-in-clever-cloud/ un periodo de prueba] (Actualmente da 20€ para nuevas cuentas)'''

'''Por lo tanto: '''
# '''Recomendamos no introducir nuestros datos bancarios para que no se nos haga ningún cargo involuntario tras el periodo de prueba.'''
# '''La realización de la práctica es voluntaria, aunque los conceptos que se enseñan en ella sí son materia de estudio.'''

= Prerequisitos =
* Crear una cuenta en [https://www.clever-cloud.com CleverCloud] usando email y contraseña.
* Asociar una llave SSH a la cuenta de CleverCloud en el [https://console.clever-cloud.com/users/me/ssh-keys menú de gestión de SSH].
* Instalar CleverCloud CLI sobre Ubuntu:
<syntaxhighlight lang="bash" line='line'>
# Instalamos llave de cifrado:
curl -fsSL https://clever-tools.clever-cloud.com/gpg/cc-nexus-deb.public.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/cc-nexus-deb.gpg

# Añadimos el repositorio
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/cc-nexus-deb.gpg] https://nexus.clever-cloud.com/repository/deb stable main" | sudo tee -a /etc/apt/sources.list

# Instalamos CleverCloud tools
sudo apt update
sudo apt install clever-tools

</syntaxhighlight>
* Comprobar que la instalación es correcta con
<syntaxhighlight lang="bash" line='line'>
clever login
# Se abrirá un navegador con el login de CleverCloud.
</syntaxhighlight>

= Despliegue puntual en CleverCloud =

== Ejercicio 1. Crear aplicación ==
* Desde el "espacio personal" de CleverCloud cree una aplicación. Use la opción "Create a Brand new App".
* Elija una aplicación de tipo "Python" e incluya "Postgress" como Add-on.
¿Para qué sirve el hecho de escoger un "Plan" o una "Localización" concreta?
* Seguir las instrucciones para hacer un push de nuestros código de decide hacia CleverCloud.
* Visualizar el log de la aplicación
¿Por qué está fallando?
¿Cuál es la URL dónde debería estar la aplicación desplegada en CleverCloud?

== Ejercicio 2. Archivo de configuración de CleverCloud ==
CleverCloud realiza dos etapas:
# Build: Prepara el entorno, instala las dependencias, etc.
# Run: Despliega y expone la aplicación.
Parte de la configuración de estas etapas se hace en el archivo de configuración de CleverCloud. Para Python, este archivo deberá estar en <code> clevercloud/python.json </code>.
* Cree ese archivo con el siguiente contenido:
<syntaxhighlight lang="json">
{
"build": {
"folder": "decide"
},
"deploy": {
"module": "decide.wsgi:application",
"managetasks": [
"collectstatic --noinput",
"migrate"
]
}
}
</syntaxhighlight>
* Como en CleverCloud no habrá local_settings, editaremos el <code> decide/settings.py </code> para que contenga una configuración válida para CleverCloud. Estos son los cambios principales que habrá que hacer:
# Permitir conexiones más allá de localhost: <code>ALLOWED_HOSTS = ['*'] </code>
# Actualizar la url en <code> BASEURL </code>
# Añadir el bloque de API={ …} apuntando a base url. Puede copiarlo de algún local_settings.py
# Específicar las rutas de los archivos estáticos <code>STATIC_URL = '/static/'</code> y <code>STATIC_ROOT= 'static/'</code>
# El 'migrate' no funcionará si la base de datos no está bien configurada. Para ello puede observar en su aplicación en CleverCloud que hay una configuración de variables de entorno para sus Add-on de postgres. # Desde el settings.py puede acceder al valor de dichas variables con <code>os.environ.get(NOMBRE_VARIABLE)</code>. Actualize el objeto "DATABASES" del settings.py para que acceda a dichas variables.
*Vuelva a realizar un push a CleverCloud (no olvide hacer commit antes).
¿Por qué sigue sin funcionar?
* El requirements.txt no lo está identificando al buscarlo, por defecto, dentro de la carpeta indicada en "folder". Copie el requirements.txt dentro de la carpeta decide (También puede especificar la ruta del requirements.txt usando la variable de entorno CC_PIP_REQUIREMENTS_FILE, ver siguiente ejercicio).
== Ejercicio 3. Variables de entorno de CleverCloud ==
Hay otra parte de la configuración de CleverCloud que ha de especificarse dentro las variables de entorno de la aplicación.
* Para que la aplicación se levante correctamente, ha de usar la versión de python 3.8 en la variable CC_PYTHON_VERSION.
* Para indicar qué url dirige a los archivo estáticos, use STATIC_URL_PREFIX con el valor /static. Por ejemplo, el CSS de la aplicación.
* Para indicar la ruta donde se almacenarán dichos archivos, use STATIC_FILES_PATH con el valor decide/static/.
* Pulse sobre "Update changes" y reinicie la aplicacion desde el menú "Overview".
¿Puede ya nevegar hasta el menú de administración de decide?
* Cree el superusuario accediendo por ssh con:
<code>ssh -t ssh@sshgateway-clevercloud-customers.services.clever-cloud.com <<app_name>></code>
El código de la aplicación (manage.py) se encuentra en una carpeta con el nombre de su aplicación.
= Despliege continuo =
== Ejercicio 4. CleverCloud y GitHub Actions==
Para integrar GitHub Actions y CleverCloud cree un workflow de GitHub Actions nuevo, con un solo job.
* Use este workflow a modo de ejemplo:
<syntaxhighlight lang="YAML">
name: Deploy example
on: [push]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
fetch-depth: 0
- uses: 47ng/actions-clever-cloud@v1.3.1
with:
appID: app_fd57a008-7dbd-4636-8b34-af951947911f
env:
CLEVER_TOKEN: ${{ secrets.CLEVER_TOKEN }}
CLEVER_SECRET: ${{ secrets.CLEVER_SECRET }}
</syntaxhighlight>
* Añada la dos secrets al proyecto de GitHub. Estas secrets se obtiene en el proceso de hacer <code>clever login</code>. Aunque lo hiciera en los prerrequisitos, puede repetirlo ahora.
* Recuerde que necesita pushear este código (incluídos los cambios anteriores) a su repositorio en GitHub.
¿Ha funcionado el workflow?
¿Ha estado la aplicación en algún momento caída?

== Ejercicio 5. Condiciones de despliegue ==
En GitHub Actions, los workflows tienen la capacidad de definir el/los evento/s que los disparan con la clausua "on:".
Puedes ver [[https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#onpushpull_requestbranchestags aquí]] más detalles de dicha cláusula.
Sin embargo eso no se puede especificar a nivel de job o de step.
A esos niveles pueden expresarse sentencias "if" que permiten ejecutarlas condicionalmente.
Puedes ver [[https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsif aquí]] más detalles de dicha cláusula.

* Integra el job de "deploy" en el workflow que creaste en prácticas anteriores.
* Para hacer que solo se lance el job "deploy" cuando estemos en una rama concreta, por ejemplo, "master", incluiya lo siguiente:

<syntaxhighlight lang="YAML">
deploy:
if: ${{github.ref == 'refs/heads/master' }}
</syntaxhighlight>

* Haga push del nuevo workflow incluyen el job de deploy y su condición. Posterioremente, haz un push de algún otro código a otra rama.
¿Se lanza el workflow?
¿Se lanza el job "deploy"? ¿En que estado se queda?

Modifica la clausula "on:" para que se lance el workflow solo cuando se hiciera push a la rama master.
Despues de hacer un push del workflow, haz un push a otra rama.
¿Se lanza el workflow?

= Ejercicio 6. Creación de incidencias =
# El usuario “superuser” no se crea dentro del ciclo de despliegue continuo y obliga a hacer una tarea manual en los nuevos despliegues (salvo cuando se mantiene la BD).
# Crear una incidencia según las [[Gestión de incidencias | recomendaciones vistas en clase]] para el error que obtenemos al votar en heroku.
# Asegurarse que la incidencia creada incluye, al menos, un título descriptivo, información de qué es lo que ocurre y cómo puede reproducirse el error.
---------------
* Transparencias: [[Archivo:06-PaaSyDespliegueContinuo.pdf]]

Despliegue de aplicaciones: PaaS y Despliegue Continuo 22-23

2022-11-21T12:59:04Z

Ajramirez:

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

'''Nota: En esta práctica se hacen uso de los servicios de CleverCloud, el cual no ofrece capa gratuita pero sí da [https://www.clever-cloud.com/blog/company/2015/04/14/why-isnt-t-there-a-free-tier-in-clever-cloud/ un periodo de prueba] (Actualmente da 20€ para nuevas cuentas)'''

'''Por lo tanto: '''
# '''Recomendamos no introducir nuestros datos bancarios para que no se nos haga ningún cargo involuntario tras el periodo de prueba.'''
# '''La realización de la práctica es voluntaria, aunque los conceptos que se enseñan en ella sí son materia de estudio.'''

= Prerequisitos =
* Crear una cuenta en [https://www.clever-cloud.com CleverCloud] usando email y contraseña.
* Asociar una llave SSH a la cuenta de CleverCloud en el [https://console.clever-cloud.com/users/me/ssh-keys menú de gestión de SSH].
* Instalar CleverCloud CLI sobre Ubuntu:
<syntaxhighlight lang="bash" line='line'>
# Instalamos llave de cifrado:
curl -fsSL https://clever-tools.clever-cloud.com/gpg/cc-nexus-deb.public.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/cc-nexus-deb.gpg

# Añadimos el repositorio
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/cc-nexus-deb.gpg] https://nexus.clever-cloud.com/repository/deb stable main" | sudo tee -a /etc/apt/sources.list

# Instalamos CleverCloud tools
sudo apt update
sudo apt install clever-tools

</syntaxhighlight>
* Comprobar que la instalación es correcta con
<syntaxhighlight lang="bash" line='line'>
clever login
# Se abrirá un navegador con el login de CleverCloud.
</syntaxhighlight>

= Despliegue puntual en CleverCloud =

== Ejercicio 1. Crear aplicación ==
* Desde el "espacio personal" de CleverCloud cree una aplicación. Use la opción "Create a Brand new App".
* Elija una aplicación de tipo "Python" e incluya "Postgress" como Add-on.
¿Para qué sirve el hecho de escoger un "Plan" o una "Localización" concreta?
* Seguir las instrucciones para hacer un push de nuestros código de decide hacia CleverCloud.
* Visualizar el log de la aplicación
¿Por qué está fallando?
¿Cuál es la URL dónde debería estar la aplicación desplegada en CleverCloud?

== Ejercicio 2. Archivo de configuración de CleverCloud ==
CleverCloud realiza dos etapas:
# Build: Prepara el entorno, instala las dependencias, etc.
# Run: Despliega y expone la aplicación.
Parte de la configuración de estas etapas se hace en el archivo de configuración de CleverCloud. Para Python, este archivo deberá estar en <code> clevercloud/python.json </code>.
* Cree ese archivo con el siguiente contenido:
<syntaxhighlight lang="json">
{
"build": {
"folder": "decide"
},
"deploy": {
"module": "decide.wsgi:application",
"managetasks": [
"collectstatic --noinput",
"migrate"
]
}
}
</syntaxhighlight>
* Como en CleverCloud no habrá local_settings, editaremos el <code> decide/settings.py </code> para que contenga una configuración válida para CleverCloud. Estos son los cambios principales que habrá que hacer:
# Permitir conexiones más allá de localhost: <code>ALLOWED_HOSTS = ['*'] </code>
# Actualizar la url en <code> BASEURL </code>
# Añadir el bloque de API={ …} apuntando a base url. Puede copiarlo de algún local_settings.py
# Específicar las rutas de los archivos estáticos <code>STATIC_URL = '/static/'</code> y <code>STATIC_ROOT= 'static/'</code>
# El 'migrate' no funcionará si la base de datos no está bien configurada. Para ello puede observar en su aplicación en CleverCloud que hay una configuración de variables de entorno para sus Add-on de postgres. # Desde el settings.py puede acceder al valor de dichas variables con <code>os.environ.get(NOMBRE_VARIABLE)</code>. Actualize el objeto "DATABASES" del settings.py para que acceda a dichas variables.
*Vuelva a realizar un push a CleverCloud (no olvide hacer commit antes).
¿Por qué sigue sin funcionar?
* El requirements.txt no lo está identificando al buscarlo, por defecto, dentro de la carpeta indicada en "folder". Copie el requirements.txt dentro de la carpeta decide (También puede especificar la ruta del requirements.txt usando la variable de entorno CC_PIP_REQUIREMENTS_FILE, ver siguiente ejercicio).
== Ejercicio 3. Variables de entorno de CleverCloud ==
Hay otra parte de la configuración de CleverCloud que ha de especificarse dentro las variables de entorno de la aplicación.
* Para que la aplicación se levante correctamente, ha de usar la versión de python 3.8 en la variable CC_PYTHON_VERSION.
* Para indicar qué url dirige a los archivo estáticos, use STATIC_URL_PREFIX con el valor /static. Por ejemplo, el CSS de la aplicación.
* Para indicar la ruta donde se almacenarán dichos archivos, use STATIC_FILES_PATH con el valor static/.
* Pulse sobre "Update changes" y reinicie la aplicacion desde el menú "Overview".
¿Puede ya nevegar hasta el menú de administración de decide?
* Cree el superusuario accediendo por ssh con:
<code>ssh -t ssh@sshgateway-clevercloud-customers.services.clever-cloud.com <<app_name>></code>
El código de la aplicación (manage.py) se encuentra en una carpeta con el nombre de su aplicación.
= Despliege continuo =
== Ejercicio 4. CleverCloud y GitHub Actions==
Para integrar GitHub Actions y CleverCloud cree un workflow de GitHub Actions nuevo, con un solo job.
* Use este workflow a modo de ejemplo:
<syntaxhighlight lang="YAML">
name: Deploy example
on: [push]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
fetch-depth: 0
- uses: 47ng/actions-clever-cloud@v1.3.1
with:
appID: app_fd57a008-7dbd-4636-8b34-af951947911f
env:
CLEVER_TOKEN: ${{ secrets.CLEVER_TOKEN }}
CLEVER_SECRET: ${{ secrets.CLEVER_SECRET }}
</syntaxhighlight>
* Añada la dos secrets al proyecto de GitHub. Estas secrets se obtiene en el proceso de hacer <code>clever login</code>. Aunque lo hiciera en los prerrequisitos, puede repetirlo ahora.
* Recuerde que necesita pushear este código (incluídos los cambios anteriores) a su repositorio en GitHub.
¿Ha funcionado el workflow?
¿Ha estado la aplicación en algún momento caída?

== Ejercicio 5. Condiciones de despliegue ==
En GitHub Actions, los workflows tienen la capacidad de definir el/los evento/s que los disparan con la clausua "on:".
Puedes ver [[https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#onpushpull_requestbranchestags aquí]] más detalles de dicha cláusula.
Sin embargo eso no se puede especificar a nivel de job o de step.
A esos niveles pueden expresarse sentencias "if" que permiten ejecutarlas condicionalmente.
Puedes ver [[https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsif aquí]] más detalles de dicha cláusula.

* Integra el job de "deploy" en el workflow que creaste en prácticas anteriores.
* Para hacer que solo se lance el job "deploy" cuando estemos en una rama concreta, por ejemplo, "master", incluiya lo siguiente:

<syntaxhighlight lang="YAML">
deploy:
if: ${{github.ref == 'refs/heads/master' }}
</syntaxhighlight>

* Haga push del nuevo workflow incluyen el job de deploy y su condición. Posterioremente, haz un push de algún otro código a otra rama.
¿Se lanza el workflow?
¿Se lanza el job "deploy"? ¿En que estado se queda?

Modifica la clausula "on:" para que se lance el workflow solo cuando se hiciera push a la rama master.
Despues de hacer un push del workflow, haz un push a otra rama.
¿Se lanza el workflow?

= Ejercicio 6. Creación de incidencias =
# El usuario “superuser” no se crea dentro del ciclo de despliegue continuo y obliga a hacer una tarea manual en los nuevos despliegues (salvo cuando se mantiene la BD).
# Crear una incidencia según las [[Gestión de incidencias | recomendaciones vistas en clase]] para el error que obtenemos al votar en heroku.
# Asegurarse que la incidencia creada incluye, al menos, un título descriptivo, información de qué es lo que ocurre y cómo puede reproducirse el error.
---------------
* Transparencias: [[Archivo:06-PaaSyDespliegueContinuo.pdf]]

Archivo:06-PaaSyDespliegueContinuo.pdf

2022-11-21T04:14:14Z

Ajramirez:

Despliegue de aplicaciones: PaaS y Despliegue Continuo 22-23

2022-11-21T04:06:44Z

Ajramirez:

[[Página_Principal]] -> [[2022/2023]] -> [[Prácticas - 22/23]]
= Prerequisitos =
* Crear una cuenta en [https://www.clever-cloud.com CleverCloud] usando email y contraseña.
* Asociar una llave SSH a la cuenta de CleverCloud en el [https://console.clever-cloud.com/users/me/ssh-keys menú de gestión de SSH].
* Instalar CleverCloud CLI sobre Ubuntu:
<syntaxhighlight lang="bash" line='line'>
# Instalamos llave de cifrado:
curl -fsSL https://clever-tools.clever-cloud.com/gpg/cc-nexus-deb.public.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/cc-nexus-deb.gpg

# Añadimos el repositorio
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/cc-nexus-deb.gpg] https://nexus.clever-cloud.com/repository/deb stable main" | sudo tee -a /etc/apt/sources.list

# Instalamos CleverCloud tools
sudo apt update
sudo apt install clever-tools

</syntaxhighlight>
* Comprobar que la instalación es correcta con
<syntaxhighlight lang="bash" line='line'>
clever login
# Se abrirá un navegador con el login de CleverCloud.
</syntaxhighlight>

= Despliegue puntual en CleverCloud =

== Ejercicio 1. Crear aplicación ==
* Desde el "espacio personal" de CleverCloud cree una aplicación. Use la opción "Create a Brand new App".
* Elija una aplicación de tipo "Python" e incluya "Postgress" como Add-on.
¿Para qué sirve el hecho de escoger un "Plan" o una "Localización" concreta?
* Seguir las instrucciones para hacer un push de nuestros código de decide hacia CleverCloud.
* Visualizar el log de la aplicación
¿Por qué está fallando?
¿Cuál es la URL dónde debería estar la aplicación desplegada en CleverCloud?

== Ejercicio 2. Archivo de configuración de CleverCloud ==
CleverCloud realiza dos etapas:
# Build: Prepara el entorno, instala las dependencias, etc.
# Run: Despliega y expone la aplicación.
Parte de la configuración de estas etapas se hace en el archivo de configuración de CleverCloud. Para Python, este archivo deberá estar en <code> clevercloud/python.json </code>.
* Cree ese archivo con el siguiente contenido:
<syntaxhighlight lang="json">
{
"build": {
"folder": "decide"
},
"deploy": {
"module": "decide.wsgi:application",
"managetasks": [
"collectstatic --noinput",
"migrate"
]
}
}
</syntaxhighlight>
* Como en CleverCloud no habrá local_settings, editaremos el <code> decide/settings.py </code> para que contenga una configuración válida para CleverCloud. Estos son los cambios principales que habrá que hacer:
# Permitir conexiones más allá de localhost: <code>ALLOWED_HOSTS = ['*'] </code>
# Actualizar la url en <code> BASEURL </code>
# Añadir el bloque de API={ …} apuntando a base url. Puede copiarlo de algún local_settings.py
# Específicar las rutas de los archivos estáticos <code>STATIC_URL = '/static/'</code> y <code>STATIC_ROOT= 'static/'</code>
# El 'migrate' no funcionará si la base de datos no está bien configurada. Para ello puede observar en su aplicación en CleverCloud que hay una configuración de variables de entorno para sus Add-on de postgres. # Desde el settings.py puede acceder al valor de dichas variables con <code>os.environ.get(NOMBRE_VARIABLE)</code>. Actualize el objeto "DATABASES" del settings.py para que acceda a dichas variables.
*Vuelva a realizar un push a CleverCloud (no olvide hacer commit antes).
¿Por qué sigue sin funcionar?
* El requirements.txt no lo está identificando al buscarlo, por defecto, dentro de la carpeta indicada en "folder". Copie el requirements.txt dentro de la carpeta decide (También puede especificar la ruta del requirements.txt usando la variable de entorno CC_PIP_REQUIREMENTS_FILE, ver siguiente ejercicio).
== Ejercicio 3. Variables de entorno de CleverCloud ==
Hay otra parte de la configuración de CleverCloud que ha de especificarse dentro las variables de entorno de la aplicación.
* Para que la aplicación se levante correctamente, ha de usar la versión de python 3.8 en la variable CC_PYTHON_VERSION.
* Para indicar qué url dirige a los archivo estáticos, use STATIC_URL_PREFIX con el valor /static. Por ejemplo, el CSS de la aplicación.
* Para indicar la ruta donde se almacenarán dichos archivos, use STATIC_FILES_PATH con el valor static/.
* Pulse sobre "Update changes" y reinicie la aplicacion desde el menú "Overview".
¿Puede ya nevegar hasta el menú de administración de decide?
* Cree el superusuario accediendo por ssh con:
<code>ssh -t ssh@sshgateway-clevercloud-customers.services.clever-cloud.com <<app_name>></code>
El código de la aplicación (manage.py) se encuentra en una carpeta con el nombre de su aplicación.
= Despliege continuo =
== Ejercicio 4. CleverCloud y GitHub Actions==
Para integrar GitHub Actions y CleverCloud cree un workflow de GitHub Actions nuevo, con un solo job.
* Use este workflow a modo de ejemplo:
<syntaxhighlight lang="YAML">
name: Deploy example
on: [push]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
fetch-depth: 0
- uses: 47ng/actions-clever-cloud@v1.3.1
with:
appID: app_fd57a008-7dbd-4636-8b34-af951947911f
env:
CLEVER_TOKEN: ${{ secrets.CLEVER_TOKEN }}
CLEVER_SECRET: ${{ secrets.CLEVER_SECRET }}
</syntaxhighlight>
* Añada la dos secrets al proyecto de GitHub. Estas secrets se obtiene en el proceso de hacer <code>clever login</code>. Aunque lo hiciera en los prerrequisitos, puede repetirlo ahora.
* Recuerde que necesita pushear este código (incluídos los cambios anteriores) a su repositorio en GitHub.
¿Ha funcionado el workflow?
¿Ha estado la aplicación en algún momento caída?

== Ejercicio 5. Condiciones de despliegue ==
En GitHub Actions, los workflows tienen la capacidad de definir el/los evento/s que los disparan con la clausua "on:".
Puedes ver [[https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#onpushpull_requestbranchestags aquí]] más detalles de dicha cláusula.
Sin embargo eso no se puede especificar a nivel de job o de step.
A esos niveles pueden expresarse sentencias "if" que permiten ejecutarlas condicionalmente.
Puedes ver [[https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsif aquí]] más detalles de dicha cláusula.

* Integra el job de "deploy" en el workflow que creaste en prácticas anteriores.
* Para hacer que solo se lance el job "deploy" cuando estemos en una rama concreta, por ejemplo, "master", incluiya lo siguiente:

<syntaxhighlight lang="YAML">
deploy:
if: ${{github.ref == 'refs/heads/master' }}
</syntaxhighlight>

* Haga push del nuevo workflow incluyen el job de deploy y su condición. Posterioremente, haz un push de algún otro código a otra rama.
¿Se lanza el workflow?
¿Se lanza el job "deploy"? ¿En que estado se queda?

Modifica la clausula "on:" para que se lance el workflow solo cuando se hiciera push a la rama master.
Despues de hacer un push del workflow, haz un push a otra rama.
¿Se lanza el workflow?

= Ejercicio 6. Creación de incidencias =
# El usuario “superuser” no se crea dentro del ciclo de despliegue continuo y obliga a hacer una tarea manual en los nuevos despliegues (salvo cuando se mantiene la BD).
# Crear una incidencia según las [[Gestión de incidencias | recomendaciones vistas en clase]] para el error que obtenemos al votar en heroku.
# Asegurarse que la incidencia creada incluye, al menos, un título descriptivo, información de qué es lo que ocurre y cómo puede reproducirse el error.
---------------
* Transparencias: [[Archivo:06-PaaSyDespliegueContinuo.pdf]]

Despliegue de aplicaciones: PaaS y Despliegue Continuo 22-23

2022-11-21T04:06:10Z

Ajramirez:

Despliegue de aplicaciones: PaaS y Despliegue Continuo 22-23

2022-11-21T02:55:13Z

Ajramirez: Página creada con «Página_Principal -> 2022/2023 -> Prácticas - 22/23 = Prerequisitos = * Crear una cuenta en [https://www.clever-cloud.com CleverCloud] usando email y contrase...»

Prácticas - 22/23

2022-11-21T02:44:51Z

Ajramirez:

[[Página_Principal]] -> [[2022/2023]]

* Práctica 1: [[Instalación de Decide 22-23 | Instalación de Decide]]
* Práctica 2: [[Pruebas de software 22-23 | Pruebas de Software]]
* Práctica 3: [[Gestión de Código Fuente e Integración Continua 22-23 | Gestión de Código Fuente e Integración Continua]]
* Práctica 4: [[Despliegue de aplicaciones: Contenedores 22-23 | Despliegue de aplicaciones: Contenedores ]]
* Práctica 5: [[Despliegue de aplicaciones: Máquinas virtuales 22-23|Despliegue de aplicaciones: Máquinas virtuales]]
* Práctica 6: [[Despliegue de aplicaciones: PaaS y Despliegue Continuo 22-23|Despliegue de aplicaciones: PaaS y Despliegue Continuo]]

Despliegue de aplicaciones: Máquinas virtuales 22-23

2022-11-15T06:43:07Z

Ajramirez:

[[Página_Principal]] -> [[2022/2023]] -> [[Prácticas - 22/23]]
= Prerequisitos =

* [https://videos.us.es/media/P5-+M%C3%A1quinas+virtuales/1_9075tuv8 Vídeo explicando la instalación de los prerequisitos y configuración]

= Instalación de Vagrant Ansible =

Instrucciones para instalar sobre Ubuntu 20.04
<syntaxhighlight lang="bash" line='line'>
sudo apt update
sudo apt install vagrant ansible virtualbox

#Para probar que funciona
vagrant init ubuntu/trusty32
vagrant up
#Suele tardar varios minutos
vagrant ssh -c 'hostnamectl'
#Comparar que devuelve el comando con respecto a ejecutar hostnamectl en local
vagrant destroy #Para eliminar la imagen y liberar espacio
</syntaxhighlight>

== Uso sobre máquinas virtuales (desaconsejado) ==
'''Es altamente recomendable realizar esta práctica en un sistema Linux NO VIRTUALIZADO, es decir, instalado directamente en el equipo (por ejemplo, en una partición).'''
'''En caso contrario, los más probable es que no llegue a funcionar la práctica. Raramente, llegará a funcionar pero con un rendimiento muy bajo (las instrucciones tardan mucho en ejecutarse).'''
Si decides continuar usando máquinas virtuales, lee este texto hasta el final. Tanto el uso dentro de virtualbox como en WSL requieren de bastante configuración.

En caso de usar máquina virtual hay que habilitar la virtualización anidada y asegurarse de tener suficiente espacio en disco.
* [https://www.raulprietofernandez.net/blog/virtualizacion/como-redimensionar-un-disco-virtual-en-virtualbox Espacio en disco].
En caso de usar WSL teneis el [https://www.vagrantup.com/docs/other/wsl tutorial de la propia Vagrant].

=Ejercicios=

* [[Ejercicio 1: Operaciones básicas en Vagrant 21-22 |Ejercicio 1: Operaciones básicas en Vagrant]]
* [[Ejercicio 2: Carpetas compartidas y redirección de puertos 21-22 | Ejercicio 2: Carpetas compartidas y redirección de puertos]]
* [[Ejercicio 3: Encapsulado y aprovisionamiento de una app en Vagrant 21-22 | Ejercicio 3: Encapsulado y aprovisionamiento de una app en Vagrant]]
* [[Ejercicio 4: Despliegue de Decide en Vagrant 21-22 | Ejercicio 4: Despliegue de Decide en Vagrant]]

* Transparencias [[Archivo:05-vagrant.pdf]]

Despliegue de aplicaciones: Máquinas virtuales 22-23

2022-11-09T09:11:23Z

Ajramirez:

Despliegue de aplicaciones: Máquinas virtuales 22-23

2022-11-09T09:08:28Z

Ajramirez: Página creada con «Página_Principal -> 2022/2023 -> Prácticas - 22/23 = Prerequisitos = * [https://videos.us.es/media/P5-+M%C3%A1quinas+virtuales/1_9075tuv8 Vídeo explicando l...»

[[Página_Principal]] -> [[2022/2023]] -> [[Prácticas - 22/23]]
= Prerequisitos =

* [https://videos.us.es/media/P5-+M%C3%A1quinas+virtuales/1_9075tuv8 Vídeo explicando la instalación de los prerequisitos y configuración]

= Instalación de Vagrant Ansible =

Instrucciones para instalar sobre Ubuntu 20.04
<syntaxhighlight lang="bash" line='line'>
sudo apt update
sudo apt install vagrant ansible virtualbox

#Para probar que funciona
vagrant init ubuntu/trusty32
vagrant up
#Suele tardar varios minutos
vagrant ssh -c 'hostnamectl'
#Comparar que devuelve el comando con respecto a ejecutar hostnamectl en local
vagrant destroy #Para eliminar la imagen y liberar espacio
</syntaxhighlight>

== Uso sobre máquinas virtuales (desaconsejado) ==
'''Es altamente recomendable realizar esta práctica en un sistema Linux NO VIRTUALIZADO, es decir, instalado directamente en el equipo (por ejemplo, en una partición).'''
'''En caso contrario, los más probable es que no llegue a funcionar la práctica. Raramente, llegará a funcionar pero con un rendimiento muy bajo (las instrucciones tardan mucho en ejecutarse).'''
Si decides continuar usando máquinas virtuales, lee este texto hasta el final. Tanto el uso dentro de virtualbox como en WSL requieren de bastante configuración.

En caso de usar máquina virtual hay que habilitar la virtualización anidada y asegurarse de tener suficiente espacio en disco.
* [https://www.raulprietofernandez.net/blog/virtualizacion/como-redimensionar-un-disco-virtual-en-virtualbox Espacio en disco].
* [https://www.zonasystem.com/2019/02/habilitar-virtualizacion-anidada-vt-x-amd-v-virtualbox.html Virtualización anidada]
En caso de usar WSL teneis el [https://www.vagrantup.com/docs/other/wsl tutorial de la propia Vagrant].

Prácticas - 22/23

2022-11-09T09:06:18Z

Ajramirez:

Archivo:04-Docker 22.pdf

2022-10-24T16:05:53Z

Ajramirez:

Despliegue de aplicaciones: Contenedores 22-23

2022-10-24T16:05:11Z

Ajramirez:

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

= Prerequisitos =

* [https://videos.us.es/media/P4-+Contenedores/1_1mkxtw14 Vídeo explicando la instalación docker y docker-compose]

== Instalación Docker ==
Instrucciones para instlar sobre Ubuntu 20.04
<syntaxhighlight lang="bash" line='line'>
#Desinstalamos versiones antiguas:
sudo apt-get remove docker docker-engine docker.io containerd runc

#Instalamos dependencias
sudo apt-get update

sudo apt-get install \
ca-certificates \
curl \
gnupg \
lsb-release

# Instalamos llave de cifrado
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Añadimos el repositorio
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Instalamos docker
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io

# Instalamos docker compose
sudo apt-get install docker-compose-plugin

# Añadimos nuestro usuario al grupo docker
sudo usermod -aG docker $USER
newgrp docker

# Tenemos que salir de la sesión y volver a entrar para que los cambios tomen efecto

# Probamos que fundiona con:
docker run hello-world

</syntaxhighlight>

----

= Ordenes para docker =

* [[Lanzando un hola mundo 21-22 |Lanzando un hola mundo]]
* [[Operando con las imagenes]]
* [[Operando con los contenedores]]
* [[Modificando una imagen]]

= Ejemplos =

* [https://docs.docker.com/compose/wordpress/ Para instalar WordPress y MySQL]
* [http://codeomitted.com/deploy-war-file-to-docker-image/ Para construir una imagen con Tomcat básica]
* [https://runnable.com/docker/java/dockerize-your-java-application Para construir una imagen Java muy personalizada].

=Ejercicios=
* [[Ejercicio 0: Ejecutando comandos simples de docker 21-22| Ejercicio 0: Ejecutando comandos simples de docker]]
* [[Ejercicio 1: Creando mi propia imagen para una app python 22-23 | Ejercicio 1: Creando mi propia imagen para una app python]]
* [[Ejercicio 2: Ejecutando decide en docker-compose]]
----
[[Archivo:04-Docker 22.pdf]]

Ejercicio 1: Creando mi propia imagen para una app python 22-23

2022-10-24T16:04:07Z

Ajramirez: Página creada con «= Creando una imagen para una app Flask en python = *Todo el código fuente está disponible en : https://github.com/EGCETSII/1920-Practica-1 Comenzamos creando nuestra a...»

= Creando una imagen para una app Flask en python =

*Todo el código fuente está disponible en : https://github.com/EGCETSII/1920-Practica-1

Comenzamos creando nuestra app en el arcvhivo holamundo.py

<syntaxhighlight lang="python">
from flask import Flask
app = Flask(__name__)
@app.route('/')
def hello_world():
return 'Hello World'
@app.route('/hello/<name>')
def hello_name(name):
return 'Hello %s!' % name
if __name__ == '__main__':
app.run(host="0.0.0.0")

</syntaxhighlight>

Definimos las dependencias en el archivo requirements.txt

<syntaxhighlight lang="python">
Flask
</syntaxhighlight>

Podemos usar la imagen de python3 existente en los repositorios de docker, y modificarla anadiendo la aplicacion que hemos desarrollado

Para ello podemos crear un fichero Dockerfile que nos automatiza la creacion de una imagen modificada:

<syntaxhighlight lang="sh">
# Base image
FROM python:3
#copy the requirements txt file with all our dependencies
COPY requirements.txt ./
#install the dependencies
RUN pip install --no-cache-dir -r requirements.txt
#copy the app in the image
COPY holamundo.py ./
#define a default command to execute
CMD [ "python", "./holamundo.py" ]

</syntaxhighlight>

Este fichero indica que docker tiene que descargar la imagen python en su tercera versión y tiene que añadir el fichero requirements a la carpeta de usuario de la imagen.

Docker nos ofrece un lenguaje de scripting para automatizar la creacion de imagenes.

<syntaxhighlight lang="sh">
# docker build -t holamundo-flask .
</syntaxhighlight>

Va a crear la imagen, tras esto podemos lanzar:

<syntaxhighlight lang="sh">
# docker run -p 8020:80 holamundo-flask
</syntaxhighlight>

Tras esto, desde un navegador, abrimos la URI: http://localhost:8020/hello/"yourname"

Prácticas - 22/23

2022-10-24T15:52:49Z

Ajramirez:

Despliegue de aplicaciones: Contenedores 22-23

2022-10-20T10:51:29Z

Ajramirez: Página creada con «Página_Principal -> 2022/2023 -> Prácticas - 22/23 = Prerequisitos = * [https://videos.us.es/media/P4-+Contenedores/1_1mkxtw14 Vídeo explicando la instalac...»

GithubActions 2022

2022-10-11T08:00:34Z

Ajramirez: /* Nociones básicas sobre GitHub Actions */

== Nociones básicas sobre GitHub Actions==
Dentro de cada .yml de la carpeta .github/worflows se define un:
# '''workflow''' el cuál se dispara al recibir un evento de GitHub.
# Estos '''eventos''' puede ser desde un push hasta la creación de una issue. Cada workflow permite correr jobs.
# Los '''jobs''' son secuencias de pasos. Cada uno de estos jobs se ejecutan dentro de un entorno llamado runner.
# Los '''runners''' son máquinas virtuales que se levantan para cada job. Todos los pasos de un job se ejecutan dentro del mismo runner, por lo que comparten recursos como los archivos y las carpetas.
# Los '''pasos''' de un job pueden ser simples instrucciones de shell, o utilizar funciones más concretas llamadas '''actions''' como, por ejemplo, hacer un clone.

El siguiente workflow tiene como nombre 'GitHub Actions Demo' y se dispara al hacer un push. Únicamente define un job llamado 'Explore-GitHub-Actions' dentro de un runner de tipo ubuntu-latest. Casi todos los pasos son de tipo shell salvo uno que utiliza la acción actions/checkout@v1.

<syntaxhighlight lang="YAML">
name: GitHub Actions Demo
on: [push]
jobs:
Explore-GitHub-Actions:
runs-on: ubuntu-latest
steps:
- run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
- run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
- run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
- name: Check out repository code
uses: actions/checkout@v1
- run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."
- run: echo "🖥️ The workflow is now ready to test your code on the runner."
- name: List files in the repository
run: |
ls ${{ github.workspace }}
- run: echo "🍏 This job's status is ${{ job.status }}."
- name: Contains expresion in a step
run: echo "Is this branch master or develop? ${{ contains('refs/heads/master refs/heads/develop',github.ref)}}"
</syntaxhighlight>

Añade un archivo con este contenido a tu proyecto en GitHub y comprueba su estado en la pestaña Actions:
* ¿Cuántos Worflows, jobs, steps se lanzan?
* ¿Entiendes todo lo que hacen las expresiones ${{ <expresion> }}?
Para consultar la lista completa de expressiones, visita este [[https://docs.github.com/en/actions/learn-github-actions/expressions link]].

Para consultar la lista completa de contextos (e.g., github.<>, job.<> o runner.<>), visita este otro [[https://docs.github.com/en/actions/learn-github-actions/contexts link]].

Para consultar la lista completa de acciones, visita el [[https://github.com/marketplace?type=actions link]].

Archivo:03-Codigo y GActions.pdf

2022-10-11T07:30:45Z

Ajramirez:

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

2022-10-11T07:30:20Z

Ajramirez:

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

= Prerrequisitos =

* Ver video de presentación aquí: [https://videos.us.es/media/P3-+GIT+y+Codacy/1_vr2tpcm0 aquí]
* [[ConfPreviasPractica3 22-23 | Configuraciones Previas]]
* [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]
Puedes utilizar este repositorio para basarte: [https://github.com/AndresJR/decide-23 Repo con Actions]

= Uso de Git =

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

== Ejercicio 2. git rebase y git merge ==
# Trabajando en local, crea una rama con el objetivo de desarrollar alguna nueva funcionalidad. Haz algunos commits ahí.
# Muevete a la rama master y haz algún commit más.
# 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?

== Ejercicio 3. git cherry-pick ==
# 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?

== Ejercicio 4. git reset ==
# Trabajando en local, haz varios commits sobre la rama master pero no lo subas al servidor remoto.
# 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?
# 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?

== [[Ejercicios_de_git|Más ejercicios de Git aquí]] ==

= Uso de Github Actions =

Revisa antes los [[ GithubActions_2022 | Conceptos básicos]] para poder usar Github Actions.
Puedes utilizar este repositorio para basarte: [https://github.com/AndresJR/decide-23 Repo con Actions]

== Ejercicio 5. CI/CD de decide ==
Siguiendo [[CI de decide 22|estas instrucciones]]:
# Revisa que al hacer push se lanza el worflow de integración continua de decide.
# Crea una rama donde reduciremos la carga de tests. Comentaremos los tests de mixnet y el test_complete_voting del módulo Voting.
# 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>).
# 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.
# ¿Es exitoso o fallido? ¿Por qué?

== Ejercicio 6. Matriz con diferentes versiones de python==
Siguiendo [[Matrices en Github Actions 22 |estas instrucciones]]:
# Configura el workflow para que lanze las pruebas en varias versiones de Python y Django.
# ¿Cuántos jobs se están lanzando?

== Ejercicio 7. Badges de workflows ==

Siguiendo [[Badges en Actions 22 |estas instrucciones]]
# Configura el README.md de tu proyecto para que muestre una imagen con el estado de la construcción.
# 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 [[Reutilización de workflows y creación de releases 23 |estas instrucciones]]:
# Crea un nuevo workflow con una etapa de buildTest, (que invoque al workflow django.yml) y otro job de release.
# Haga que este workflow se dispare sólo cuando se cree un tag.
# Haga que el workflow django.yml sea "invocable" requiriendo el parámetro de secrets CODACY_PROJECT_TOKEN.
# Cree un tag.
# ¿Cuántos workflows se disparan?
# ¿Cuántos jobs se ejecutan del nuevo workflow?
# ¿Se crea correctamente la release? ¿Por qué?

= Uso de Codacy =
== Ejercicio 9. 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 y su análisis de cobertura de tests.

----

[[Archivo:03-Codigo_y_GActions.pdf]]

Reutilización de workflows y creación de releases 23

2022-10-09T15:42:57Z

Ajramirez: Página creada con « = Reutilización de workflows y creación de releases = En GitHub puede hacerse crearse una Release de un repositorio en https://github.com/<tu org>/<tu repo>/releases....»

= Reutilización de workflows y creación de releases =

En GitHub puede hacerse crearse una Release de un repositorio en https://github.com/<tu org>/<tu repo>/releases.
Para automatizar el proceso de generación de una release a partir de un tag (siempre y cuando dicho código haya pasado las pruebas) podemos combinar el workflow django.yml con un pasos posterior de release. Para ello:

# Cree un nuevo workflow en la carpeta de los workflows con el siguiente contenido:
<syntaxhighlight lang="YAML">
name: release

on:
push:
tags:
- '*'

jobs:
buildTest:
uses: <tu org>/<tu repo>/.github/workflows/django.yml@master
secrets:
CODACY_PROJECT_TOKEN: ${{secrets.CODACY_PROJECT_TOKEN}}

release:
needs: buildTest
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Release
uses: softprops/action-gh-release@v1
</syntaxhighlight>
# Dado que las variables de entorno y secrets no se comparten entre workflows, hay que pasarlos explicitamente de un worflow al workflow reutilizable. Para convertir el workflow django.yml en reutilizable tenemos que modifcarlo añadiendo:
<syntaxhighlight lang="YAML">
...
on:
push:
branches:
- master
workflow_call:
secrets:
CODACY_PROJECT_TOKEN:
required: true

...
</syntaxhighlight>

Para crear un nuevo tag hagamos:
<syntaxhighlight language="bash">
git tag -a v1.0.0 -m “mensaje para añadir al tag que también aparecerá en la release”
git push origin v1.0.
</syntaxhighlight>

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

2022-10-09T15:41:35Z

Ajramirez: /* Ejercicio 7. Badges de workflows */

Badges en Actions 22

2022-10-09T15:41:02Z

Ajramirez: Página creada con « = Badge de worflows de GitHub Actions = Podemos añadir badges a nuestro README.md relacionados con el estado de un worflow. Para ello: # Accede a la pestaña Actions. #...»

= Badge de worflows de GitHub Actions =
Podemos añadir badges a nuestro README.md relacionados con el estado de un worflow.
Para ello:
# Accede a la pestaña Actions.
# Accede a uno de los Workflows.
# Pulsa el botón ... y genera el badge.
# Incluye el contenido de dicho badge en tu README.MD

Matrices en Github Actions 22

2022-10-09T15:40:02Z

Ajramirez: Página creada con « = Build matrix en GitHub Actions = Podemos indicarle a GitHub que ciertos steps se ejecuten en paralelo. Para ello, hemos de definir una "estrategria" a nivel de job. P...»

= Build matrix en GitHub Actions =

Podemos indicarle a GitHub que ciertos steps se ejecuten en paralelo. Para ello, hemos de definir una "estrategria" a nivel de job.
Para indicar varias versiones de python a utilizar en el step de "setup-python", incluiremos lo siguiente:

<syntaxhighlight lang="YAML">
build:
strategy:
matrix:
pyversion: ['3.5','3.8']
</syntaxhighlight>

Una vez hecho eso, podremos usar el contexto "matrix" en cualquiera de los steps de este job. En este caso lo usaremos en en el siguiente step:

<syntaxhighlight lang="YAML">
- name: Set up Python ${{matrix.pyversion}}
uses: actions/setup-python@v1
with:
python-version: ${{matrix.pyversion}}
</syntaxhighlight>

Haz un push y observa la ejecución del workflow.

¿Qué tendríamos que hacer para probar ampliar el build matrix con las versiones de postress 12 y 10.8? ¿Cuántos jobs se ejecutarían?

CI de decide 22

2022-10-09T15:33:42Z

Ajramirez: Página creada con «= Decide con GitHub Actions = El archivo django.yml ofrecido prepara el entorno, prueba decide y reporta a Codacy. Está compuesto por un job: "build". En el job "build"...»

= Decide con GitHub Actions =

El archivo django.yml ofrecido prepara el entorno, prueba decide y reporta a Codacy. Está compuesto por un job: "build".

En el job "build" se especifica que el servicio de base de datos tendrá que estar disponible en el runner de este job. Se le especifica información de healthchek para verificar que el servicio está correctamente levantado antes de continuar con los pasos del job. Para que este job funcione se tendrá que comprobar que:
# La configuración completa ha de estar en el local_settings.gactions.py.
# Como no es necesario crear la base de datos de "producción" la parte del "migrate" no haría falta realizarla.
# Hay un test que puede fallar llamado "test_multiple_auths_mock" dentro del módulo Mixnet. Si falla, debería anularse ese test.

Haz un push y observa la ejecución del workflow.
* ¿Se lanzan el job? ¿Por qué?
* ¿Está correctamente subido el informe de cobertura a Codacy? ¿Por qué?

GithubActions 2022

2022-10-09T15:29:17Z

Ajramirez: Página creada con «== Nociones básicas sobre GitHub Actions== Dentro de cada .yml de la carpeta .github/worflows se define un: # '''workflow''' el cuál se dispara al recibir un evento de Gi...»

== Nociones básicas sobre GitHub Actions==
Dentro de cada .yml de la carpeta .github/worflows se define un:
# '''workflow''' el cuál se dispara al recibir un evento de GitHub.
# Estos '''eventos''' puede ser desde un push hasta la creación de una issue. Cada workflow permite correr jobs.
# Los '''jobs'' son secuencias de pasos. Cada uno de estos jobs se ejecutan dentro de un entorno llamado runner.
# Los '''runners''' son máquinas virtuales que se levantan para cada job. Todos los pasos de un job se ejecutan dentro del mismo runner, por lo que comparten recursos como los archivos y las carpetas.
# Los '''pasos''' de un job pueden ser simples instrucciones de shell, o utilizar funciones más concretas llamadas '''actions''' como, por ejemplo, hacer un clone.

El siguiente workflow tiene como nombre 'GitHub Actions Demo' y se dispara al hacer un push. Únicamente define un job llamado 'Explore-GitHub-Actions' dentro de un runner de tipo ubuntu-latest. Casi todos los pasos son de tipo shell salvo uno que utiliza la acción actions/checkout@v1.

<syntaxhighlight lang="YAML">
name: GitHub Actions Demo
on: [push]
jobs:
Explore-GitHub-Actions:
runs-on: ubuntu-latest
steps:
- run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
- run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
- run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
- name: Check out repository code
uses: actions/checkout@v1
- run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."
- run: echo "🖥️ The workflow is now ready to test your code on the runner."
- name: List files in the repository
run: |
ls ${{ github.workspace }}
- run: echo "🍏 This job's status is ${{ job.status }}."
- name: Contains expresion in a step
run: echo "Is this branch master or develop? ${{ contains('refs/heads/master refs/heads/develop',github.ref)}}"
</syntaxhighlight>

Añade un archivo con este contenido a tu proyecto en GitHub y comprueba su estado en la pestaña Actions:
* ¿Cuántos Worflows, jobs, steps se lanzan?
* ¿Entiendes todo lo que hacen las expresiones ${{ <expresion> }}?
Para consultar la lista completa de expressiones, visita este [[https://docs.github.com/en/actions/learn-github-actions/expressions link]].

Para consultar la lista completa de contextos (e.g., github.<>, job.<> o runner.<>), visita este otro [[https://docs.github.com/en/actions/learn-github-actions/contexts link]].

Para consultar la lista completa de acciones, visita el [[https://github.com/marketplace?type=actions link]].

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

2022-10-09T15:28:17Z

Ajramirez:

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

= Prerrequisitos =

* Ver video de presentación aquí: [https://videos.us.es/media/P3-+GIT+y+Codacy/1_vr2tpcm0 aquí]
* [[ConfPreviasPractica3 22-23 | Configuraciones Previas]]
* [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]
Puedes utilizar este repositorio para basarte: [https://github.com/AndresJR/decide-23 Repo con Actions]

= Uso de Git =

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

== Ejercicio 2. git rebase y git merge ==
# Trabajando en local, crea una rama con el objetivo de desarrollar alguna nueva funcionalidad. Haz algunos commits ahí.
# Muevete a la rama master y haz algún commit más.
# 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?

== Ejercicio 3. git cherry-pick ==
# 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?

== Ejercicio 4. git reset ==
# Trabajando en local, haz varios commits sobre la rama master pero no lo subas al servidor remoto.
# 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?
# 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?

== [[Ejercicios_de_git|Más ejercicios de Git aquí]] ==

= Uso de Github Actions =

Revisa antes los [[ GithubActions_2022 | Conceptos básicos]] para poder usar Github Actions.
Puedes utilizar este repositorio para basarte: [https://github.com/AndresJR/decide-23 Repo con Actions]

== Ejercicio 5. CI/CD de decide ==
Siguiendo [[CI de decide 22|estas instrucciones]]:
# Revisa que al hacer push se lanza el worflow de integración continua de decide.
# Crea una rama donde reduciremos la carga de tests. Comentaremos los tests de mixnet y el test_complete_voting del módulo Voting.
# 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>).
# 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.
# ¿Es exitoso o fallido? ¿Por qué?

== Ejercicio 6. Matriz con diferentes versiones de python==
Siguiendo [[Matrices en Github Actions 22 |estas instrucciones]]:
# Configura el workflow para que lanze las pruebas en varias versiones de Python y Django.
# ¿Cuántos jobs se están lanzando?

== Ejercicio 7. Badges de workflows ==

Siguiendo [[Badges en Actions 22 |estas instrucciones]]
# Configura el README.md de tu proyecto para que muestre una imagen con el estado de la construcción.

== Ejercicio 8. Reutilización de workflows y creación de releases ==
Siguiendo [[Reutilización de workflows y creación de releases 23 |estas instrucciones]]:
# Crea un nuevo workflow con una etapa de buildTest, (que invoque al workflow django.yml) y otro job de release.
# Haga que este workflow se dispare sólo cuando se cree un tag.
# Haga que el workflow django.yml sea "invocable" requiriendo el parámetro de secrets CODACY_PROJECT_TOKEN.
# Cree un tag.
# ¿Cuántos workflows se disparan?
# ¿Cuántos jobs se ejecutan del nuevo workflow?
# ¿Se crea correctamente la release? ¿Por qué?

= Uso de Codacy =
== Ejercicio 9. 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 y su análisis de cobertura de tests.
----

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

2022-10-08T13:17:30Z

Ajramirez: /* Prerrequisitos */

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

2022-10-07T18:27:45Z

Ajramirez: /* Prerrequisitos */

ConfPreviasPractica3 22-23

2022-10-07T16:14:40Z

Ajramirez:

* Configuración de GitHub
# 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 -t ed25519 -C "your_email@example.com"
</source>
# Esto genera un par de claves pública y privada en la carpeta /home/USUARIO/.ssh/. El fichero /home/usuario/.ssh/id_ed25519.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_ed25519.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.

<source lang="bash">
% cd .ssh
% cat id_ed25519.pub
ssh-ed25519 AAAAB3NzaC1yc2EAAAADAQABAAABAQDrd[... bytes omitidos intencionadamente ...]BDA3z1C1 profesor@pc-14-142
</source>

Para saber más: [https://docs.github.com/es/authentication/connecting-to-github-with-ssh]

Por cierto, github permite crear organizaciones en las que participan múltiples usuarios.
# Por último, Git necesita que se le especifique el nombre y el email del autor del cambio. Esto se hace con las siguientes órdenes:

<source lang="bash">
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.

Para l@s curios@s, las órdenes de arriba crean un fichero .gitconfig en la carpeta local del usuari@ con este contenido:

<source lang="bash">
$ cat .gitconfig
[user]
name = Profe EGC
email = profeegc@gmail.com
</source>
# Prueba a clonar tu proyecto y hacer un push con algún cambio.

* Configuración de Codacy
# Usando tu cuenta de GitHub entra en https://app.codacy.com y acepta la confirmación de permisos de GitHub.
# Obtener la Project API del repositorio dentro de Codacy.
[[Archivo:codacy_api.png|500px]]]
# En Github, editar las propiedades del proyecto y añade la variable de entorno (secrets) "CODACY_PROJECT_TOKEN"
[[Archivo:ghSecrets.png|500px]]
# Trás realizar esto, ya podemos ver que el build termina correctamente y que envia los datos a codacy:
[[Archivo:codacyOK.png|500px]]]

ConfPreviasPractica3

2022-10-07T16:14:24Z

Ajramirez:

* Configuración de GitHub
# 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.

<source lang="bash">
% cd .ssh
% cat id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDrd[... bytes omitidos intencionadamente ...]BDA3z1C1 profesor@pc-14-142
</source>

Para saber más: [https://git-scm.com/book/es/v2/Git-en-el-Servidor-Generando-tu-clave-p%C3%BAblica-SSH]

Por cierto, github permite crear organizaciones en las que participan múltiples usuarios.
# Por último, Git necesita que se le especifique el nombre y el email del autor del cambio. Esto se hace con las siguientes órdenes:

<source lang="bash">
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.

Para l@s curios@s, las órdenes de arriba crean un fichero .gitconfig en la carpeta local del usuari@ con este contenido:

<source lang="bash">
$ cat .gitconfig
[user]
name = Profe EGC
email = profeegc@gmail.com
</source>
# Prueba a clonar tu proyecto y hacer un push con algún cambio.

* Configuración en Travis
# Usando tu cuenta de GitHub entra en https://travis-ci.com y acepta la confirmación de permisos de GitHub.
# 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.
# Confirma que el <code>.travis.yml</code> existe en la raiz del repositorio. Éste indica a Travis CI lo que tiene que hacer.
# 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.
# 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
# Usando tu cuenta de GitHub entra en https://app.codacy.com y acepta la confirmación de permisos de GitHub.
# Obtener la Project API del repositorio dentro de Codacy.
[[Archivo:codacy_api.png|500px]]]
# En Travis, editar las propiedades del build y añadir la variable de entorno "CODACY_PROJECT_TOKEN"
[[Archivo:codacy.png|500px]]
# Trás realizar esto, ya podemos ver que el build termina correctamente y que envia los datos a codacy:
[[Archivo:codacy_success.png|500px]]]

ConfPreviasPractica3 22-23

2022-10-07T16:13:44Z

Ajramirez: Página creada con «https://1984.lsi.us.es/wiki-egc/index.php?title=ConfPreviasPractica3&action=edit * Configuración de GitHub # Crea una cuenta en http://github.com # Desde un terminal crea...»

https://1984.lsi.us.es/wiki-egc/index.php?title=ConfPreviasPractica3&action=edit

* Configuración de GitHub
# 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 -t ed25519 -C "your_email@example.com"
</source>
# Esto genera un par de claves pública y privada en la carpeta /home/USUARIO/.ssh/. El fichero /home/usuario/.ssh/id_ed25519.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_ed25519.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.

<source lang="bash">
% cd .ssh
% cat id_ed25519.pub
ssh-ed25519 AAAAB3NzaC1yc2EAAAADAQABAAABAQDrd[... bytes omitidos intencionadamente ...]BDA3z1C1 profesor@pc-14-142
</source>

Para saber más: [https://docs.github.com/es/authentication/connecting-to-github-with-ssh]

Por cierto, github permite crear organizaciones en las que participan múltiples usuarios.
# Por último, Git necesita que se le especifique el nombre y el email del autor del cambio. Esto se hace con las siguientes órdenes:

<source lang="bash">
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.

Para l@s curios@s, las órdenes de arriba crean un fichero .gitconfig en la carpeta local del usuari@ con este contenido:

<source lang="bash">
$ cat .gitconfig
[user]
name = Profe EGC
email = profeegc@gmail.com
</source>
# Prueba a clonar tu proyecto y hacer un push con algún cambio.

* Configuración de Codacy
# Usando tu cuenta de GitHub entra en https://app.codacy.com y acepta la confirmación de permisos de GitHub.
# Obtener la Project API del repositorio dentro de Codacy.
[[Archivo:codacy_api.png|500px]]]
# En Github, editar las propiedades del proyecto y añade la variable de entorno (secrets) "CODACY_PROJECT_TOKEN"
[[Archivo:ghSecrets.png|500px]]
# Trás realizar esto, ya podemos ver que el build termina correctamente y que envia los datos a codacy:
[[Archivo:codacyOK.png|500px]]]

ConfPreviasPractica3

2022-10-07T16:13:14Z

Ajramirez:

Archivo:GhSecrets.png

2022-10-07T16:12:48Z

Ajramirez:

Archivo:CodacyOK.png

2022-10-07T16:12:26Z

Ajramirez:

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

2022-10-07T16:04:22Z

Ajramirez: Página creada con «Página_Principal -> 2022/2023 -> Prácticas - 22/23 = Prerrequisitos = * Ver video de presentación aquí: [aquí] * ConfPreviasPractica3 22-23 | Configura...»

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

= Prerrequisitos =

* Ver video de presentación aquí: [aquí]
* [[ConfPreviasPractica3 22-23 | Configuraciones Previas]]
* [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]

Prácticas - 22/23

2022-10-07T16:03:41Z

Ajramirez:

Prácticas - 22/23

2022-10-07T16:02:20Z

Ajramirez:

Link1

2022-10-04T08:16:06Z

Ajramirez:

‎<syntaxhighlight lang="python">
class VotingModelTestCase(BaseTestCase):
def setUp(self):

q = Question(desc='Descripcion')
q.save()

opt1 = QuestionOption(question=q, option='opcion 1')
opt1.save()
opt1 = QuestionOption(question=q, option='opcion 2')
opt1.save()

self.v = Voting(name='Votacion', question=q)
self.v.save()
super().setUp()

def tearDown(self):
super().tearDown()
self.v = None

def testExist(self):
v=Voting.objects.get(name='Votacion')
self.assertEquals(v.question.options.all()[0].option, "opcion 1")

‎</syntaxhighlight>

Pruebas del Modelo 22-23

2022-10-04T08:14:35Z

Ajramirez:

Como vimos en las clase de teoría, para poder probar los elementos persistentes disponemos de las pruebas CRUD.
Es importante conocer que en Django los tests no se ejecutan sobre la misma base de datos que la que usamos en producción, por lo que los elementos que creemos no permanecerán en nuestra instalación de producción.

<source>
def setUp(self):
super().setUp()
self.census = Census(voting_id=1, voter_id=1)
self.census.save()

def tearDown(self):
super().tearDown()
self.census = None

def test_store_census(self):
self.assertEqual(Census.objects.count(), 1)
</source>

También hay otros métodos que se definen en los modelos y que puede tener sentido quere probar aunque no persistan datos, como por ejempo __str__ de voting. El siguiente método lo podemos añadir dentro de la clase de test de Voting y utilizar sus métodos auxiliares como el "create_voting()". Es método añade varias opciones con el nombre "opción ''i'' (''i+1'')"

<source>
def test_Voting_toString(self):
v = self.create_voting()
self.assertEquals(str(v),"test voting")
self.assertEquals(str(v.question),"test question")
self.assertEquals(str(v.question.options.all()[0]),"option 1 (2)")

</source>

'''Ejercicio 1'''

Implemente una prueba que cree una votación con una pregunta y dos opciones de respuesta.

[[link1]]

Pruebas de carga 22-23

2022-10-03T10:38:03Z

Ajramirez: Página creada con «Las pruebas de carga se usan para simular cómo responde un software ante una serie de usuarios concurrentes que la usan. Son especialmente útiles cuando estimamos que pu...»

Las pruebas de carga se usan para simular cómo responde un software ante una serie de usuarios concurrentes que la usan.
Son especialmente útiles cuando estimamos que pueden existir picos de uso de una aplicación (p.e. Amazon en Black friday).

Este pudiese ser el caso de decide. Para observar como responde vamos a usar locust, una aplicación python que esta dirigida a efectuar este tipo de operaciones.

= Test de estrés con Locust =
Antes de empezar, hay que entender para qué sirven las pruebas de estrés. A veces necesitamos soportar que nuestra aplicación ofrezca una cantidad de peticiones por segundo porque habrá muchos usuarios entrando a la misma vez y, ante este estrés, tenemos que comprobar cómo se comporta nuestra aplicación.

No es lo mismo que cuando la estresemos nos de un error 500 a que nos devuelva la petición de otro usuario. Con estos test conseguiremos comprobar cuál es ese comportamiento y, quizás, entender cómo mejorar la velocidad de procesamiento de las peticiones para permitir más peticiones por segundo.

Para ejecutar los test de estrés utilizando locust, necesitaremos tener instalado locust:
<source>
$ pip install locust
</source>
Una vez instalado, necesitaremos tener un fichero locustfile.py donde tengamos la configuración de lo que vamos a ejecutar. En nuestro caso, tenemos hecho dos ejemplos dentro de decide/loadtest/locustfile.py:

*Visualizer: Simula un usuario que entra en el visualizador de una votación.

Para ejecutar el test de Visualizer, tenemos que tener en cuenta que entra en la votación 1, por lo que necesitaremos tenerla creada para que funcione correctamente, una vez hecho esto, podemos comenzar a probar con el siguiente comando (dentro de la carpeta loadtest):
<source>
$ locust Visualizer
</source>
Esto abrirá un servidor que podremos ver en el navegador, el mismo comando nos dirá el puerto. Cuando se abra, nos preguntará cuantos usuarios queremos que hagan peticiones a la vez y cómo queremos que vaya creciendo hasta llegar a ese número. Por ejemplo, si ponemos 100 y 5, estaremos creando 5 nuevos usuarios cada segundo hasta llegar a 100.

*Voters: Simula un usuario cuando va a votar, por lo que con este ejemplo estaremos comprobando cuantas votaciones podemos hacer por segundo. A nivel de locust, esos usuarios hacen la secuencia de peticiones REST: login, getuser y store. Para ello, este test utilizar cuentas de usuarios previamente creada.

Para ejecutar el test de Voter, necesitaremos realizar varios pasos previos.
# Necesitaremos la votación 1 abierta.
# Necesitaremos crear una serie de usuarios en el censo de esta votación, para que cuando hagamos el test, estos usuario puedan autenticarse y votar correctamente. Para facilitar esta tarea, hay creado un script de python gen_census.py, con el cual se crean los usuarios que tenemos dentro del fichero voters.json y se añaden al censo utilizando la librería requests. Para que este script funcione, necesitaremos tener instalado request:

<source>
$ pip install requests
</source>

Una vez instalado, ejecutamos el script:
<source>
$ python gen_census.py
</source>
'''Nota:''' habrá que editar el contenido de gen_census.py para configurar la cuenta de usuario administrador para crear estos usuarios y su censo.

Tras esto, ya podremos comenzar el test de estrés de votantes:
<source>
$ locust Voters
</source>

Importante mirar bien el fichero locustfile.py, donde existen algunas configuraciones que podremos cambiar, dependiendo del HOST donde queramos hacer las pruebas y del id de la votación.

A tener en cuenta:

*En un servidor local, con un postgres que por defecto nos viene limitado a 100 usuarios concurrentes, cuando pongamos más de 100, lo normal es que empiecen a fallar muchas peticiones.
*Si hacemos las pruebas en local, donde tenemos activado el modo debug de Django, lo normal es que las peticiones tarden algo más y consigamos menos RPS (Peticiones por segundo).

Pruebas de las Vistas 22-23

2022-10-03T10:36:19Z

Ajramirez: Página creada con «Los módulos ofrecen funcionalidad en la vistas (views.py) que necesitan ser probadas. Algunas de esas vistas pueden ser probadas a través de llamada a las API REST que of...»

Los módulos ofrecen funcionalidad en la vistas (views.py) que necesitan ser probadas. Algunas de esas vistas pueden ser probadas a través de llamada a las API REST que ofrecen. Otrás, sin embargo, ofrecen una vista HTML que tendremos que probar con otros frameworks como Selenium.

= Pruebas de APIs =
Decide tiene implementada una clase para usar como base a la hora de implementar los test de interacción con APIs, BaseTestCase. Esa clase nos ofrece un ''client'' para hacer llamadas REST además de métodos de ''login'' y ''logout'' para simular el ingreso de un usuario en el sistema.

En el siguiente ejemplo podemos ver como se realizar una prueba donde se intenta realizar una acción nula sobre una votación ya creada. El resultado esperado es un 400.

<source>
def test_update_voting_400(self):
v = self.create_voting()
data = {} #El campo action es requerido en la request
self.login()
response = self.client.put('/voting/{}/'.format(v.pk), data, format= 'json')
self.assertEquals(response.status_code, 400)
</source>

'''Ejercicio 1'''

Implemente una prueba que cree una votación a através de su API y la recupere del modelo.

[[link2]]

= Pruebas de navegación =

Selenium es un framework para testing y automatización de acciones web en general que nos permite simular como actuaría un usuario frente a nuestra aplicación[[https://www.seleniumhq.org/]]

En nuestro caso usaremos selenium dada la dificultad de probar las vistas en django. Estas vistas, normalmente, tienen que lidiar con dependencias AJAX, Javascript, etc. para poder ejecutarse normalmente.

Por ejemplo podemos probar si el acceso a la web de login es correcto o no.

'''Ejercicio 2'''

Instalamos selenium
<source> $ pip install selenium </source>
Instalamos, si no lo hemos hecho ya, chromiun y el driver para chromium que se encargará de reproducir el código dentro del navegador
<source>
sudo apt install chromium-browser chromium-chromedriver
</source>

Finalmente, escribimos el código de nuestro test.
Los test de Selenium requerirán que django levante el servidor durante las pruebas. Estos casos de prueba deberan extender de StaticLiveServerTestCase para que funcione correctamente. Sí, además, queremos hacer uso de la funcionalidad que nos daba BaseTestCase, crearemos un atrbuto para ello:

<source>
from django.test import TestCase
from django.contrib.staticfiles.testing import StaticLiveServerTestCase

from selenium import webdriver
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.keys import Keys

from base.tests import BaseTestCase

class AdminTestCase(StaticLiveServerTestCase):

def setUp(self):
#Load base test functionality for decide
self.base = BaseTestCase()
self.base.setUp()

options = webdriver.ChromeOptions()
options.headless = True
self.driver = webdriver.Chrome(options=options)

super().setUp()

def tearDown(self):
super().tearDown()
self.driver.quit()

self.base.tearDown()

...
</source>

Se ha marcado la opcion ''headless'' para que Chrome no se abra visualmente y así pueda ser ejecutado en servidores sin interfaz gráfica. Si eliminamos esa línea, veremos como Chrome se abre y se navega por el sistema decide.

Un método para comprobar que un login es correcto, sería:

<source>
def test_simpleCorrectLogin(self):
self.driver.get(f'{self.live_server_url}/admin/')
self.driver.find_element(By.ID,'id_username').send_keys("admin")
self.driver.find_element(By.ID,'id_password').send_keys("qwerty",Keys.ENTER)

print(self.driver.current_url)
#In case of a correct loging, a element with id 'user-tools' is shown in the upper right part
self.assertTrue(len(self.driver.find_elements(By.ID,'user-tools'))==1)

</source>

[[link3]]
* '''Importante''' estos tests los podemos ejecutar desde dentro del propio sistema django o bien implementarlos para ejecutarlos de manera autonoma

'''Ejercicio 3'''

Implementar un test para comprobar el correcto funcionamiento al introducir un login incorrecto

'''Ejercicio 4'''

Implementar un test para crear una pregunta.

'''Ejercicio 5'''

Para crear scripts con navegaciones más largas y complejas, podemos descargar e instalar la extensión de selenium para nuestro navegador y registrar así los diferentes pasos de nuestra prueba y, posteriormente, integrarlo dentro de nuestra prueba en Python:

* [[Archivo:selenium-ide.png||500px]]
* Grabar una prueba para realizar un login correcto.
[[Archivo:selenium-record.png||500px]]
* Replicar la prueba

* Integrarlo dentro de nuestra clase en Python

Pruebas del Modelo 22-23

2022-10-03T10:35:59Z

Ajramirez: Página creada con « Las pruebas unitarias están destinadas a identificar errores en partes pequeñas de código con la idea de maximizar la cobertura de nuestros tests. Recordar que la funci...»

Las pruebas unitarias están destinadas a identificar errores en partes pequeñas de código con la idea de maximizar la cobertura de nuestros tests. Recordar que la función de cobertura de las pruebas es algo que debemos decidir. Los tests de cada módulo se implementan en archivos python que comienzan por test*

'''Ejercicio 1'''

Lo primero que vamos a hacer es crear un nuevo test para el modulo de autenticación de decide donde en vez de probar la aplicación, comprobaremos que la suma de dos enteros es correcta.
'''Nota''' esta prueba es para familiarizarnos con el framework. Aquí no estamos probando nuestra app Django.

<source>
from django.test import TestCase
class SimpleTest(TestCase):
def test_basic_addition(self):
"""
Tests that 1 + 1 always equals 2.
"""
self.assertEqual(1 + 1, 2)
</source>

Para ejecutar los tests deberemos ejecutar ./manage.py test authentication.

'''Ejercicio 2'''

Para probar la cobertura de nuestras pruebas usaremos la aplicación coverage:

<source>
$ pip install coverage
</source>

Para lanzar el analisis de cobertura:
<source>
coverage run --source . ./manage.py test -v 2
</source>
Añadimos la opción "--source ." para sólo analizar nuestro código de decide pero no las bibliotecas incluidas.
Añadimos la opción "-v 2" para hacer la salida más verbosa, es decir, ver más información sobre los tests.
Podemos añadir la opción "--keepdb" para evitar que la base de datos de prueba se borre al finalizar. Entre otras cosas, eso evitará que se tenga que crear la base de datos la próxima vez que vayan a correrse los test.
<source>
coverage html
</source>
Finalmente podemos ver el contenido del html abriendo "decide/htmlcov/index.html"

'''Ejercicio 3'''
Pensar los tests que necesitaremos para nuestro proyecto decide.

Pruebas unitarias 22-23

2022-10-03T10:35:30Z

Pruebas de software 22-23

2022-10-03T10:35:07Z

Ajramirez:

Link2

2022-10-03T10:34:02Z

Ajramirez:

<syntaxhighlight lang="python">
def testCreateVotinAPI(self):
self.login()
data = {
'name': 'Example',
'desc': 'Description example',
'question': 'I want a ',
'question_opt': ['cat', 'dog', 'horse']
}

response = self.client.post('/voting/', data, format='json')
self.assertEqual(response.status_code, 201)

voting = Voting.objects.get(name='Example')
self.assertEqual(voting.desc, 'Description example')
</syntaxhighlight>

Link3

2022-10-03T10:33:07Z

Ajramirez: Página creada con «<syntaxhighlight lang="python"> from pyexpat import model from django.test import TestCase from django.contrib.staticfiles.testing import StaticLiveServerTestCase from sel...»

<syntaxhighlight lang="python">
from pyexpat import model
from django.test import TestCase
from django.contrib.staticfiles.testing import StaticLiveServerTestCase

from selenium import webdriver
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.keys import Keys

from base.tests import BaseTestCase
from voting.models import Question, Voting

class AdminTestCase(StaticLiveServerTestCase):

def setUp(self):
#Load base test functionality for decide
self.base = BaseTestCase()
self.base.setUp()

options = webdriver.ChromeOptions()
options.headless = False
self.driver = webdriver.Chrome(options=options)

super().setUp()

def tearDown(self):
super().tearDown()
self.driver.quit()

self.base.tearDown()

def test_simpleVisualizer(self):
q = Question(desc='test question')
q.save()
v = Voting(name='test voting', question=q)
v.save()
response =self.driver.get(f'{self.live_server_url}/visualizer/{v.pk}/')
vState= self.driver.find_element(By.TAG_NAME,"h2").text
self.assertTrue(vState, "Votación no comenzada")

def test_simpleCorrectLogin(self):
self.driver.get(f'{self.live_server_url}/admin/')
self.driver.find_element(By.ID,'id_username').send_keys("admin")
self.driver.find_element(By.ID,'id_password').send_keys("qwerty",Keys.ENTER)

print(self.driver.current_url)
#In case of a correct loging, a element with id 'user-tools' is shown in the upper right part
self.assertTrue(len(self.driver.find_elements(By.ID,'user-tools'))==1)
</syntaxhighlight>

Pruebas de las Vistas 21-23

2022-10-03T10:30:31Z

Ajramirez:

Pruebas de las Vistas 21-23

2022-10-03T10:30:10Z

Ajramirez:

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

= Prerrequisitos =

* Ver video de presentación aquí: [https://videos.us.es/media/P2-+Pruebas/1_kj0hbxrx aquí]
* Instrucciones para la descarga Chrome y el webdriver de Chrome:
<source>
sudo apt-get install chromium-browser chromium-chromedriver
</source>
* Código del script de Python para probar el funcionamiento de Selenium:
<source>
from selenium import webdriver
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC

options = webdriver.ChromeOptions()
options.headless = True
driver = webdriver.Chrome(options=options)
driver.get("https://www.google.com/")
print('Title: %s' % driver.title)
driver.quit()

</source>

Ajustes en la base de datos -> [[Tips and tricks]]

= Automatizando Pruebas =
La estructura de Django se divide en vistas, modelos, plantillas principalmente. En esta práctica veremos como testear cada una de las partes de django así como ejecutar las pruebas de carga del mismo. Para lanzar las pruebas Django utiliza el framework de pruebas unittest el cual esta inspirado en Junit. Estas pruebas se ejecutarán con el comando:

[[Archivo:django-arch.png|400px]]

<source>
#Corre todos los tests disponibles
$./manage.py test
</source>

<source>
#Corre los tests dentro de “voting”
$./manage.py test voting
</source>

* [[Pruebas unitarias 21-23 | Pruebas unitarias]]
* [[Pruebas del Modelo 21-23 | Pruebas del Modelo]]
* [[Pruebas de las Vistas 21-23 | Pruebas de las Vistas]]
* [[Pruebas de carga 21-23 | Pruebas de carga]]

----

[[Archivo:02-Decide-Test_2021.pdf]]

----------------------- VISTAS ----------------

Los módulos ofrecen funcionalidad en la vistas (views.py) que necesitan ser probadas. Algunas de esas vistas pueden ser probadas a través de llamada a las API REST que ofrecen. Otrás, sin embargo, ofrecen una vista HTML que tendremos que probar con otros frameworks como Selenium.

= Pruebas de APIs =
Decide tiene implementada una clase para usar como base a la hora de implementar los test de interacción con APIs, BaseTestCase. Esa clase nos ofrece un ''client'' para hacer llamadas REST además de métodos de ''login'' y ''logout'' para simular el ingreso de un usuario en el sistema.

En el siguiente ejemplo podemos ver como se realizar una prueba donde se intenta realizar una acción nula sobre una votación ya creada. El resultado esperado es un 400.

<source>
def test_update_voting_400(self):
v = self.create_voting()
data = {} #El campo action es requerido en la request
self.login()
response = self.client.put('/voting/{}/'.format(v.pk), data, format= 'json')
self.assertEquals(response.status_code, 400)
</source>

'''Ejercicio 1'''

Implemente una prueba que cree una votación a através de su API y la recupere del modelo.

[[link2]]

= Pruebas de navegación =

Selenium es un framework para testing y automatización de acciones web en general que nos permite simular como actuaría un usuario frente a nuestra aplicación[[https://www.seleniumhq.org/]]

En nuestro caso usaremos selenium dada la dificultad de probar las vistas en django. Estas vistas, normalmente, tienen que lidiar con dependencias AJAX, Javascript, etc. para poder ejecutarse normalmente.

Por ejemplo podemos probar si el acceso a la web de login es correcto o no.

'''Ejercicio 2'''

Instalamos selenium
<source> $ pip install selenium </source>
Instalamos, si no lo hemos hecho ya, chromiun y el driver para chromium que se encargará de reproducir el código dentro del navegador
<source>
sudo apt install chromium-browser chromium-chromedriver
</source>

Finalmente, escribimos el código de nuestro test.
Los test de Selenium requerirán que django levante el servidor durante las pruebas. Estos casos de prueba deberan extender de StaticLiveServerTestCase para que funcione correctamente. Sí, además, queremos hacer uso de la funcionalidad que nos daba BaseTestCase, crearemos un atrbuto para ello:

<source>
from django.test import TestCase
from django.contrib.staticfiles.testing import StaticLiveServerTestCase

from selenium import webdriver
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.keys import Keys

from base.tests import BaseTestCase

class AdminTestCase(StaticLiveServerTestCase):

def setUp(self):
#Load base test functionality for decide
self.base = BaseTestCase()
self.base.setUp()

options = webdriver.ChromeOptions()
options.headless = True
self.driver = webdriver.Chrome(options=options)

super().setUp()

def tearDown(self):
super().tearDown()
self.driver.quit()

self.base.tearDown()

...
</source>

Se ha marcado la opcion ''headless'' para que Chrome no se abra visualmente y así pueda ser ejecutado en servidores sin interfaz gráfica. Si eliminamos esa línea, veremos como Chrome se abre y se navega por el sistema decide.

Un método para comprobar que un login es correcto, sería:

<source>
def test_simpleCorrectLogin(self):
self.driver.get(f'{self.live_server_url}/admin/')
self.driver.find_element(By.ID,'id_username').send_keys("admin")
self.driver.find_element(By.ID,'id_password').send_keys("qwerty",Keys.ENTER)

print(self.driver.current_url)
#In case of a correct loging, a element with id 'user-tools' is shown in the upper right part
self.assertTrue(len(self.driver.find_elements(By.ID,'user-tools'))==1)

</source>

[[link3]]
* '''Importante''' estos tests los podemos ejecutar desde dentro del propio sistema django o bien implementarlos para ejecutarlos de manera autonoma

'''Ejercicio 3'''

Implementar un test para comprobar el correcto funcionamiento al introducir un login incorrecto

'''Ejercicio 4'''

Implementar un test para crear una pregunta.

'''Ejercicio 5'''

Para crear scripts con navegaciones más largas y complejas, podemos descargar e instalar la extensión de selenium para nuestro navegador y registrar así los diferentes pasos de nuestra prueba y, posteriormente, integrarlo dentro de nuestra prueba en Python:

* [[Archivo:selenium-ide.png||500px]]
* Grabar una prueba para realizar un login correcto.
[[Archivo:selenium-record.png||500px]]
* Replicar la prueba

* Integrarlo dentro de nuestra clase en Python

Pruebas de las Vistas 21-23

2022-10-03T10:23:26Z

Ajramirez:

Los módulos ofrecen funcionalidad en la vistas (views.py) que necesitan ser probadas. Algunas de esas vistas pueden ser probadas a través de llamada a las API REST que ofrecen. Otrás, sin embargo, ofrecen una vista HTML que tendremos que probar con otros frameworks como Selenium.

= Pruebas de APIs =
Decide tiene implementada una clase para usar como base a la hora de implementar los test de interacción con APIs, BaseTestCase. Esa clase nos ofrece un ''client'' para hacer llamadas REST además de métodos de ''login'' y ''logout'' para simular el ingreso de un usuario en el sistema.

En el siguiente ejemplo podemos ver como se realizar una prueba donde se intenta realizar una acción nula sobre una votación ya creada. El resultado esperado es un 400.

<source>
def test_update_voting_400(self):
v = self.create_voting()
data = {} #El campo action es requerido en la request
self.login()
response = self.client.put('/voting/{}/'.format(v.pk), data, format= 'json')
self.assertEquals(response.status_code, 400)
</source>

'''Ejercicio 1'''

Implemente una prueba que cree una votación a através de su API y la recupere del modelo.

[[link2]]

= Pruebas de navegación =

Selenium es un framework para testing y automatización de acciones web en general que nos permite simular como actuaría un usuario frente a nuestra aplicación[[https://www.seleniumhq.org/]]

En nuestro caso usaremos selenium dada la dificultad de probar las vistas en django. Estas vistas, normalmente, tienen que lidiar con dependencias AJAX, Javascript, etc. para poder ejecutarse normalmente.

Por ejemplo podemos probar si el acceso a la web de login es correcto o no.

'''Ejercicio 2'''

Instalamos selenium
<source> $ pip install selenium </source>
Instalamos, si no lo hemos hecho ya, chromiun y el driver para chromium que se encargará de reproducir el código dentro del navegador
<source>
sudo apt install chromium-browser chromium-chromedriver
</source>

Finalmente, escribimos el código de nuestro test.
Los test de Selenium requerirán que django levante el servidor durante las pruebas. Estos casos de prueba deberan extender de StaticLiveServerTestCase para que funcione correctamente. Sí, además, queremos hacer uso de la funcionalidad que nos daba BaseTestCase, crearemos un atrbuto para ello:

<source>
from django.test import TestCase
from django.contrib.staticfiles.testing import StaticLiveServerTestCase

from selenium import webdriver
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.keys import Keys

from base.tests import BaseTestCase

class AdminTestCase(StaticLiveServerTestCase):

def setUp(self):
#Load base test functionality for decide
self.base = BaseTestCase()
self.base.setUp()

options = webdriver.ChromeOptions()
options.headless = True
self.driver = webdriver.Chrome(options=options)

super().setUp()

def tearDown(self):
super().tearDown()
self.driver.quit()

self.base.tearDown()

...
</source>

Se ha marcado la opcion ''headless'' para que Chrome no se abra visualmente y así pueda ser ejecutado en servidores sin interfaz gráfica. Si eliminamos esa línea, veremos como Chrome se abre y se navega por el sistema decide.

Un método para comprobar que un login es correcto, sería:

<source>
def test_simpleCorrectLogin(self):
self.driver.get(f'{self.live_server_url}/admin/')
self.driver.find_element(By.ID,'id_username').send_keys("admin")
self.driver.find_element(By.ID,'id_password').send_keys("qwerty",Keys.ENTER)

print(self.driver.current_url)
#In case of a correct loging, a element with id 'user-tools' is shown in the upper right part
self.assertTrue(len(self.driver.find_elements(By.ID,'user-tools'))==1)

</source>

[https://hdvirtual.us.es/discovirt/index.php/s/3tg2CwNyT3X22nq test_selenium.py]
* '''Importante''' estos tests los podemos ejecutar desde dentro del propio sistema django o bien implementarlos para ejecutarlos de manera autonoma

'''Ejercicio 3'''

Implementar un test para comprobar el correcto funcionamiento al introducir un login incorrecto

'''Ejercicio 4'''

Implementar un test para crear una pregunta.

'''Ejercicio 5'''

Para crear scripts con navegaciones más largas y complejas, podemos descargar e instalar la extensión de selenium para nuestro navegador y registrar así los diferentes pasos de nuestra prueba y, posteriormente, integrarlo dentro de nuestra prueba en Python:

* [[Archivo:selenium-ide.png||500px]]
* Grabar una prueba para realizar un login correcto.
[[Archivo:selenium-record.png||500px]]
* Replicar la prueba

* Integrarlo dentro de nuestra clase en Python

Pruebas de las Vistas 21-23

2022-10-03T10:22:33Z

Ajramirez: Página creada con «Página_Principal -> 2022/2023 -> Prácticas - 22/23 = Prerrequisitos = * Ver video de presentación aquí: [https://videos.us.es/media/P2-+Pruebas/1_kj0hbxrx...»

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

= Prerrequisitos =

* Ver video de presentación aquí: [https://videos.us.es/media/P2-+Pruebas/1_kj0hbxrx aquí]
* Instrucciones para la descarga Chrome y el webdriver de Chrome:
<source>
sudo apt-get install chromium-browser chromium-chromedriver
</source>
* Código del script de Python para probar el funcionamiento de Selenium:
<source>
from selenium import webdriver
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC

options = webdriver.ChromeOptions()
options.headless = True
driver = webdriver.Chrome(options=options)
driver.get("https://www.google.com/")
print('Title: %s' % driver.title)
driver.quit()

</source>

Ajustes en la base de datos -> [[Tips and tricks]]

= Automatizando Pruebas =
La estructura de Django se divide en vistas, modelos, plantillas principalmente. En esta práctica veremos como testear cada una de las partes de django así como ejecutar las pruebas de carga del mismo. Para lanzar las pruebas Django utiliza el framework de pruebas unittest el cual esta inspirado en Junit. Estas pruebas se ejecutarán con el comando:

[[Archivo:django-arch.png|400px]]

<source>
#Corre todos los tests disponibles
$./manage.py test
</source>

<source>
#Corre los tests dentro de “voting”
$./manage.py test voting
</source>

* [[Pruebas unitarias 21-23 | Pruebas unitarias]]
* [[Pruebas del Modelo 21-23 | Pruebas del Modelo]]
* [[Pruebas de las Vistas 21-23 | Pruebas de las Vistas]]
* [[Pruebas de carga 21-23 | Pruebas de carga]]

----

[[Archivo:02-Decide-Test_2021.pdf]]

----------------------- VISTAS ----------------

Los módulos ofrecen funcionalidad en la vistas (views.py) que necesitan ser probadas. Algunas de esas vistas pueden ser probadas a través de llamada a las API REST que ofrecen. Otrás, sin embargo, ofrecen una vista HTML que tendremos que probar con otros frameworks como Selenium.

= Pruebas de APIs =
Decide tiene implementada una clase para usar como base a la hora de implementar los test de interacción con APIs, BaseTestCase. Esa clase nos ofrece un ''client'' para hacer llamadas REST además de métodos de ''login'' y ''logout'' para simular el ingreso de un usuario en el sistema.

En el siguiente ejemplo podemos ver como se realizar una prueba donde se intenta realizar una acción nula sobre una votación ya creada. El resultado esperado es un 400.

<source>
def test_update_voting_400(self):
v = self.create_voting()
data = {} #El campo action es requerido en la request
self.login()
response = self.client.put('/voting/{}/'.format(v.pk), data, format= 'json')
self.assertEquals(response.status_code, 400)
</source>

'''Ejercicio 1'''

Implemente una prueba que cree una votación a através de su API y la recupere del modelo.

[[link2]]

= Pruebas de navegación =

Selenium es un framework para testing y automatización de acciones web en general que nos permite simular como actuaría un usuario frente a nuestra aplicación[[https://www.seleniumhq.org/]]

En nuestro caso usaremos selenium dada la dificultad de probar las vistas en django. Estas vistas, normalmente, tienen que lidiar con dependencias AJAX, Javascript, etc. para poder ejecutarse normalmente.

Por ejemplo podemos probar si el acceso a la web de login es correcto o no.

'''Ejercicio 2'''

Instalamos selenium
<source> $ pip install selenium </source>
Instalamos, si no lo hemos hecho ya, chromiun y el driver para chromium que se encargará de reproducir el código dentro del navegador
<source>
sudo apt install chromium-browser chromium-chromedriver
</source>

Finalmente, escribimos el código de nuestro test.
Los test de Selenium requerirán que django levante el servidor durante las pruebas. Estos casos de prueba deberan extender de StaticLiveServerTestCase para que funcione correctamente. Sí, además, queremos hacer uso de la funcionalidad que nos daba BaseTestCase, crearemos un atrbuto para ello:

<source>
from django.test import TestCase
from django.contrib.staticfiles.testing import StaticLiveServerTestCase

from selenium import webdriver
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.keys import Keys

from base.tests import BaseTestCase

class AdminTestCase(StaticLiveServerTestCase):

def setUp(self):
#Load base test functionality for decide
self.base = BaseTestCase()
self.base.setUp()

options = webdriver.ChromeOptions()
options.headless = True
self.driver = webdriver.Chrome(options=options)

super().setUp()

def tearDown(self):
super().tearDown()
self.driver.quit()

self.base.tearDown()

...
</source>

Se ha marcado la opcion ''headless'' para que Chrome no se abra visualmente y así pueda ser ejecutado en servidores sin interfaz gráfica. Si eliminamos esa línea, veremos como Chrome se abre y se navega por el sistema decide.

Un método para comprobar que un login es correcto, sería:

<source>
def test_simpleCorrectLogin(self):
self.driver.get(f'{self.live_server_url}/admin/')
self.driver.find_element(By.ID,'id_username').send_keys("admin")
self.driver.find_element(By.ID,'id_password').send_keys("qwerty",Keys.ENTER)

print(self.driver.current_url)
#In case of a correct loging, a element with id 'user-tools' is shown in the upper right part
self.assertTrue(len(self.driver.find_elements(By.ID,'user-tools'))==1)

</source>

[https://hdvirtual.us.es/discovirt/index.php/s/3tg2CwNyT3X22nq test_selenium.py]
* '''Importante''' estos tests los podemos ejecutar desde dentro del propio sistema django o bien implementarlos para ejecutarlos de manera autonoma

'''Ejercicio 3'''

Implementar un test para comprobar el correcto funcionamiento al introducir un login incorrecto

'''Ejercicio 4'''

Implementar un test para crear una pregunta.

'''Ejercicio 5'''

Para crear scripts con navegaciones más largas y complejas, podemos descargar e instalar la extensión de selenium para nuestro navegador y registrar así los diferentes pasos de nuestra prueba y, posteriormente, integrarlo dentro de nuestra prueba en Python:

* [[Archivo:selenium-ide.png||500px]]
* Grabar una prueba para realizar un login correcto.
[[Archivo:selenium-record.png||500px]]
* Replicar la prueba

* Integrarlo dentro de nuestra clase en Python