Fondo
Si leíste mi blog anterior sobre los indicadores de características , sabrás qué herramienta tan poderosa son.
Sin embargo, agregar indicadores de características hace que su código sea más difícil de leer y mantener a medida que se expanden las matrices de prueba.
Este blog presenta un proceso sencillo de desarrollo y ciclo de vida de indicadores de características para mitigar estos desafíos complejos. Este proceso lo guía a través de todas las etapas de los indicadores de características: planificación y diseño, prueba, producción, monitoreo y etapa de retiro.
Si bien los ejemplos de código están escritos en Python, los conceptos que describo son los mismos para cualquier SDK de indicadores de características escrito en cualquier lenguaje de programación que elija.
Para obtener un proyecto Python completo y funcional que se implementa en AWS AppConfig y utiliza indicadores de funciones en tiempo de ejecución, haga clic aquí .
Propiedad
Creo que el equipo de desarrollo es dueño del proceso de indicadores de características desde el principio hasta el final.
El equipo y su líder deben implementar la característica y gestionarla durante todo su ciclo de vida.
El equipo de desarrollo es la fuente de verdad para el diseño, ya que tiene la mejor comprensión de los efectos secundarios de las características, la implementación, los puntos de falla y cómo superarlos.
Bucle infinito de CI/CD
Planificar, codificar y construir
Una vez que una nueva característica planificada se considera suficientemente importante o riesgosa, se debe considerar habilitarla a través de una bandera de característica.
La implementación más sencilla es un único punto de ejecución con una única instrucción " if-else ". Considere el siguiente ejemplo de pseudocódigo:
¿Cómo se implementa 'get_my_feature_flag'?
Presenté una implementación para obtener y evaluar indicadores de características en mi serie de blogs AWS Lambda Cookbook. Se basa en AWS AppConfig y AWS Lambda Powertools .
En ese blog también se describe cómo separar el indicador de función de la secuencia de funciones de AWS Lambda, lo que la hace verdaderamente dinámica. Un indicador de función dinámico le permite cambiar rápidamente el comportamiento de su función de AWS Lambda sin tener que volver a implementar la función. Lea más sobre la configuración estática y dinámica aquí .
Tenga en cuenta que cualquier solución de terceros también funciona. Elija la solución que mejor se adapte a sus necesidades.
Prueba
La mayoría de las personas centran sus pruebas en el caso de uso obvio: habilitar la función y probar la nueva lógica que la rodea: verificar que la lógica empresarial se gestione correctamente y que los efectos secundarios sean los esperados. También se asegurarán de que la cobertura del código se mantenga lo más alta posible si son minuciosos.
Sin embargo, también es fundamental verificar que la lógica de la función NO se ejecute cuando el valor del indicador de la función sea Falso . Esto puede parecer obvio , pero ejecutar la lógica de una función cuando su indicador esté configurado en Falso puede tener resultados terribles. Puede deberse a errores en el código o casos extremos.
Pruebas de integración/unidad con simulacros
Las pruebas en este ejemplo se ejecutan localmente y no en AWS, ya que utilizan simulaciones de Pytest .
En el siguiente ejemplo, se prueba ' my_handler ' cuando ' my_feature ' está habilitado.
El controlador se llama con un evento generado y una función simulada ' get_my_feature_flag '. Aunque la prueba se ejecuta localmente con simulacros de Pytest, el controlador puede llamar a servicios reales y no solo a simulacros. Defina simulacros y valores de retorno que simulen los casos extremos de la prueba.
Las líneas 8 a 9 habilitan la función.
La línea 11 activa el controlador Lambda con un evento simulado.
En las líneas 12 y 13, la prueba verifica que la salida del controlador y los efectos secundarios de la función (cuando está habilitada) sean los exceptuados.
Y ahora, la prueba se vuelve a ejecutar pero la función se deshabilita de forma simulada:
La función está deshabilitada en las líneas 8 y 9.
La prueba verifica en la línea 14 que el punto de entrada del controlador de indicadores de características no se llama por error.
De hecho, la función está deshabilitada ya que solo tiene un ÚNICO punto de ejecución.
Pruebas E2E
Como regla general, las pruebas E2E no se deben utilizar para probar la lógica de un solo indicador de característica.
Las pruebas simuladas anteriores ya han probado la lógica del indicador de función.
Las pruebas E2E solo pueden simular los flujos "felices" de todo el servicio, ya que es difícil crear fallas en los servicios de AWS Serverless donde no se tiene el control total de la infraestructura. Por ese motivo, los casos extremos y las fallas simuladas se prueban antes de la etapa E2E en las etapas de pruebas unitarias y de integración como pruebas adicionales a los ejemplos de pruebas anteriores.
Creo que cuando una bandera de función está " deshabilitada ", se espera que todas las pruebas E2E pasen y sirvan como una línea base de " prueba de cordura" . También verifican que el SDK de banderas de función funcione como se espera y que evalúe el valor de la bandera de función correctamente.
Sin embargo, una vez que se habilita la función en el entorno " dev ", algunas pruebas E2E pueden fallar. Esta falla sugiere que las pruebas simuladas no detectaron un caso extremo o de uso.
Corrija las pruebas simuladas según corresponda y continúe con el siguiente paso: lanzar e implementar.
Liberar e implementar
Suponiendo que no implementa directamente en producción, sería prudente implementar primero el indicador de función como " deshabilitado " en todos los entornos que no sean " dev ".
Cuando esté listo y pueda probar y depurar, libere el indicador de función en al menos un entorno que simule un entorno de producción real: " staging ".
Esto podría provocar que las pruebas E2E fallen si las pruebas simuladas no detectaron algunos casos extremos. En ese caso, agregue las pruebas faltantes y continúe con la versión.
Lanzamiento a producción
Existen numerosas estrategias de implementación. Elija la que se ajuste a sus necesidades.
Las estrategias de implementación más comunes incluyen " todo a la vez ", "implementación canaria " y " lanzamiento oscuro ".
Lea más sobre las estrategias de implementación para AWS AppConfig aquí .
Lea más sobre Dark Launching en el blog de Martin Fowler.
Monitorear y operar
Una vez que la función esté activa, no habrá vuelta atrás. Si surge un problema, deberá actuar con rapidez:
Deshabilite la bandera de función lo antes posible.
Actualice las pruebas y agregue los casos de uso faltantes.
Implementar y volver a lanzar.
Realice una reunión retrospectiva: intente identificar casos de uso adicionales que se hayan pasado por alto.
¿Pero cómo sé si hay un problema?
El monitoreo depende en gran medida de las características seleccionadas. Yo uso AWS AppConfig.
AWS AppConfig tiene controles de estado automáticos que pueden monitorear cualquier alerta de CloudWatch.
También es posible definir una reversión automática de la configuración si se activa una alerta de AWS CloudWatch. Lea más sobre esto aquí .
Otras soluciones como AWS CloudWatch proporcionan evidentemente gráficos e información sobre la bandera de implementación habilitada.
Recuerde que definir alertas de AWS CloudWatch que monitoreen el estado y la salud de su servicio se considera una buena práctica, independientemente del uso de los indicadores de funciones.
Plan para jubilarse
Las características son potentes y adictivas . Sin embargo, cuanto más se agregan, la complejidad del código y la sobrecarga de las pruebas aumentan.
Sin embargo, no estás vinculado para siempre a esas características.
Está bien y es recomendable darles el 'hacha' una vez que alcanzan la madurez y la estabilidad.
El principio fundamental aquí es la visibilidad . Asegúrese de poder ver TODOS los indicadores de características en TODAS sus cuentas de AWS en una sola vista. Debe comprender el estado completo de los indicadores de características en todas las cuentas de AWS de un vistazo. Si la herramienta que eligió no ofrece esa posibilidad, créela usted mismo. Puede ser un panel simple o una interfaz de usuario simple.
El equipo de desarrollo debe programar una reunión de una hora por mes para revisar el estado actual de las características y decidir qué características se pueden retirar.
Aquí están mis reglas generales para seleccionar un candidato adecuado para la jubilación:
La función se ha implementado para el 100 % de los clientes durante "X" semanas. Use el sentido común para definir "X".
La función ha sido estable durante 'X' semanas: no se conocen problemas ni errores.
Los comentarios de los clientes son positivos y no hay problemas abiertos.
No se espera que la función sufra ninguna refactorización o adición.
Su equipo de producto ya no lo utiliza o cree que es necesario.
Gracias a Roy Ben Yosef , Alon Sadovski , Alexy Grabov y Mauro R
Comments