Objetivo 9: Despliegue de una aplicación en un PaaS

Descripción

Hacer un despliegue en la nube, usando una Plataforma como Servicio, del proyecto que se esté desarrollando.

Prerrequisitos

Haber alcanzado el 60% de los objetivos del tema correspondiente tras haber realizado los ejercicios propuestos. Haber superado el hito anterior de la práctica.

Explicación

El principal objetivo de esta práctica es familiarizarse con este tipo de infraestructura virtual que se puede usar de forma válida para un lanzamiento inicial de un producto web (o una aplicación que tenga un backoffice en la web) y, subsidiariamente, familiarizarse con las técnicas usadas para desplegar aplicaciones desde un repositorio web. Un PaaS puede soportar todo un negocio donde la infraestructura sea común y esté bien soportada, pero también se puede usar para despliegue rápido, sobre todo en el tier gratuito. Y aunque la idea inicial del mismo es soportar pilas monolíticas, también se puede usar para microservicios como los que vemos en esta asignatura.

El despliegue real, y la definición del mismo, van un paso más allá del usado en integración continua en el uso de infraestructura virtual, y usa las herramientas de construcción e infraestructura definida para lanzar y testear el microservicio. No sólo hay que pasar los tests (y con ello haber definido las dependencias) sino que hay que levantar los servicios, el stack que se vaya a usar y también expresar las dependencias que hay entre ellos, la secuencia de despliegue. Un PaaS simplifica todo esto levantando los servicios, siempre que estén dentro de una pila o conjunto determinado, por sí solos. En general, a lo que se usa en el CI se añadirá soporte para almacenamiento de datos y, adicionalmente, logs.

También se plantea como objetivo el saber seleccionar el PaaS gratuito, o de pago pero gratuito durante un tiempo o para un nivel determinado, más adecuado para las necesidades de la aplicación que se va a hacer. El PaaS tiene que cumplir dos requisitos:

A efectos de evaluación, la configuración debe definirse en un fichero que describa la infraestructura virtual. Se puede hacer o bien usando algún lenguaje o fichero de configuración que provea el PaaS, o bien mediante encadenamiento de órdenes del toolbelt que use. En ambos casos se tendrá que especificar claramente en la documentación de proyecto los pasos seguidos. El objetivo de esta parte es que una persona que se dé de alta y esté autorizada a usar ese PaaS pueda, usando ese fichero de configuración o secuencia de comandos, reproducir la infraestructura y desplegar el mismo proyecto. Si el PaaS sólo permite configuración desde la web, no sería válido.
Que permita despliegue directo desde el repositorio, es decir, que se pueda desde GitHub y la herramienta de integración continua creada el despliegue simplemente haciendo push desde el repositorio. La configuración de este despliegue se tendrá que documentar en el directorio docs del repositorio.

En esta práctica, desde la herramienta que se use en el PaaS para lanzar la infraestructura se tendrán que hacer uso de las órdenes que se hayan creado en las prácticas anteriores, es decir, xxx start donde xxx es el task runner que se haya elegido. De esta forma te aseguras que se ejecuta de la misma forma como se hace localmente.

El énfasis de esta práctica es en el despliegue y eso es lo que se va a evaluar, pero no hay que perder de vista que es el cuarto hito de un proyecto y a estas alturas ya debería de tener alguna funcionalidad mínima (y que esa funcionalidad tendrá que estar testeada). Esto se tendrá en cuenta en la aplicación. También el resto de los hitos siguen presentes: se tendrá que seguir usando un sistema basado en issues e hitos, evitar ficheros que no tengan que estar en el repo, y todas las buenas prácticas que han sido objetivo desde el principio. Especialmente se tendrá en cuenta que la cobertura de las funciones usadas en el proyecto sea lo suficientemente alta.

Entrega de la práctica

Subir los fuentes a GitHub y hacer un pull request al documento que describa las prácticas con el nombre habitual.

Se tendrá que incluir lo siguiente en el fichero iv.yaml para la evaluación:

Clave PaaS con el URL a donde se haya desplegado. Se comprobará que https://url-declarado/status devuelve { status: "OK" }.
El test comprobará adicionalmente que los recursos funcionen directamente, creando un recurso y accediendo a continuación al mismo. Este recurso se declarará de la forma siguiente

recurso:
    nombre: nombre-del-recurso
    metodo: <será PUT o POST)>
    payload: <hash en formato YAML que habrá que pasar en el body>
    IDs:
        - ID1
        - ID2
        - ID3

Esto último se hará solo en caso de que el recurso se cree con PUT. Lo que se va a hacer en el test es lo siguiente

En el payload se interpretarán los valores según su apariencia. Es decir, un id = 33 se interpretará como un número y no una cadena. Si el framework que uséis es fuertemente tipificado y no le gusta recibir una cadena como un número (o viceversa), por favor usad valores que no parezcan numéricos.
Una o varias peticiones PUT a los URIs indicados, en cualquier orden, o varias peticiones POST.
Las peticiones POST y PUT se harán usando application/json en la cabecera.
Tanto los PUT como los POSTs deberán devolver, en la cabecera Location, el URI del recurso creado.
Estos URIs devueltos tendrán los IDs indicados más abajo, por orden. Es decir, a la primera petición se devolverá un URI que incluirá el primer ID y así sucesivamente. Se harán como máximo tantas peticiones como IDs haya en el caso de usar PUT, 4 peticiones en el caso de que se use POST.
A continuación se harán una o varias peticiones GET a los recursos creados, en cualquier orden (y posiblemente en paralelo). Se comprobará que se devuelve el mismo resultado.

Por ejemplo, supongamos que vamos a crear un recurso con hitos de la asignatura. Habrá que añadir a iv.yaml algo así:

PaaS: una-url-de.herokuapp.com
recurso:
    nombre: hitos
    metodo: PUT
    payload:
        descripcion: Un hito de esos
        fecha: 20/03/1975
    IDs:
        - 1.Hito
        - 2.Hito

Se usará siempre la misma payload. Como los IDs son diferentes, será conveniente que no se rompa con eso. En este caso se hará una petición sobre http://una-url-de.herokuapp.com/hitos/1.Hito con el payload indicado, y se comprobará que el Location devuelto sea el mismo que se ha usado en PUT.

En el propio repositorio de la aplicación, la explicación del proyecto deberá incluir los criterios usados para elegir el PaaS y sus diferentes opciones y una explicación de cómo funciona la aplicación y de los pasos llevados a cabo para crearla. En el fichero README.md comentar sólo lo relativo al proyecto, las explicaciones en una documentación aparte. Se recuerda que este fichero sólo debe incluir el estado en el que esté la aplicación en ese momento, y que información adicional que se haya enviado en hitos anteriores y que ya no sea relevante es mejor que se traslade (y se enlace) desde el mismo.

Subobjetivos a alcanzar

Descripción y justificación de las herramientas usadas para desplegar la aplicación en en PaaS.
Descripción correcta de la configuración para despliegue automático, desde el repositorio o desde el sistema de integración continua.
Funcionamiento correcto del despliegue en el PaaS (no sólo el status). Es decir, no se puede devolver ningún status 500.
Uso correcto de bases de datos y logs dentro del PaaS, incluyendo su justificación y pruebas de prestaciones, así como avance general y grado de terminación de la aplicación.

Si la aplicación no funciona o hay plagio o trabajo en común, la práctica estará suspensa.

Valoración

Este objetivo cubrirá el 10% de la valoración de la asignatura.