Para admitir un panel de integración continua que sea escalable, eficaz y flexible, el backend del panel VTS debe diseñarse cuidadosamente con una sólida comprensión de la funcionalidad de la base de datos. Google Cloud Datastore es una base de datos NoSQL que ofrece garantías ACID transaccionales y coherencia eventual, así como una sólida coherencia dentro de los grupos de entidades. Sin embargo, la estructura es muy diferente a la de las bases de datos SQL (e incluso a la de Cloud Bigtable); en lugar de tablas, filas y celdas hay tipos, entidades y propiedades.
Las siguientes secciones describen la estructura de datos y los patrones de consulta para crear un backend eficaz para el servicio web VTS Dashboard.
Entidades
Las siguientes entidades almacenan resúmenes y recursos de ejecuciones de pruebas de VTS:
- Entidad de prueba . Almacena metadatos sobre ejecuciones de prueba de una prueba en particular. Su clave es el nombre de la prueba y sus propiedades incluyen el recuento de fallas, el recuento de aprobaciones y la lista de fallos de casos de prueba desde que los trabajos de alerta lo actualizan.
- Entidad de ejecución de prueba . Contiene metadatos de ejecuciones de una prueba particular. Debe almacenar las marcas de tiempo de inicio y finalización de la prueba, el ID de compilación de la prueba, el número de casos de prueba aprobados y fallidos, el tipo de ejecución (por ejemplo, preenvío, posenvío o local), una lista de enlaces de registro, el host. nombre de la máquina y recuentos de resumen de cobertura.
- Entidad de información del dispositivo . Contiene detalles sobre los dispositivos utilizados durante la ejecución de prueba. Incluye el ID de compilación del dispositivo, el nombre del producto, el destino de compilación, la sucursal y la información ABI. Esto se almacena por separado de la entidad de ejecución de prueba para admitir ejecuciones de prueba en múltiples dispositivos de uno a muchos.
- Entidad de ejecución de punto de generación de perfiles . Resume los datos recopilados para un punto de generación de perfiles particular dentro de una ejecución de prueba. Describe las etiquetas de los ejes, el nombre del punto de perfilado, los valores, el tipo y el modo de regresión de los datos de perfilado.
- Entidad de Cobertura . Describe los datos de cobertura recopilados para un archivo. Contiene la información del proyecto Git, la ruta del archivo y la lista de recuentos de cobertura por línea en el archivo fuente.
- Entidad de ejecución de caso de prueba . Describe el resultado de un caso de prueba particular de una ejecución de prueba, incluido el nombre del caso de prueba y su resultado.
- Entidad de favoritos del usuario . Cada suscripción de usuario se puede representar en una entidad que contiene una referencia a la prueba y el ID de usuario generado desde el servicio de usuario de App Engine. Esto permite realizar consultas bidireccionales eficientes (es decir, para todos los usuarios suscritos a una prueba y para todas las pruebas favoritas de un usuario).
Agrupación de entidades
Cada módulo de prueba representa la raíz de un grupo de entidades. Las entidades de ejecución de prueba son hijas de este grupo y padres de entidades de dispositivo, entidades de punto de perfilado y entidades de cobertura relevantes para la prueba respectiva y el antecesor de ejecución de prueba.
Punto clave: al diseñar relaciones de ascendencia, debe equilibrar la necesidad de proporcionar mecanismos de consulta eficaces y coherentes con las limitaciones impuestas por la base de datos.
Beneficios
El requisito de coherencia garantiza que las operaciones futuras no verán los efectos de una transacción hasta que se confirme, y que las transacciones del pasado sean visibles para las operaciones presentes. En Cloud Datastore, la agrupación de entidades crea islas de sólida coherencia de lectura y escritura dentro del grupo, que en este caso son todas las ejecuciones de prueba y los datos relacionados con un módulo de prueba. Esto ofrece los siguientes beneficios:
- Las lecturas y actualizaciones del estado del módulo de prueba mediante trabajos de alerta se pueden tratar como atómicas.
- Vista consistente garantizada de los resultados de los casos de prueba dentro de los módulos de prueba.
- Consultas más rápidas dentro de los árboles de ascendencia
Limitaciones
No se recomienda escribir en un grupo de entidades a una velocidad superior a una entidad por segundo, ya que algunas escrituras pueden rechazarse. Siempre que los trabajos de alerta y la carga no se realicen a un ritmo superior a una escritura por segundo, la estructura es sólida y garantiza una gran coherencia.
En última instancia, el límite de una escritura por módulo de prueba por segundo es razonable porque las ejecuciones de prueba suelen tardar al menos un minuto, incluida la sobrecarga del marco VTS; A menos que una prueba se ejecute consistentemente y simultáneamente en más de 60 hosts diferentes, no puede haber un cuello de botella en la escritura. Esto resulta aún más improbable dado que cada módulo forma parte de un plan de prueba que a menudo lleva más de una hora. Las anomalías se pueden manejar fácilmente si los hosts ejecutan las pruebas al mismo tiempo, provocando breves ráfagas de escritura en los mismos hosts (por ejemplo, detectando errores de escritura e intentando nuevamente).
Consideraciones de escala
Una ejecución de prueba no necesita necesariamente tener la prueba como padre (por ejemplo, podría tomar alguna otra clave y tener el nombre de la prueba y la hora de inicio de la prueba como propiedades); sin embargo, esto cambiará una fuerte coherencia por una eventual coherencia. Por ejemplo, es posible que el trabajo de alerta no vea una instantánea mutuamente coherente de las ejecuciones de prueba más recientes dentro de un módulo de prueba, lo que significa que es posible que el estado global no represente una representación completamente precisa de la secuencia de ejecuciones de prueba. Esto también puede afectar la visualización de ejecuciones de prueba dentro de un único módulo de prueba, que puede no ser necesariamente una instantánea consistente de la secuencia de ejecución. Con el tiempo, la instantánea será consistente, pero no hay garantías de que los datos más recientes lo sean.
Casos de prueba
Otro posible cuello de botella son las pruebas grandes con muchos casos de prueba. Las dos restricciones operativas son el rendimiento de escritura máximo dentro de un grupo de entidades de una por segundo, junto con un tamaño máximo de transacción de 500 entidades.
Un enfoque sería especificar un caso de prueba que tenga una ejecución de prueba como antecedente (similar a cómo se almacenan los datos de cobertura, los datos de perfiles y la información del dispositivo):
Si bien este enfoque ofrece atomicidad y coherencia, impone fuertes limitaciones a las pruebas: si una transacción se limita a 500 entidades, entonces una prueba no puede tener más de 498 casos de prueba (suponiendo que no haya cobertura ni datos de perfiles). Si una prueba superara esto, entonces una sola transacción no podría escribir todos los resultados de los casos de prueba a la vez, y dividir los casos de prueba en transacciones separadas podría exceder el rendimiento máximo de escritura del grupo de entidades de una iteración por segundo. Como esta solución no se escalará bien sin sacrificar el rendimiento, no se recomienda.
Sin embargo, en lugar de almacenar los resultados del caso de prueba como hijos de la ejecución de prueba, los casos de prueba se pueden almacenar de forma independiente y se pueden proporcionar sus claves a la ejecución de prueba (una ejecución de prueba contiene una lista de identificadores de sus entidades de casos de prueba):
A primera vista, esto puede parecer que rompe la sólida garantía de coherencia. Sin embargo, si el cliente tiene una entidad de ejecución de prueba y una lista de identificadores de casos de prueba, no necesita crear una consulta; en cambio, puede obtener directamente los casos de prueba mediante sus identificadores, lo que siempre garantiza la coherencia. Este enfoque alivia enormemente la restricción en la cantidad de casos de prueba que puede tener una ejecución de prueba y, al mismo tiempo, gana una fuerte coherencia sin amenazar la escritura excesiva dentro de un grupo de entidades.
Patrones de acceso a datos
El panel VTS utiliza los siguientes patrones de acceso a datos:
- Favoritos del usuario . Se puede consultar mediante el uso de un filtro de igualdad en las entidades favoritas del usuario que tienen el objeto Usuario de App Engine particular como propiedad.
- Listado de pruebas . Consulta simple de entidades de prueba. Para reducir el ancho de banda para representar la página de inicio, se puede usar una proyección en los recuentos de aprobación y falla para omitir la lista potencialmente larga de ID de casos de prueba fallidos y otros metadatos utilizados por los trabajos de alerta.
- Ejecuciones de prueba . La consulta de entidades de ejecución de prueba requiere una clasificación por clave (marca de tiempo) y un posible filtrado de las propiedades de ejecución de prueba, como ID de compilación, recuento de pases, etc. Al realizar una consulta ancestral con una clave de entidad de prueba, la lectura es fuertemente consistente. En este punto, todos los resultados del caso de prueba se pueden recuperar utilizando la lista de ID almacenados en una propiedad de ejecución de prueba; También se garantiza que esto será un resultado muy consistente debido a la naturaleza de las operaciones de obtención del almacén de datos.
- Datos de perfilamiento y cobertura . La consulta de datos de perfil o cobertura asociados con una prueba se puede realizar sin recuperar otros datos de ejecución de prueba (como otros datos de perfil/cobertura, datos de casos de prueba, etc.). Una consulta ancestral que utilice las claves de entidad de prueba y ejecución de prueba recuperará todos los puntos de perfil registrados durante la ejecución de prueba; Al filtrar también por el nombre del punto de perfil o el nombre del archivo, se puede recuperar una única entidad de perfil o cobertura. Por la naturaleza de las consultas de ancestros, esta operación es muy consistente.
Para obtener detalles sobre la interfaz de usuario y capturas de pantalla de estos patrones de datos en acción, consulte Interfaz de usuario del panel VTS .