Todos los programas deben tener una serie de servicios: los registros de actividad (logs) y el uso de configuración, posiblemente distribuida, son fundamentales.
Haber superado los tests del objetivo anterior.
Todas las aplicaciones en la red tienen que usar una serie de servicios, pero dos de ellos son fundamentales. La configuración, siguiendo los principios SOLID, debe estar en el entorno, y por lo tanto deben usarse servicios que lo permitan. Y la actividad de una aplicación tiene que ser observable, así que tendrán que registrarla, sea normal o errónea.
En el primer caso, la configuración tiene que incluir diferentes posibles niveles de la misma, desde configurar desde línea de órdenes hasta usar sistemas de configuración remota, depósitos clave-valor distribuidos que permitan, a diferentes copias de un mismo servicio, compartir todos los elementos de configuración pertinentes, desde rutas y direcciones IP hasta claves de diferentes servicios. Relacionado con "la configuración esa en el entorno", uno de los principios de los "12 factores", eventualmente se trata de dotar a nuestras aplicaciones de una serie de funcionalidades que permitan fácilmente desplegar la aplicación, y diferentes copias de un microservicio, donde sea menester.
Por otro lado, el registro de actividad se plasma en el uso de bibliotecas de registro o log, y el uso extensivo de la misma para registrar toda la actividad, especialmente la errónea, pero también actividad relacionada con el usuario que permita, incluso de forma automática, escalar servicios horizontal o verticalmente para servir mejor al usuario.
En este objetivo habrá, por tanto, que añadir estas dos funcionalidades a la aplicación, justificando la elección de los servicios e integrando esta funcionalidad dentro del desarrollo normal de la aplicación, usando issues y también integrándolo en un PMV.
Un concepto fundamental en estos casos de servicios externos es el de inyección de dependencias. Cuando una clase depende de cualquier servicio externo, el acoplamiento entre una y otra debe ser lo más "suelto" posible, de forma que en el diseño de la aplicación se pueda cambiar de ese servicio externo simplemente cambiando la implementación de la clase. En los dos casos, la inyección de dependencias implica crear un objeto que encapsule la funcionalidad que necesitamos de los mismos, que será inyectado en los objetos de la clase para que puedan usarlo adecuadamente.
En el caso de los sistemas de log, muchos lenguajes lo incorporan ya en su biblioteca estándar, o incluyen en su biblioteca estándar alguna forma de configurarlos con diferentes opciones. Siempre, tanto en un caso como en otro, habrá que llevar a cabo una serie de elecciones sobre las herramientas que se van a usar, y justificarlo dentro de la documentación de este objetivo.
Del curso 0 se puede consultar el material sobre servicios avanzados en informática.
La configuración es un ejemplo de dependencia que debe estar desacoplada, por lo que se aconseja que se mire el tema de inversión de dependencias.
* [ ] ¿Se han registrado todos los eventos relevantes en la aplicación, es decir, se
han añadido comandos para registrarlos en todos ellos?
* [ ] ¿Se han seguido buenas prácticas en el uso de configuración remota?
* [ ] ¿Se han explicado correctamente las decisiones técnicas que se han tomado
sobre las bibliotecas usadas?
* [ ] ¿Te has asegurado de que el fichero `.env` no se pueda añadir
accidentalente al repositorio?
* [ ] ¿Los logs y la configuración están en un objeto que se *inyecta* en las
clases manejadoras para su uso?
* [ ] ¿*Realmente* se usan los logs en las diferentes clases en eventos
importantes?
* [ ] ¿Se testea el código creado para logs y configuración, igual que
cualquier otro código?
* [ ] ¿La clase o módulo de configuración lee *siempre* las variables de entorno?Subir los fuentes a GitHub y hacer un pull request al
fichero de este
objetivo. En
el fichero iv.yaml habrá que añadir la clave configuracion que use como
valor el fichero en el que se haya abstraído la configuración de la aplicación.
También se comprobará que se ha configurado .gitignore para que no se añada
nunca un fichero de configuración al repo.
Se tendrán que alcanzar los siguientes objetivos
- Entender las buenas prácticas en la configuración de aplicaciones en la nube, incluyendo la seguridad.
- Integrar los sistemas de registro para permitir observabilidad del comportamiento de un sistema.
- Entender cuando y cuánto es necesario registrar la actividad de una aplicación.
- Comprender el concepto de inyección de dependencias.
El alcanzar este objetivo avanzará, en principio, 10% de la puntuación de este apartado.
¡Has llegado muy lejos! Puedes avanzar al penúltimo objetivo de la asignatura.