Cuarto hito: 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.

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.

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.

El servicio web desplegado debe cumplir también un requisito muy importante: debe incluir una ruta /status que devuelva el JSON { "status": "OK" } de forma que se pueda comprobar de forma fehaciente que se ha desplegado de forma correcta. Adicionalmente, puede incluir una clave ‘ejemplo’ con una ruta y de ejemplo y el JSON que devolvería usando las claves indicadas.

{
   "status": "OK",
   "ejemplo": { 
                "ruta": "/ruta/parametro",
                "valor": "{JSON: devuelto}"
              }
}

de forma que se pueda comprobar si el despliegue se ha hecho correctamente y se pueda además comprobar que hay rutas que funcionan correctamente.

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 la práctica anterior, 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 y que se anunciará en la web de la asignatura. La dirección del PaaS en el que se ha desplegado deberá estar claramente indicada, si puede ser en un párrafo aparte, en una línea de sólo texto que incluya la palabra “Despliegue” y un solo URL seguro, de esta forma

Despliegue: https://...

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.

Una vez terminado, se puede hacer este ejercicio para conseguir crédito adicional.

Valoración

• 2 puntos: Descripción correcta del script de configuración del PaaS desde línea de órdenes.
• 2 puntos: Descripción correcta de la configuración de GitHub para despliegue continuo de la aplicación.
• 2 puntos: Funcionamiento correcto del despliegue en el PaaS (no sólo el status). Es decir, no se puede devolver ningún status 500.
• 2 puntos: ficheros de definición y lanzamiento de los servicios en el PaaS correctos.
• 2 puntos: concedidos por originalidad de la aplicación, grado de terminación, utilidad para la asignatura, PaaS elegido, cantidad de trabajo invertido, el hecho que se haya avanzado el proyecto.

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

Se recuerda también que este es un hito de un proyecto, y como tal los tests para este hito incluyen los de todos los anteriores; el proyecto tendrá que seguir desarrollándose de acuerdo a lo indicado en el hito anterior.

Reenvío

Si ya se ha entregado y corregido la práctica y se quiere subir nota, se reenviará siguiendo estas instrucciones.