Se puede utilizar un tipo de registro de proyecto para realizar el seguimiento de la producción de un release del producto real. Un proyecto puede incluir un nombre de producto, información de release y el conjunto de todas las iteraciones asociadas al proyecto. También puede incluir información de componente para un proyecto.
Cada vez que se modifica el código fuente, la aplicación se compila y se verifica si tiene la calidad suficiente para iniciar la prueba. Una vez que se ha realizado la verificación, la compilación se despliega a los servidores de prueba para la prueba. Este patrón de entrega de cambios de código fuente, compilación de la aplicación y prueba se lleva a cabo independientemente del ámbito o la magnitud de un release (por ejemplo, si se trata de la revisión principal de una aplicación existente, parche o hotfix). Cuando se encuentran errores, se registran los defectos y se modifica el código fuente para arreglar el defecto y, de nuevo, se debe construir la aplicación y desplegar en los servidores de prueba para la prueba.
Los registros Baseline y Build de ALM se pueden utilizar tanto en proyectos en los que se utilicen integraciones de Gestión unificada de cambios (UCM) de IBM Rational ClearCase/ClearQuest, como en aquellos en los que no se utilicen dichas integraciones. Los registros Baseline y Build también se pueden utilizar para garantizar la entrega satisfactoria de proyectos y releases de productos o de información a los clientes. Por ejemplo, los registros Baseline y Build pueden permitir la transferencia automatizada de información de desarrollo a prueba, e informar a los verificadores sobre las compilaciones de productos que contienen los arreglos para solicitudes específicas.
En este patrón, todas las actividades están relacionadas. A medida que los desarrolladores implementan la funcionalidad y arreglan defectos, los ingenieros de release deben conocer el origen a incluir en la compilación o cuándo realizar la compilación (es decir, cuándo se va a completar todo el trabajo esperado). Cuando surgen problemas con la compilación, los ingenieros de release deben identificar si la causa del problema se encuentra en el script de compilación en sí mismo o se debe a algún otro error debido al equipo de desarrollo. Al mismo tiempo, los verificadores deben saber si una compilación es adecuada para la prueba, la funcionalidad que se ha incluido en la compilación y las pruebas que se deben ejecutar en dicha compilación. Cada vez que se informa sobre un defecto, se deben conocer los casos de prueba que han revelado el defecto, además de las referencias al requisito original. Y, cuando el desarrollador arregla el defecto y entrega el código, se vuelve a iniciar el ciclo.
En proyectos de desarrollo de software, las compilaciones se suceden constantemente. Las preguntas comunes para los equipos de desarrollo son sobre lo que se ha implementado en la compilación y lo que se ha probado en la compilación. El registro Build permite que los equipos capturen información sobre cada compilación, incluido el estado de la misma. El registro Baseline permite realizar el seguimiento de las actividades que se entregan en cada compilación y se puede utilizar para capturar el estado de las actividades en un momento determinado. El uso de los registros Baseline, Build y Activity permite que los desarrolladores sepan lo que deben probar y realicen el seguimiento de las pruebas que se han ejecutado con respecto a la compilación.