Hacer un despliegue en la nube, usando una Plataforma como Servicio, del proyecto que se esté desarrollando.
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.
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:
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.
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:
PaaS
con el URL a donde se haya desplegado. Se comprobará
que https://url-declarado/status
devuelve { status: "OK" }
.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
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.application/json
en la
cabecera.Location
, el URI del recurso creado.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.
Si la aplicación no funciona o hay plagio o trabajo en común, la práctica estará suspensa.
Si ya se ha entregado y corregido la práctica y se quiere subir nota, se reenviará siguiendo estas instrucciones.