Antes de pasar una aplicación a producción se deben tener superados unos hitos QA para que pueda ser desplegada en la infraestructura kubernetes del portal de servicios. Éstos hitos deberán ser validados por MNCS de cara a asegurar que las aplicaciones desplegadas se ajustan a los parámetros establecidos para los servicios FundewebJS.
Los grupos desarrolladores deberán proveer las evidencias de QA establecidas en la Metodología de gestión de proyectos de desarrollo en el apartado P9. Gestión de la calidad del software
En esta guía vamos a ampliar y especificar las acciones que son necesarias realizar para garantizar que nuestros servicios pueden desplegarse de manera segura en la infraestructura.
Configuración de la aplicación
Se debe comprobar que la configuración de las variables que usa la aplicación está correctamente establecida en los repositorios de sistemas.
Es importante recordar que los ficheros de configuración que utilizamos en nuestro equipo local no son los que se aplicarán a los despliegues en los diferentes entornos sino los que hay en el repositorio de configuración que provee sistemas para tal fin. Es importante comprobar que toda la configuración necesaria está o bien en esos ficheros.
(configuración variables por entorno en repositorio de sistemas y configuración y uso de lagar)
Revisión vulnerabilidades
(SonarQube)
Test de carga
...
, para ello deberemos seguir el manual Despliegues y configuración de los entornos para garantizar que ubicamos correctamente las propiedades.
También debemos tener claro cómo funcionará Lagar ya que los logs sólo estarán disponibles en esta plataforma, para ello debemos leer el manual 4. Visualización de Logs de FundeWebJS en LAGAR donde se nos explica cómo verlo y el significado de cada una de las propiedades recogidas. También tendremos información sobre cómo incluir nuevos campos en lagar para mejorar el filtrado, no obstante estos campos extras sólo deberán añadirse de manera justificada.
Revisión vulnerabilidades
Una vez tenemos la configuración de nuestra aplicación controlada, debemos asegurar que nuestro código fuente no contiene errores que puedan provocar problemas durante su ejecución. Para ello debemos asegurar que en el servidor SonarQube no hay ni vulnerabilidades ni bugs, en el caso de que creamos que sean un falso positivo, comunicar con MNCS para que lo valide y elimine del proyecto.
También debemos reducir los Code Smells lo máximo posible evitando cualquier mala práctica que haya en el código. En proyectos nuevos debemos asegurar que las subidas de código nuevo no empeoran el código ya existente para no ir incrementando la deuda técnica.
Seguridad en APIs Rest
Los backend FundewebJS al ser sin estado deben tener un especial control sobre todas sus APIs ya que están expuestas a internet y cualquiera puede utilizarlas. No sólo hay que proteger que un usuario no autenticado acceda a una parte de la aplicación que no debe, sino que los usuarios que están autenticados no realizan ninguna acción que no deban.
Para evitar cualquier agujero de seguridad, las API Rest de nuestras aplicaciones deben documentarse dentro del espacio de Confluence donde se trate dicha aplicación o servicio o bien en el espacio del propio grupo si la aplicación no tiene uno propio. Se deberá rellenar la siguiente tabla para verificar que las APIs están protegidas.
| URL API | Requiere login | Recibe Form Data | Acciones |
|---|---|---|---|
| Url de la api incluyendo los header param | Si requiere login | Si recibe datos del frontend |
|
Test de carga
Una vez securizada y revisada la API deberemos realizar los test de carga pertinentes para confirmar que la infraestructura soporta de manera correcta las peticiones y la concurrencia que pudiera tener el sistema. Para ello deberemos preparar un test de carga en local que sea repetible y representativo, es decir que no requiera dar de alta de manera manual datos durante el proceso y que realice operaciones lo más pesadas posibles.
Una vez preparado el test de carga lo ejecutaremos una primera vez en local para medir tanto los tiempos de respuesta como el uso de memoria. En este punto es muy importante comprobar que el uso de memoria permanece estable en el test de 40/60 min, de no ser así tendremos que solucionar los problemas en la aplicación antes de realizar el siguiente paso.
Si tenemos ya un uso de memoria estable y unos tiempos medios menores de 3 segundos coordinaremos con sistemas (poniéndoles un Jira a DJ-AT-SIST-MIDDLE ) para realizar la prueba contra la infraestructura. Una vez terminada la prueba y revisados los resultados, si entran dentro de los valores normales consideraremos esta tarea superada.
Accesibilidad
Por último, antes de poner nuestra aplicación y/o servicio en producción deberemos asegurarnos que tenemos los documentos y análisis realizados para garantizar la accesibilidad de nuestra aplicación y estar conforme al real decreto Real Decreto 1112/2018.
| Info |
|---|
|
