Planificar los procesos de compilación, pruebas y control de calidad
Esta unidad revisa los procesos de desarrollo que se utilizan para administrar los procesos de compilación, prueba y control de calidad, y proporciona información sobre cómo planificar la administración de estos procesos.
Crear un plan de proyecto para compilaciones
Dependiendo de la metodología que elija, deberá seleccionar los horarios y las ubicaciones de las compilaciones. También deberá decidir en qué orden se producirán las compilaciones. Por ejemplo, no querrá compilar el código del entorno de desarrollo en el entorno de producción sin pasar primero por el entorno de pruebas.
También deberá considerar cómo gestionar el desarrollo que no pasa las pruebas, porque ese desarrollo deberá revertirse. Esto evitará que se promuevan errores. Puede usar Lifecycle Services para ayudar a administrar su compilación de un entorno a otro.
Por ejemplo, una compilación puede revertir cualquier código con errores del entorno de prueba al entorno de desarrollo, promover el código correcto de prueba a producción y finalmente promover el código terminado del entorno de desarrollo a prueba.
Decidir qué entornos son necesarios
La elección de los entornos debe planificarse al comienzo de la implementación. Al planificar los entornos, debe:
- Decidir la finalidad del entorno Considerar si los entornos se utilizarán para desarrollo, pruebas del sistema, pruebas de aceptación de usuario (UAT) u operaciones
- Considerar la topología del entorno, como Desarrollar o Compilar y probar
- Considerar el nivel del entorno (nivel 1 o 2)
Un entorno de nivel 1 es un entorno de caja única con todos los componentes instalados en el mismo servidor. Un entorno de nivel 1 utiliza Microsoft SQL Server y está estructurado para maximizar la eficiencia del desarrollo. Este nivel no es una buena opción para UAT o pruebas de rendimiento.
Un entorno de nivel 2 o más es un entorno de caja múltiple con componentes que se instalan en varios servidores. En lugar de Microsoft SQL Server, los entornos de nivel 2 usan Azure SQL Database. La arquitectura en este entorno es la misma que la del entorno de producción, pero no utiliza la recuperación ante desastres. Este entorno debe usarse para UAT y pruebas de rendimiento.
La oferta estándar para entornos en la nube incluye un entorno de nivel 1 para desarrollo y pruebas, un entorno de nivel 2 para UAT y un entorno de producción. Estos entornos se proporcionan en diferentes momentos. El nivel 2 se proporciona durante la incorporación. El entorno de desarrollo y prueba de nivel 1 se proporciona cuando comienza la fase de diseño y Microsoft Azure DevOps ha sido configurado. Finalmente, el entorno de producción se proporciona durante la preparación del sistema de producción con Microsoft. Este entorno debe solicitarse a través de Lifecycle Services.
También puede agregar otro entorno complementario para los entornos de nivel 1 y nivel 2 si es necesario. Los entornos de nivel 1 también se pueden implementar como un entorno hospedado en la nube o una imagen de entorno. El cliente o partner administra los entornos hospedados en la nube. La imagen del entorno es un entorno local que utiliza un disco duro virtual.
Puede elegir qué entornos necesitará y cuándo los necesitará. Deberá resumir las listas de entornos requeridos en una matriz para Microsoft.
Puede utilizar el plan de entorno como ayuda con el fin de seleccionar el flujo para la compilación de código en todos sus entornos y para estructurar su ALM.
Planificar cuántas pruebas se requieren
Al implementar las aplicaciones de finanzas y operaciones, deberá decidir cómo evaluar el desarrollo para su aprobación, quién lo evaluará, qué criterios se utilizarán para la aprobación y cómo realizar un seguimiento de las pruebas. Se pueden usar pruebas unitarias, pruebas de regresión y pruebas de rendimiento para probar el sistema.
Las pruebas unitarias son útiles para probar si funciona un componente específico de la funcionalidad. Las pruebas unitarias no verifican si el nuevo código afecta las funciones existentes del sistema.
La prueba de regresión ejecuta una prueba contra un proceso completo para asegurarse de que las características existentes aún funcionan con el nuevo desarrollo. Por ejemplo, si se realiza una modificación para agregar funcionalidad relacionada con los clientes, es posible que desee realizar pruebas de regresión para asegurarse de que la nueva funcionalidad no interfiera con la funcionalidad existente, como los pedidos de ventas.
También es posible que desee considerar la prueba de rendimiento del sistema para asegurarse de que el sistema sea estable haciendo que varios usuarios entren en el sistema y realicen procesos fiscales de gran volumen. Esto puede ayudar a encontrar oportunidades para mejorar el rendimiento.
Las aplicaciones de finanzas y operaciones incluyen la herramienta Grabador de tareas para documentar los pasos de un proceso que realiza un usuario. Azure DevOps también permite vincular tareas a una solución de proyecto de desarrollo. La tarea se puede utilizar para realizar un seguimiento de actualizaciones, documentos de prueba y otras notas.
Control de código fuente y control de calidad para desarrolladores
Ocasionalmente, varios desarrolladores pueden estar trabajando en aplicaciones de finanzas y operaciones al mismo tiempo. Para evitar que los desarrolladores interfieran con el trabajo de los demás, el control de código fuente se puede configurar con un proyecto de Azure DevOps.
Este proyecto hospedará el código fuente del modelo, lo que permite a los usuarios insertar y extraer objetos en el repositorio. Al extraer un objeto del repositorio, le está diciendo al sistema que está haciendo cambios. Al volver a insertar el objeto en el repositorio, el sistema crea una nueva versión de ese objeto.
El control de versiones permite ver qué cambios se realizaron anteriormente. Puede deshacer los cambios pendientes que se han insertado en el repositorio más recientemente. Además, puede seleccionar Obtener más reciente en los objetos, que extrae la versión más reciente del objeto insertada en el repositorio. Los desarrolladores deben usar esta característica regularmente para asegurarse de que estén usando el código más actualizado.
Para garantizar la calidad en el desarrollo, siga las prácticas recomendadas de Microsoft Dynamics X++. Además, es posible que desee desarrollar sus propias prácticas recomendadas, como las convenciones de nomenclatura, para mantener todo el desarrollo estandarizado en la organización.