Recomendaciones para estandarizar herramientas y procesos
Se aplica a esta recomendación de lista de comprobación de excelencia operativa del marco de trabajo bien diseñado de Azure:
OE:04 | Optimice los procesos de desarrollo de software y control de calidad mediante procedimientos aprobados del sector para desarrollo y pruebas. Para una designación de roles inequívoca, normalice las prácticas entre componentes, como herramientas, control de código fuente, patrones de diseño de aplicaciones, documentación y guías de estilo. |
---|
Guía relacionada: Mejora de la velocidad | de compilación Uso de la integración continua
En esta guía se describen las recomendaciones para definir estándares para herramientas y procesos de desarrollo de software. La definición de prácticas coherentes conduce a un equipo de cargas de trabajo eficaz y a un trabajo de alta calidad. Los equipos de alto rendimiento utilizan herramientas y procesos probados por el sector para minimizar el esfuerzo desperdiciado y los posibles errores de código.
Estrategias de diseño principales
El primer paso para optimizar las prácticas de desarrollo es estandarizar herramientas y procesos. Cuando sea posible, use soluciones probadas en el sector en lugar de desarrollar soluciones internas. Para optimizar aún más sus prácticas, adopte herramientas de código bajo y sin código. Estas herramientas le permiten centrar sus esfuerzos en la aplicación y ayudarle a ahorrar tiempo. Para todas las herramientas y procesos que normalice, implemente el entrenamiento para que los equipos comprendan y los usen de forma eficaz. Para definir estándares que ayuden a optimizar las prácticas de desarrollo, tenga en cuenta las siguientes recomendaciones.
Usar herramientas conocidas y maduras fuera de la estantería
Use herramientas conocidas y maduras fuera de la estantería y normalice su uso. Los equipos de ingeniería altamente eficaces adoptan las mejores herramientas de clase. Este enfoque minimiza la necesidad de desarrollar soluciones para planear, desarrollar, probar, colaborar e integración continua y entrega continua (CI/CD). Muchas empresas ofrecen a los desarrolladores una opción entre algunas herramientas, pero todas las opciones son herramientas estándar para la organización y se validan internamente. Lo más importante es elegir herramientas que cumplan los requisitos de la carga de trabajo. Las herramientas fuera de la plataforma deben proporcionar las siguientes funciones:
Planificación del trabajo y administración de trabajos pendientes
Control de versiones y repositorios
Canalizaciones de CI/CD
Pruebas, como integración, humo, usuario sintético, simulación, caos y otras pruebas de calidad
Desarrollo de código
En algunos casos, una herramienta o un conjunto de herramientas pueden proporcionar varias funciones. Asegúrese de comprender las funcionalidades de las herramientas y sus limitaciones para que cumplan sus requisitos en todas las funciones.
Determine si debe invertir en herramientas costosas o versiones premium de herramientas. Tenga en cuenta el tiempo y el esfuerzo de desarrollar sus propias soluciones en comparación con las características que proporcionan las herramientas premium. Considere los costos únicos frente a los costos periódicos. En la mayoría de los casos, las herramientas off-the-shelf proporcionan un mayor valor al equipo.
Use herramientas de bajo código, sin código e inteligencia artificial cuando sea práctico. Las herramientas de poco código y sin código ahorran tiempo a los desarrolladores experimentados al permitirles conectar fácilmente la funcionalidad en lugar de realizar todo el proceso de desarrollo de código. Estas herramientas también permiten a los miembros del equipo de carga de trabajo que podrían no estar capacitados para que los desarrolladores contribuyan al funcionamiento de la carga de trabajo. Las herramientas de inteligencia artificial pueden ayudar con el desarrollo, las revisiones y la optimización del código.
Estandarizar la estrategia de bifurcación
Elija un modelo basado en troncos siempre que sea posible. La bifurcación basada en troncos mantiene sincronizado el equipo de desarrollo de cargas de trabajo y promueve la entrega continua. Defina directivas de rama para proteger ramas importantes, como la principal. Para obtener más información, consulte Adopción de una estrategia de bifurcación de Git y directivas y configuraciones de rama.
Evaluación de métricas para cuantificar la eficacia del desarrollo
Los equipos de desarrollo de software y control de calidad solo pueden mejorar si pueden cuantificar su eficacia. Para cuantificar la eficacia, deben identificar las métricas que miden la velocidad del desarrollador y definen kpi. Entre los ejemplos de estas métricas se incluyen:
Frecuencia de implementación: el número de implementaciones que cada desarrollador implementa cada día.
Tiempo de espera: el tiempo que tarda una tarea o un caso de usuario en pasar del trabajo pendiente a una implementación de producción.
Tiempo medio para la resolución: el tiempo medio que se dedica a corregir errores o defectos en el código.
Tasa de errores de cambio: el porcentaje de cambios que producen un error.
Para ayudar a las partes interesadas y al equipo de cargas de trabajo a realizar un seguimiento sencillo de la velocidad, visualice los KPI mediante paneles u otras herramientas de informes.
Estandarizar cómo escribe el equipo de cargas de trabajo, las revisiones y el código de documentos
Normalice cómo el equipo de cargas de trabajo escribe, revisa y documenta el código mediante una guía de estilo. Un estilo estándar facilita la colaboración y ayuda a incorporar a nuevos desarrolladores. Para trabajar de forma eficaz, los nuevos desarrolladores deben saber cómo funciona el equipo de cargas de trabajo. Una guía de estilo con estándares claramente definidos puede facilitar su proceso de entrenamiento. En la guía de estilo, defina estándares para lenguajes de desarrollo, bibliotecas, marcos y otras convenciones.
Cuando sea práctico, use herramientas para aplicar estándares de formato de código. Por ejemplo, Visual Studio ofrece varias herramientas que examinan el código para conocer el estilo, la calidad, el mantenimiento, el diseño y otros problemas. Para la infraestructura como código (IaC), puede usar Checkov o Terrascan para Terraform.
Para garantizar la coherencia y evitar posibles confusiones, la guía de estilo debe incluir convenciones de nomenclatura estándar para artefactos, entornos, ramas, compilaciones y ejecuciones.
También debe establecer directrices y estándares para el grado permitido de varianza en sus entornos. Si hay nuevos lenguajes, marcos u otras tecnologías que los miembros del equipo de carga de trabajo desean agregar a la lista estándar, implemente un proceso para usar esas herramientas en un entorno aislado o inferior. Pruebe su viabilidad y reemplace las tecnologías existentes cuando proceda.
Use registros de decisión de arquitectura (ADR) para mantener un registro histórico de las decisiones de diseño del equipo de carga de trabajo. Las ADR ayudan a los equipos a mantener una comprensión nueva de la carga de trabajo. También ayudan a los nuevos miembros del equipo a obtener información sobre las decisiones de diseño que se toman durante el ciclo de vida de la carga de trabajo. Asegúrese de que las ADR están controladas por versiones.
En la ADR, incluya:
Herramientas y tecnologías específicas, por ejemplo, con SQL o NoSQL, que el equipo elija.
Las razones para las decisiones de su equipo.
Otras opciones que se consideraron, lo que ayuda a contextualizar la decisión final.
Requisitos funcionales y no funcionales que se tienen en cuenta en las decisiones.
El contexto del proceso de toma de decisiones, como el problema que se solucionó.
Implementación de estándares para abordar la deuda técnica
La mentalidad que debe adoptar sobre la deuda técnica es que es intencionada y necesaria para las entregas de las cargas de trabajo del equipo. Esta mentalidad motiva a su equipo a tener en cuenta y abordar periódicamente la deuda técnica para evitar la acumulación. Abordar la deuda técnica como una tarea periódica en el trabajo pendiente.
Por ejemplo, supongamos que el equipo está estandarizado en una biblioteca. Con el tiempo, debe cambiar a otra biblioteca para la nueva funcionalidad de la carga de trabajo. Esa transición podría dar lugar a deudas técnicas. Con frecuencia, las transiciones como esta pueden dejar que el equipo de cargas de trabajo admita dos tecnologías porque no pueden realizar la transición sin problemas. El equipo de carga de trabajo debe priorizar la finalización de la transición porque cuando la carga de trabajo logra la nueva funcionalidad, las partes interesadas están satisfechos y tienen menos probabilidades de considerar la deuda técnica.
Estandarizar cómo aplicar el control de versiones a los artefactos
Normalice cómo aplica el control de versiones a los artefactos y cómo el control de versiones se expone interna y externamente. Por ejemplo, los sistemas orientados al cliente deben exponer su versión en ejecución en la interfaz de usuario. Esta técnica es útil cuando el equipo de cargas de trabajo soluciona problemas porque el cliente puede comunicar fácilmente qué versión usa. Las interfaces REST pueden exponer versiones para determinados componentes o bases de datos. Puede usar una tabla específica en los metadatos de un esquema para exponer la versión del esquema.
Use patrones de diseño de aplicaciones probadas en el sector para asegurarse de que la aplicación sea confiable, eficaz y segura. Use estos patrones para ahorrar tiempo y esfuerzo en comparación con el desarrollo de sus propias soluciones para la aplicación. Elija los patrones que benefician a la carga de trabajo. Revise periódicamente los patrones de diseño para asegurarse de que usa los patrones adecuados a medida que evoluciona la carga de trabajo.
Implementación de un enfoque de desplazamiento a la izquierda para probar
Implemente un enfoque de desplazamiento a la izquierda para realizar pruebas unitarias al principio y, a menudo, en todo el proceso de desarrollo. Las pruebas frecuentes en cada entorno de desarrollo ayudan a los desarrolladores a obtener confianza en sus aplicaciones. Para ayudar a crear la estrategia de pruebas con un enfoque de desplazamiento a la izquierda, tenga en cuenta los siguientes principios:
Escriba pruebas en el nivel más bajo posible. Favorece las pruebas con las dependencias externas más pocas y ejecuta pruebas como parte de la compilación.
Escriba pruebas una vez y ejecute pruebas en todas partes, incluida la producción. Escriba pruebas que puede ejecutar en todos los entornos de desarrollo sin tener en cuenta factores específicos de un entorno, como secretos cifrados o configuraciones.
Diseñe la carga de trabajo para realizar pruebas. Al desarrollar la aplicación, haga que la capacidad de prueba sea un requisito.
Trate el código de prueba como código de aplicación. Aplique los mismos estándares de calidad y desarrollo al código de aplicación y al código de prueba. Almacene el código de prueba junto con el código de la aplicación. Desarrolle y mantenga el código de prueba con código de aplicación. Para garantizar la calidad de las pruebas, descarte las pruebas que no sean confiables.
Considere la posibilidad de probar la propiedad, que se basa en la propiedad de la carga de trabajo. El equipo de cargas de trabajo posee sus pruebas y no debe depender de otros equipos para probar su código.
Automatice las pruebas tanto como sea posible. El código automatizado alivia la carga del equipo de cargas de trabajo y exige una calidad coherente.
Para obtener instrucciones detalladas sobre la implementación de una estrategia de prueba de DevOps, consulte Shift testing left with unit tests (Pruebas de desplazamiento a la izquierda con pruebas unitarias).
Requerir prácticas de DevSecOps como parte de los procedimientos operativos estándar. El equipo de cargas de trabajo debe comprender las prácticas de seguridad relacionadas con el desarrollo de software y la garantía de calidad. Deben seguir estas prácticas sin excepción. Para obtener más información, consulte Guía del ciclo de vida de desarrollo de seguridad.
Implementación de estándares para asignar nombres y etiquetado a los recursos
La implementación de convenciones de etiquetado y nomenclatura es un procedimiento recomendado para administrar y organizar recursos de Azure. Las convenciones de nomenclatura y etiquetado ayudan a identificar, clasificar y agrupar los recursos en función de atributos comunes, como el entorno, la aplicación, el propietario o el centro de coste. También permiten la seguridad, la automatización, los informes y la gobernanza de los recursos entre suscripciones y grupos de recursos.
Algunas de las ventajas de usar el etiquetado estandarizado y las convenciones de nomenclatura son:
- Proporcionan coherencia y claridad para la identificación y administración de recursos, lo que facilita la detección y búsqueda en Azure Portal, PowerShell, la CLI y las API.
- Habilitan el filtrado y la agrupación de recursos con fines de facturación, supervisión, seguridad y cumplimiento.
- Admiten la administración del ciclo de vida de los recursos, como el aprovisionamiento, la retirada, la copia de seguridad y la recuperación.
- Son esenciales para fines de seguridad. Si se produce un incidente de seguridad, es fundamental identificar rápidamente los sistemas afectados, las funciones que admiten esos sistemas y el posible impacto empresarial.
Para obtener más información sobre el uso de convenciones de nomenclatura para los recursos en la nube, consulte Definición de la convención de nomenclatura. Para obtener más información sobre cómo aplicar etiquetas de metadatos a los recursos en la nube, consulte Definición de la estrategia de etiquetado.
Facilitación de Azure
Azure DevOps es una colección de servicios que puede usar para crear una práctica de desarrollo colaborativa, eficaz y coherente. Azure DevOps agrupa las siguientes soluciones:
Azure Pipelines proporciona servicios de compilación y versión para admitir la CI/CD de las aplicaciones.
Azure Boards es una herramienta de administración de trabajo basada en web que admite prácticas ágiles como Scrum y Kanban.
Azure Repos es una herramienta de control de versiones que admite el sistema de control de versiones distribuido de Git y el sistema Control de versiones de Team Foundation.
Azure Test Plans es una solución de administración de pruebas basada en explorador que proporciona funcionalidades necesarias para pruebas manuales planeadas, pruebas de aceptación de usuarios, pruebas exploratorias y recopilación de comentarios de las partes interesadas.
Azure Artifacts se usa para permitir que los desarrolladores compartan de forma eficaz su código y administren sus paquetes.
Acciones de GitHub para Azure es una herramienta que puede usar para automatizar procesos de CI/CD. Se integra directamente con Azure para simplificar las implementaciones. Puede crear flujos de trabajo que compilen y prueben cada solicitud de incorporación de cambios en el repositorio o implementar solicitudes de incorporación de cambios combinadas en producción.
GitHub Projects es una herramienta de administración del trabajo que puede usar para crear paneles Kanban, informes, paneles y otras funciones.
Entre las herramientas de código bajo y sin código se incluyen:
Las plantillas de Azure Resource Manager y Bicep son herramientas nativas de Azure que puede usar para implementar IaC. Terraform es otra herramienta de IaC compatible con Azure que puede usar para implementar y administrar la infraestructura.
Visual Studio es una herramienta de desarrollo sólida que se integra con Azure y admite muchos lenguajes.
GitHub Copilot es un servicio de INTELIGENCIA ARTIFICIAL que actúa como programador de pares y proporciona sugerencias de estilo de autocompletar a medida que se codifica. Copilot está disponible como una extensión en Visual Studio y otras herramientas de desarrollo.
Azure Load Testing es un servicio de pruebas de carga totalmente administrado que puede usar para generar una carga a gran escala mediante la simulación del tráfico para las aplicaciones, independientemente de dónde se hospeden.
Alineación de la organización
Cloud Adoption Framework para Azure proporciona instrucciones generales y recomendaciones para etiquetar y asignar nombres a recursos de Azure, así como reglas y ejemplos específicos para distintos tipos de recursos.
Vínculos relacionados
- Adopción de una estrategia de bifurcación de Git
- Directivas y configuraciones de rama
- Patrones de diseño en la nube
- Velocidad del desarrollador
- Desarrollo de la estrategia de nomenclatura y etiquetado de los recursos de Azure
- Centro de recursos de DevOps
- Habilitar DevSecOps con Azure y GitHub
- Introducción al análisis de código fuente
- Guía del ciclo de vida de desarrollo de seguridad
- Seguridad en DevOps (DevSecOps)
- Desplazamiento de las pruebas a la izquierda con pruebas unitarias
- Serie de vídeos: Introducción a GitHub CoPilot
Lista de comprobación de excelencia operativa
Consulte el conjunto completo de recomendaciones.