Ciclo de vida del desarrollo

  • Artículo

La estrategia de ciclo de vida de desarrollo proporciona consideraciones de diseño clave y recomendaciones para el repositorio, la rama, las compilaciones automatizadas, la implementación y la estrategia de reversión durante la creación automática de la zona de aterrizaje.

Estrategia de repositorio

Consideraciones de diseño

  • Considere la posibilidad de adoptar un sistema de control de versiones como Git para proporcionar a su equipo flexibilidad en el uso compartido y la administración del código.

    • Git es el sistema de control de versiones estándar del sector. Es un sistema de control de versiones distribuido, donde su copia local del código es una versión completa del repositorio.

  • Descripción de la estructura de un solo repositorio frente a la estructura de varios repositorios

    • En las estructuras de un solo repositorio, todo el código fuente se encuentra en un único repositorio.
    • En estructuras de varios repositorios, todos los proyectos se organizan en repositorios independientes.

  • Elija una configuración de visibilidad que se adapte al contenido del repositorio.

    • Se puede acceder a los repositorios públicos de forma anónima.
    • Los repositorios privados requieren que se conceda acceso a los usuarios al repositorio y que inicien sesión para acceder a los servicios.
    • Puede establecer visibilidad pública y privada para Azure DevOps Projects y los repositorios de GitHub.

  • Considere la posibilidad de establecer permisos de repositorio que le ayuden a controlar quién puede contribuir al código fuente y administrar otras características.

  • Considere la posibilidad de usar la implementación de recursos de infraestructura como código (IaC) en Azure. IaC permite administrar la infraestructura en un modelo declarativo, lo que ayuda a reducir el esfuerzo de configuración, garantizar la coherencia entre las implementaciones y evitar la configuración manual del entorno.

  • Azure proporciona compatibilidad con IaC para zonas de aterrizaje mediante:

Recomendaciones de diseño

  • Use Git como sistema de control de versiones.

  • Uso de repositorios privados al compilar zonas de aterrizaje de Azure

  • Use repositorios públicos al compartir información no confidencial, como ejemplos de automatización, documentación pública y material de colaboración de código abierto.

  • Adopte un enfoque de IaC para implementar, administrar, gobernar y admitir recursos en la nube.

Estrategia de bifurcación

Consideraciones de diseño

  • Considere la posibilidad de usar una estrategia de rama que permita a los equipos colaborar mejor y administrar de forma eficaz el control de versiones.

  • Considere la posibilidad de usar convenciones de nomenclatura específicas para las ramas.

  • Considere la posibilidad de usar permisos de rama para controlar las funcionalidades del usuario.

  • Considere la posibilidad de usar directivas de rama para ayudar a los equipos a proteger ramas importantes de desarrollo. Las directivas que pueden ayudar a aplicar los estándares de administración de cambios y la calidad del código. Entre los ejemplos de directivas de rama se incluyen los siguientes:

  • La adopción de una estrategia de solicitud de incorporación de cambios puede ayudarle a mantener el control de los cambios de código combinados en ramas.

    • Defina una estrategia de combinación.
    • Las solicitudes de incorporación de cambios deben ser sencillas, con el número mínimo de archivos guardados para ayudar a los revisores a validar confirmaciones y cambios de forma más eficaz.
    • Las solicitudes de incorporación de cambios deben tener títulos y descripciones claros para que los revisores sepan qué esperar al revisar el código.
    • Puede usar plantillas de solicitud de incorporación de cambios.
    • Puede eliminar ramas de origen una vez completadas las solicitudes de incorporación de cambios, lo que proporciona mayor control y una administración mejorada de las ramas.

Recomendaciones de diseño

  • Adopte un modelo de desarrollo troncal, en el que los desarrolladores confirman en una sola rama. Este modelo facilita la integración continua. Todo el trabajo de las características se realiza en el tronco, y los conflictos de combinación se resuelven cuando se produce la confirmación.

  • Haga que los equipos definan y usen convenciones de nomenclatura coherentes para las ramas con el fin de identificar el trabajo realizado.

  • Establezca permisos para controlar quién puede leer y actualizar el código en una rama del repositorio de Git. Puede establecer permisos para usuarios individuales y para grupos.

  • Establezca directivas de rama:

    • Requiera el uso de solicitudes de incorporación de cambios para las combinaciones de ramas en la rama principal.
    • Requiera un número mínimo de revisores para las solicitudes de incorporación de cambios.
    • Restablezca todos los votos de aprobación para quitar todos los votos de aprobación, pero mantenga los votos para rechazar o esperar cada vez que cambie una rama de origen.
    • Incluya automáticamente los revisores de código.
    • Active la resolución de comentarios.

  • Establezca la combinación con "squash" como estrategia de fusión, lo que le permite condensar el historial de Git de las ramas de temas al completar las solicitudes de incorporación de cambios. En lugar de agregar cada confirmación en una rama de tema al historial de la rama predeterminada, una fusión mediante combinación con "squash" agrega todos los cambios de archivo a una única confirmación nueva en la rama predeterminada.

Compilaciones automatizadas

Consideraciones de diseño

  • Considere la posibilidad de implementar la integración continua (CI). La CI conlleva combinar todo el código de desarrollo en un código base central según una programación periódica y, después, ejecutar automáticamente procesos de compilación y prueba estándar.

  • Considere la posibilidad de usar desencadenadores de CI:

    • Git de Azure Repos. Puede configurar ramas, rutas de acceso y etiquetas como desencadenadores para ejecutar una compilación de CI.
    • GitHub. Puede configurar desencadenadores de ramas, rutas de acceso y etiquetas para ejecutar una compilación de CI.

  • Considere la posibilidad de incluir pruebas unitarias de IaC en el proceso de compilación para validar la sintaxis.

  • Considere la posibilidad de incluir pruebas unitarias en el proceso de compilación de la aplicación. Revise las tareas disponibles para la canalización de Azure DevOps.

  • Use conexiones de servicio de Azure DevOps o secretos de GitHub para administrar las conexiones a Azure. Cada conexión debe tener el acceso con privilegios correcto a los recursos de Azure.

  • Considere la posibilidad de usar secretos de Azure Key Vault para almacenar y administrar información confidencial, como contraseñas, claves de API y certificados.

  • Los agentes de Azure DevOps pueden estar autohospedados u hospedados por Microsoft.

    • El mantenimiento y las actualizaciones se realizan automáticamente cuando se usan agentes hospedados por Microsoft. Cada vez que se ejecuta un trabajo de compilación, se crea una máquina virtual nueva.
    • Configure y administre agentes autohospedados por su cuenta para ejecutar trabajos de compilación.

Recomendaciones de diseño

  • Use CI para automatizar las compilaciones y las pruebas de código cada vez que un miembro del equipo confirma los cambios en el control de versiones.

  • Incluya pruebas unitarias para IaC y código de aplicación como parte del proceso de compilación.

  • Si es posible, use grupos hospedados por Microsoft en lugar de grupos autohospedados, ya que ofrecen aislamiento y una máquina virtual limpia para cada ejecución de canalización.

  • Al conectar Azure DevOps o GitHub a Azure a través de conexiones de servicio o secretos de GitHub, asegúrese de definir siempre el ámbito para que solo puedan acceder a los recursos necesarios.

  • Use los secretos de Key Vault para evitar codificar de forma rígida información confidencial, como credenciales (contraseñas de usuario de la máquina virtual), certificados o claves. A continuación, use secretos como variables en los trabajos de compilación y versión.

Estrategia de implementación

Consideraciones de diseño

  • Considere la posibilidad de usar la entrega continua (CD). La entrega continua implica compilar, probar, configurar e implementar desde una compilación en un entorno.

  • Considere la posibilidad de usar entornos. Los entornos permiten establecer como destino una colección de recursos a partir de un trabajo de entrega. Algunos ejemplos de nombres de entorno comunes son:

    • Desarrollo
    • Prueba
    • QA
    • Ensayo
    • Producción

  • Considere la posibilidad de usar IaC como parte de la estrategia para validar y confirmar los cambios antes de la implementación.

Recomendaciones de diseño

  • Use la entrega continua (CD) para garantizar que el código está siempre listo para implementarse, mediante la compilación, prueba e implementación automáticas del código en entornos similares al de producción. Agregue la entrega continua para crear una integración completa de CI/CD que le ayude a detectar defectos de código lo antes posible y que garantice que puede publicar rápidamente actualizaciones probadas correctamente.

  • Use entornos como parte de la estrategia de implementación. Los entornos proporcionan ventajas como:

    • Historial de implementación
    • Rastreabilidad de confirmaciones y elementos de trabajo
    • Estado de los recursos de diagnóstico
    • Seguridad

  • Incluya comprobaciones previas a la implementación de IaC para poder obtener una vista previa de los cambios. Consulte los detalles sobre si se ha creado, modificado o eliminado un recurso.

Estrategia de reversión

Consideraciones de diseño

  • Considere la posibilidad de crear un plan de reversión. Revertir una implementación implica revertir la implementación a un estado conveniente conocido y proporciona una capacidad fundamental para recuperarse de una implementación con errores.

  • Considere la posibilidad de usar la opción de deshacer cambios en Git si necesita revertir los cambios en una confirmación, descartar los cambios o restablecer una rama a un estado anterior.

Recomendaciones de diseño

  • Adopte el uso de la opción para deshacer cambios en Git si necesita revertir los cambios en archivos confirmados, descartar los cambios pendientes de confirmación o restablecer una rama a un estado anterior.