Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Base de datos del tablero de VTS

Para admitir un panel de integración continua que sea escalable, eficaz y flexible, el backend del panel de 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 consistencia eventual, así como una consistencia sólida dentro de los grupos de entidades. Sin embargo, la estructura es muy diferente a las bases de datos SQL (e incluso a 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 efectivo para el servicio web VTS Dashboard.

Entidades

Las siguientes entidades almacenan resúmenes y recursos de las ejecuciones de prueba 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 fallos, el recuento de aprobados y la lista de casos de prueba rotos desde que se actualizan los trabajos de alerta.
  • Entidad de ejecución de prueba . Contiene metadatos de ejecuciones de una prueba en 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 rama y la información de ABI. Esto se almacena por separado de la entidad de ejecución de prueba para admitir ejecuciones de prueba de varios dispositivos de una manera de uno a varios.
  • Entidad de ejecución de punto de perfilado . Resume los datos recopilados para un punto de perfil particular dentro de una ejecución de prueba. Describe las etiquetas de los ejes, el nombre del punto de generación de perfiles, los valores, el tipo y el modo de regresión de los datos de generación de perfiles.
  • 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 de origen.
  • Entidad de ejecución de caso de prueba . Describe el resultado de un caso de prueba en 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 a partir del servicio de usuario de App Engine. Esto permite una consulta bidireccional eficiente (es decir, para todos los usuarios suscritos a una prueba y para todas las pruebas favorecidas por 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 elementos secundarios de este grupo y padres de las entidades de dispositivo, las entidades de punto de generación de perfiles y las entidades de cobertura relevantes para la prueba y el antecesor de ejecución de prueba respectivos.

Figura 1 . Probar la ascendencia de la entidad.

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 comprometa y que las transacciones del pasado sean visibles para las operaciones actuales. En Cloud Datastore, la agrupación de entidades crea islas de gran 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 uniforme 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 produzcan a una velocidad 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 generalmente toman al menos un minuto, incluida la sobrecarga del marco VTS; a menos que una prueba se ejecute de forma constante y simultánea en más de 60 hosts diferentes, no puede haber un cuello de botella de escritura. Esto se vuelve aún más improbable dado que cada módulo es parte de un plan de prueba que a menudo toma más de una hora. Las anomalías pueden manejarse fácilmente si los hosts ejecutan las pruebas al mismo tiempo, lo que provoca breves ráfagas de escrituras en los mismos hosts (por ejemplo, detectando errores de escritura y volviendo a intentarlo).

Consideraciones de escala

Una ejecución de prueba no necesariamente necesita tener la prueba como su padre (por ejemplo, podría tomar alguna otra clave y tener el nombre de la prueba, la hora de inicio de la prueba como propiedades); sin embargo, esto cambiará una fuerte consistencia por una eventual consistencia. 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 el estado global puede no representar una representación completamente precisa de la secuencia de ejecuciones de prueba. Esto también puede afectar la visualización de las ejecuciones de prueba dentro de un solo módulo de prueba, lo que puede no ser necesariamente una instantánea coherente de la secuencia de ejecución. Eventualmente, la instantánea será consistente, pero no hay garantías de que los datos más recientes sean.

Casos de prueba

Otro cuello de botella potencial son las pruebas grandes con muchos casos de prueba. Las dos restricciones operativas son el rendimiento máximo de escritura 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 antepasado (similar a cómo se almacenan los datos de cobertura, los datos de creación de perfiles y la información del dispositivo):

Figura 2 . Los casos de prueba descienden de las ejecuciones de prueba (NO SE RECOMIENDA).

Si bien este enfoque ofrece atomicidad y consistencia, impone fuertes limitaciones a las pruebas: si una transacción está limitada a 500 entidades, entonces una prueba no puede tener más de 498 casos de prueba (asumiendo que no hay cobertura o datos de perfil). Si una prueba superara esto, entonces una sola transacción no podría escribir todos los resultados del caso 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 elementos secundarios de la ejecución de prueba, los casos de prueba se pueden almacenar de forma independiente y sus claves se proporcionan a la ejecución de prueba (una ejecución de prueba contiene una lista de identificadores para sus entidades de casos de prueba):

Figura 3 . Casos de prueba almacenados de forma independiente (RECOMENDADO).

A primera vista, esto puede parecer que rompe la sólida garantía de consistencia. Sin embargo, si el cliente tiene una entidad de ejecución de prueba y una lista de identificadores de casos de prueba, no necesita construir una consulta; en su lugar, puede obtener directamente los casos de prueba mediante sus identificadores, que siempre se garantiza que sea coherente. Este enfoque alivia enormemente la restricción sobre el número de casos de prueba que puede tener una ejecución de prueba al tiempo que obtiene una gran consistencia sin amenazar la escritura excesiva dentro de un grupo de entidades.

Patrones de acceso a datos

El Panel de VTS utiliza los siguientes patrones de acceso a datos:

  • Favoritos del usuario . Puede consultarse mediante el uso de un filtro de igualdad en las entidades favoritas de los usuarios que tengan el objeto Usuario de App Engine particular como propiedad.
  • Lista de prueba . 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 aprobados y reprobados 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 de la clave (marca de tiempo) y un posible filtrado de las propiedades de ejecución de prueba, como el ID de compilación, el recuento de aprobados, etc. Al realizar una consulta de ancestro con una clave de entidad de prueba, la lectura es muy consistente. En este punto, todos los resultados del caso de prueba se pueden recuperar utilizando la lista de ID almacenada en una propiedad de ejecución de prueba; también se garantiza que esto será un resultado muy consistente por la naturaleza de las operaciones de obtención del almacén de datos.
  • Datos de perfil y cobertura . La consulta de datos de perfil o cobertura asociados con una prueba se puede realizar sin recuperar también otros datos de ejecución de prueba (como otros datos de perfil / cobertura, datos de casos de prueba, etc.). Una consulta de antepasado que utilice las claves de entidad de prueba y ejecución de prueba recuperará todos los puntos de creación de perfiles registrados durante la ejecución de la prueba; al filtrar también por el nombre del punto de generación de perfiles o el nombre del archivo, se puede recuperar una única entidad de generación de perfiles o de cobertura. Por la naturaleza de las consultas de antepasados, 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 la interfaz de usuario del panel de VTS .