ALM en un entorno ClearQuest MultiSite

Los tipos de registro basados en rol de un esquema ALM permiten un desarrollo más efectivo distribuido globalmente. Un equipo de usuarios puede trabajar en registros específicos asociados con una solicitud o tarea basada en sus roles, lo que evita conflictos si varios usuarios deben actualizar el mismo registro.

Además de ayudar a establecer un sistema de gestión de cambios basado en rol, un flujo de trabajo común también puede ayudar a direccionar las solicitudes de réplica y maestría en un entorno distribuido. Por ejemplo, si un usuario inicia la sesión en una réplica que reside en Bangalore, cuando el usuario crea una nueva tarea, la tarea se controla en el lugar en que está ubicado el propietario desarrollador. La tarea se crea en el sitio de Bangalore y, a continuación, se replica. El propietario desarrollador predeterminado determina la maestría de la tarea inicial, independientemente de dónde se controle la solicitud. Tenga en cuenta que:
  • Para que sea visible, una solicitud se debe replicar en todos los sitios.
  • Una solicitud contiene referencias a las tareas asociadas, y las tareas contienen una referencia a la solicitud.
  • Una vez que se abre la tarea, cada tarea se controla en el sitio del propietario desarrollador predeterminado y, una vez que se activa la tarea, ésta se controla en el sitio del QE Lead.
  • Una vez que se abre o envía, la actividad para una tarea asociada se controla en el sitio del propietario. El desarrollador asignado es el propietario de la actividad de desarrollador. Un valor de campo de proyecto, componente o subcomponente puede determinar el propietario desarrollador predeterminado, que es el propietario de la actividad de evaluación de documentos, y el propietario QE predeterminado es el propietario de la actividad de prueba.

El paradigma de flujo de trabajo de ALM proporciona soporte para desarrollo distribuido paralelo. Por ejemplo, las tareas creadas para gestionar solicitudes pueden ser revisadas para ver su progreso por parte de los solicitantes cuando las actividades de desarrollo están en estado Complete, pero no cuando están Tested o Assessed for documentation. Algunas actividades de desarrollor pueden tener el estado Completed y otras Opened al tiempo que se realizan las pruebas en el trabajo que ya esté completo hasta la fecha.

La clasificación de registros en un clan MultiSite no se puede realizar de forma que los usuarios que ejecutan la misma consulta en diferentes sitios vean la misma secuencia de registros si los campos de clasificación en una consulta tienen más de un registro con la misma clave de clasificación o valores de clave de clasificación concatenados. Por ejemplo, si clasifica por nombre y dos registros tienen el mismo nombre, es posible que los usuarios de cada sitio no vean los dos registros en la misma secuencia en ambos sitios. Si utiliza el ID de registro como un segundo campo de clasificación, tenga en cuenta que los ID son bloques asignados de ID que es posible que no reflejen el orden de los registros que se están enviando. Si utiliza filtros de historial (History.action_name in ('Copy_Record, 'Import')OR History.old_state = 'no_value'), puede obtener el primer registro History para cualquier registro para la clasificación a fin de encontrar la secuencia absoluta en la que dos registros cualesquiera entran en un clan. Puede utilizar History.expiration_timestamp IS NULL para obtener el último History.Action.


Comentarios