Integración Continua y Despliegue Continuo

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

Clase grabada

• Video de la clase

Prerrequisitos

• Ver video de presentación aquí: aquí
• El archivo .travis.yml ha de añadir esta configuración al final

deploy:
  provider: heroku
  app: <<your app name>>
  strategy: git
  api_key: <<your api key>>

Preparación para Integración y Despliegue Continuo

En esta práctica recrearemos un despliegue completo en el cual una vez realicemos commit a nuestro repositorio Github, Travis se encargará de ejecutar las pruebas y en caso de que pase las pruebas el mismo se encargará de desplegar la versión commiteada a Heroku.

Para la realización de esta práctica es recomendable haber realizado con anterioridad las prácticas de automatización de pruebas y de despliegue en Heroku.

Para Heroku

• Actualizamos el fichero requirements para permitir el despliegue y la correcta ejecución de las pruebas

django-heroku
gunicorn

• Preparamos y añadimos al repositorio el Procfile para Heroku

% prepara el repositorio para su despliegue. 
release: sh -c 'cd decide && python manage.py migrate'
% especifica el comando para lanzar Decide
web: sh -c 'cd decide && gunicorn decide.wsgi --log-file -'

• Introducimos los cambios pertinentes en el fichero decide/decide/settings.py para establecer los valores por defecto de la configuración de despliegue en Heroku.

...

BASEURL = 'http://heroku-meet-travis.herokuapp.com'

APIS = {
    'authentication': BASEURL,
    'base': BASEURL,
    'booth': BASEURL,
    'census': BASEURL,
    'mixnet': BASEURL,
    'postproc': BASEURL,
    'store': BASEURL,
    'visualizer': BASEURL,
    'voting': BASEURL,
}

...
import django_heroku
django_heroku.settings(locals())

Al hacer esto, la configuración por defecto ya sólo será útil para el despliegue en Heroku. En Travis no funcionará si no le definimos un local_settings.py específico.

Para Travis

• Creamos un fichero para guardar los valores del settings para travis (i.e $git$/decide/travis_local_settings.py)

ALLOWED_HOSTS = ["*"]

# Modules in use, commented modules that you won't use
MODULES = [
    'authentication',
    'base',
    'booth',
    'census',
    'mixnet',
    'postproc',
    'store',
    'visualizer',
    'voting',
]

APIS = {
    'authentication': 'http://localhost:8000',
    'base': 'http://localhost:8000',
    'booth': 'http://localhost:8000',
    'census': 'http://localhost:8000',
    'mixnet': 'http://localhost:8000',
    'postproc': 'http://localhost:8000',
    'store': 'http://localhost:8000',
    'visualizer': 'http://localhost:8000',
    'voting': 'http://localhost:8000',
}

BASEURL = 'http://localhost:8000'

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'postgres',
        'USER': 'postgres',
        'HOST': 'localhost',
        'PORT': '5432',
    }
}

# number of bits for the key, all auths should use the same number of bits
KEYBITS = 256

• Preparamos el fichero .travis.yml que, entre otras cosas, establece el settings anterior como la configuración a utilizar

dist: xenial
services:
- postgresql
addons:
  postgresql: '9.4'
before_script:
- psql -U postgres -c "create user decide password 'decide'"
- psql -U postgres -c "create database test_decide owner decide"
- psql -U postgres -c "ALTER USER decide CREATEDB"
language: python
python:
- '3.6'
install:
- pip install -r requirements.txt
script:
- cd decide
- cp travis_local_settings.py local_settings.py
- coverage run --branch --source=. ./manage.py test --keepdb
deploy:
  provider: heroku
  app: <<your app name>>
  strategy: git
  apikey: <your apikey>>

Para que la duración de los builds de Travis sea más corta, puede especificarse que sólo se ejecuten los tests de uno de los módulos, por ejemplo, el mixnet:

... ./manage.py test mixnet ...

• Creamos nuestra app de heroku desde la interfaz o con la instrucción:

heroku create <<app-name>>

• Con el siguiente build de Travis ya deberíamos observar que la aplicación está corriendo automáticamente en Heroku.

Ejercicios

Ejercicio 0: Ciclo de vida del build

1. Introduzca algún error en las pruebas del mixnet (o de otro módulo que esté probándose en Travis)
2. Compruebe que Travis se encuentra con dicho error
3. ¿Se realiza el despliegue en Heroku?´

Ejercicio 1: Encriptación de la api key de Heroku

1. Eliminar la variable de entorno en Travis donde se puso la api key de Heroku (se hizo en los prerrequisitos) y eliminar la linea del .travis.yml con la apikey de heroku.

2. Instalar Travis CLI en nuestro entorno

 //Quizás sea necesario instalar ruby-dev $ sudo apt install ruby-dev
  $ sudo gem install travis --no-document
 //Debería funcionar esta instrucción $ travis version

3. Dentro de la raiz de nuestro repositorio, ingresamos nuestras credenciales de acceso en Travis con un token de nuestra cuenta de GitHub con el scope de 'repo':

 $ travis login --pro --github-token <<token de github>>

4. Dentro de la raiz de nuestro repositorio, añadimos al api key encriptada al .travis con (debemos tener instalado el Heroku CLI como ya se hizo en los prerrequisistos de la práctica de PaaS):

  $ travis encrypt $(heroku auth:token) --add deploy.api_key --pro

Nos dará la opción de escribir los cambios en el propio .travis.yml.

5. Subimos los cambios al repositorio

6. ¿Se ha conectado correctamente Travis con Heroku?

Ejercicio 2. Condiciones de despliegue

En Travis podemos especificar diferentes condiciones a la hora de hacer un despliegue. En este ejercicio indicaremos una aplicación de Heroku diferente en función de la rama del repositorio.

1. Modificar el .travis.yml añadiendo la condicion on: a nuestro deploy de la siguiente manera.

...
deploy:
   provider: heroku
   app: egc-app-decide-prod
   strategy: git
   api_key: 
     secure: <<encrypted apikey>>
   on:
     branch: master

Con esto haremos que solo los cambios en la rama master se desplieguen en la aplicación de Heroku.

2. Añadamos un segundo despliegue (añadiendo el - delante de provider, podemos añadir cuantos despliegues queramos) con otra condición para que los cambios en la rama experimental (deberá crear esa rama) vayan a otra aplicación de Heroku diferente (deberá crear dicha aplicación en Heroku):

deploy:
  - provider: heroku
    app: egc-app-decide-prod
    ...
  - provider: heroku
    app: egc-app-decide-pre
    strategy: git
    api_key: 
      secure: <<la misma encrypted apikey>>
    on:
      branch: <<Rama nueva experimental>>

3. Haga cambios en la rama nueva experimental

4. ¿Se ha modificado la aplicación original en Heroku?

Ejercicio 3. Incidencias

1. Probar la app como hicimos en la práctica de Heroku
2. Crear una incidencia según las recomendaciones vistas en clase para el error que obtenemos al votar en heroku.