Diferencia entre revisiones de «Ejercicio 1: CI/CD de decide»

De Wiki de EGC
Saltar a: navegación, buscar
(Página creada con «Página_Principal -> 2021/2022 -> Prácticas - 21/22 -> [Integración_Continua_y_Despliegue_Continuo_21-22] = Decide con GitHub Actions = El archivo django.ym...»)
 
 
Línea 1: Línea 1:
[[Página_Principal]] -> [[2021/2022]] -> [[Prácticas - 21/22]] -> [Integración_Continua_y_Despliegue_Continuo_21-22]
+
[[Página_Principal]] -> [[2021/2022]] -> [[Prácticas - 21/22]] -> [[Integración_Continua_y_Despliegue_Continuo_21-22]]
  
 
= Decide con GitHub Actions =
 
= Decide con GitHub Actions =
Línea 11: Línea 11:
  
 
El job "deploy" se lanza sin esperar a que termine build. Para que solo se lance si el job anterior acaba satisfactoriamente añadamos la clausula "need":
 
El job "deploy" se lanza sin esperar a que termine build. Para que solo se lance si el job anterior acaba satisfactoriamente añadamos la clausula "need":
<source>
+
<syntaxhighlight lang="YAML">
 
deploy:
 
deploy:
 
     needs: build
 
     needs: build
</source>
+
</syntaxhighlight>
 
 
 
Haz un push y observa la ejecución del workflow.
 
Haz un push y observa la ejecución del workflow.
 
* ¿Se lanzan los dos jobs?
 
* ¿Se lanzan los dos jobs?
 
* ¿Está correctamente desplegada la aplicación en Heroku?
 
* ¿Está correctamente desplegada la aplicación en Heroku?

Revisión actual del 13:43 14 dic 2021

Página_Principal -> 2021/2022 -> Prácticas - 21/22 -> Integración_Continua_y_Despliegue_Continuo_21-22

Decide con GitHub Actions

El archivo django.yml ofrecido prepara el entorno, prueba decide, reporta a Codacy y despliega en Heroku. Está compuesto por dos jobs.

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:

  1. La configuración completa ha de estar en el settings.py. Esto, normalmente, si hemos hecho la práctica de heroku lo tendremos bien.
  2. Como no se está haciendo uso de local_settings, la configuración de la base de datos escrita en el django.yml deberá coincidir con la que esté puesta en el settings.py.
  3. Hay un test que puede fallar llamado "test_multiple_auths_mock" dentro del módulo Mixnet. Si falla, debería anularse ese test.

El job "deploy" se lanza sin esperar a que termine build. Para que solo se lance si el job anterior acaba satisfactoriamente añadamos la clausula "need":

deploy:
    needs: build

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

  • ¿Se lanzan los dos jobs?
  • ¿Está correctamente desplegada la aplicación en Heroku?