Planificar los procesos de compilación, pruebas y control de calidad
Esta unidad revisa los procesos de desarrollo que puede utilizar para administrar los procesos de compilación, prueba y control de calidad. También proporciona información sobre cómo planificar la gestión de estos procesos.
Crear un plan de proyecto para compilaciones
Dependiendo de la metodología que elija, debe seleccionar los horarios y las ubicaciones de las compilaciones. También debe decidir en qué orden se producen las compilaciones. Por ejemplo, no es recomendable compilar el código del entorno de desarrollo en el entorno de producción sin pasar primero por el entorno de pruebas.
También debe pensar en cómo gestionar el desarrollo que no pasa las pruebas, porque ese desarrollo debe revertirse. Esto evita que se promuevan errores. Puede usar Microsoft Dynamics 365 Lifecycle Services para administrar su compilación entre entornos.
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 hacer lo siguiente:
- Decidir la finalidad del entorno. Pensar en 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 Microsoft 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. Debe usar este entorno 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. El sistema proporciona estos entornos en diferentes momentos.
- Entorno de nivel 2: durante el proceso de instalación.
- Entorno de desarrollo y prueba de nivel 1: cuando comienza la fase de diseño y después de configurar Microsoft Azure DevOps.
- Entorno de producción: 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. Además, los entornos de nivel 1 también se pueden implementar como un entorno hospedado en la nube o una imagen de entorno. Los clientes o partners administran los entornos hospedados en la nube. La imagen del entorno es un entorno local que utiliza un disco duro virtual.
Puede seleccionar qué entornos necesita y cuándo los necesita. Debe 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, debe decidir cómo evaluar el desarrollo para su aprobación, quién lo evalúa, qué criterios se utilizan para la aprobación y cómo realizar un seguimiento de las pruebas. Puede 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 ejecutan una prueba en 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 podría hacer pruebas de rendimiento del sistema para asegurarse de que este sea estable. Para ello, es necesario que varios usuarios entre en el sistema y lleven a cabo procesos pesados y de gran volumen. Gracias a esto, puede detectar maneras de mejorar el rendimiento.
Las aplicaciones de finanzas y operaciones incluyen la herramienta Grabador de tareas para documentar los pasos del proceso de un usuario. Con Microsoft Azure DevOps, puede vincular tareas a una solución de proyecto de desarrollo. Luego, puede utilizar la tarea para hacer un seguimiento de actualizaciones, documentos de prueba y otras notas.
Control de código fuente y control de calidad para desarrolladores
A veces, puede que varios desarrolladores estén trabajando en aplicaciones de finanzas y operaciones al mismo tiempo. Para evitar que los desarrolladores se interfieran entre sí, puede configurar el control de código fuente con un proyecto de Azure DevOps.
El proyecto de Azure DevOps hospeda 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á indicando al sistema que está realizando cambios. Al volver a insertar el objeto, el sistema crea una nueva versión de ese objeto.
El control de versiones le permite ver cambios anteriores que alguien ha hecho. 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, lo 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 los procedimientos recomendados de Microsoft Dynamics 365 X++. Además, es posible que desee desarrollar sus propios procedimientos recomendados, como convenciones de nomenclatura, para mantener todo el desarrollo estandarizado en la organización.
Seleccionar un sistema de control de versiones
En las aplicaciones de finanzas y operaciones, un sistema de control de versiones es obligatorio. Azure DevOps admite tanto el control de versiones de Team Foundation (TFVC) como Git.
Control de versiones de Team Foundation de Azure DevOps
El sistema de control de versiones de Team Foundation de Azure DevOps es un sistema de control de versiones único para aplicaciones de finanzas y operaciones. Es un sistema de control de versiones centralizado, lo que significa que los desarrolladores trabajan en una rama y tienen una versión de cada archivo en sus máquinas de desarrollo. Cada rama pertenece a un espacio de trabajo del servidor y cada desarrollador trabaja en un espacio de trabajo local. Cuando un desarrollador inserta código fuente, debe asegurarse de insertar la última versión y resolver cualquier conflicto.
De forma predeterminada, los repositorios de TFVC están desactivados en el área Configuración de la organización de Azure DevOps. Debe activar los repositorios antes de poder crear un nuevo proyecto de Azure DevOps con TFVC como sistema de control de versiones.
Para activar el control de versiones de Team Foundation (TFVC) en su organización, siga estos pasos:
- Abra Azure DevOps yendo a dev.azure.com/<su organización>.
- Seleccione Configuración de la organización en la esquina inferior izquierda del panel.
- Abra Repos > Repositorios.
- Desactive la alternancia Deshabilitar la creación de repositorios TFVC en la sección Todas las configuraciones de repositorio.
Puede crear nuevos proyectos de Azure DevOps con TFVC como el sistema de control de versiones.
Git
Git es el sistema de control de versiones recomendado y predeterminado de Microsoft para el desarrollo.
TFVC es un sistema de control de versiones centralizado, mientras que Git es un sistema distribuido. Cada desarrollador tiene su propia copia de un repositorio de origen (o rama ligera) y puede realizar cambios en él. Los desarrolladores pueden crear nuevas ramas privadas y cambiar de una rama a otra. En TFVC, es más difícil cambiar de una rama a otra y, a menudo, se necesitan varios entornos de desarrollo.
Es importante tener en cuenta que puede migrar de TFVC a Git y viceversa.