Recomendaciones para estandarizar herramientas y procesos

  • Artículo

Se aplica a esta recomendación de lista de comprobación de excelencia operativa de Azure Well-Architected Framework:

OE:04 Optimice los procesos de desarrollo de software y control de calidad siguiendo las prácticas probadas en el sector para el desarrollo y las 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 usan 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 las 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 estandariza, 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.

Uso de herramientas conocidas y maduras fuera de la plataforma

Use herramientas conocidas y maduras fuera de la plataforma 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 del estante 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

  • Programación 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 fuera del estante proporcionan un mayor valor a su equipo.

Use herramientas de inteligencia artificial, sin código y poco código 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 cuando sea posible. La bifurcación basada en troncos mantiene sincronizado el equipo de desarrollo de cargas de trabajo y fomenta la entrega continua. Defina directivas de rama para proteger ramas importantes, como la rama 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 los KPI. Algunos ejemplos de estas métricas son:

  • 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 promedio de tiempo dedicado a corregir errores o defectos en el código.

  • Tasa de errores de cambio: porcentaje de cambios que dan lugar a 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 carga 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 nuevos desarrolladores. Para trabajar de forma eficaz, los nuevos desarrolladores deben saber cómo funciona el equipo de carga 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. En el caso de 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 espacio aislado o en un entorno inferior. Pruebe su viabilidad y reemplace las tecnologías existentes cuando proceda.

Use los 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. Los 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 los ADR estén controlados por versiones.

En la ADR, incluya:

  • Herramientas y tecnologías específicas, por ejemplo, con SQL o NoSQL, que elija el equipo.

  • Las razones de 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.

  • Contexto del proceso de toma de decisiones, como el problema que se solucionó.

Implementación de estándares para abordar la deuda técnica

Adopte una mentalidad de que la deuda técnica sea intencionada y necesaria para los resultados del equipo de carga de trabajo. Esta mentalidad motiva a su equipo a considerar 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 nuevas funcionalidades de la carga de trabajo. Esa transición podría dar lugar a deuda técnica. Con frecuencia, las transiciones como esta pueden dejar que el equipo de carga 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 alcanza 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

Estandarizar cómo aplicar el control de versiones a los artefactos y cómo se expone el control de versiones 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 carga 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 probados por 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 durante 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 mínimas 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 son confiables.

  • Considere la posibilidad de probar la propiedad, que se basa en la propiedad de la carga de trabajo. El equipo de carga 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 en el equipo de carga de trabajo y exige una calidad coherente.

Para obtener instrucciones detalladas sobre cómo implementar 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 el control de calidad. Deben seguir estas prácticas sin excepción. Para más información, consulte Guía del ciclo de vida de desarrollo de seguridad.

Implementación de estándares para asignar nombres y etiquetar recursos

La implementación de convenciones de etiquetado y nomenclatura es un procedimiento recomendado para administrar y organizar los recursos de Azure. Las convenciones de etiquetado y nomenclatura ayudan a identificar, clasificar y agrupar recursos en función de atributos comunes, como el entorno, la aplicación, el propietario o el centro de costos. 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 los 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 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 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 de 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 eficazmente su código y administren sus paquetes.

  • Acciones de GitHub para Azure es una herramienta que puede usar para automatizar los 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 de 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 simulando el tráfico de las aplicaciones, independientemente de dónde se hospeden.

Lista de comprobación de excelencia operativa

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de excelencia operativa