Planear la estructura de la organización

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Use la estructura empresarial como guía para el número de organizaciones, proyectos y equipos que cree en Azure DevOps. Esta guía de planeación completa le ayuda a diseñar estructuras organizativas óptimas que alinean los flujos de trabajo de desarrollo con objetivos empresariales.

Marco de planificación estratégica

Decisiones sobre la estructura principal

Solucione estas preguntas fundamentales para guiar la estructura de Azure DevOps:

Nivel organizativo:

• ¿Cuántas organizaciones necesita? - Considere la seguridad, el cumplimiento y la separación de unidades de negocio.
• Cómo asignar organizaciones a unidades de negocio - Alinea con las necesidades de gobernanza y estructura empresarial

Nivel de proyecto:

• ¿Cuántos proyectos necesita? - Equilibrar la colaboración con la seguridad y la autonomía
• Estrategias de mapeo de proyectos: conectar proyectos con funciones empresariales y estructuras de equipo

Nivel de equipo y repositorio:

• Diseño de la estructura de equipo : optimización para la entrega ágil y la propiedad del producto
• Organización del repositorio : compatibilidad con los flujos de trabajo de desarrollo e implementación

Consideraciones de apoyo

• Administración de acceso: defina quién necesita acceso a qué información y recursos
• Requisitos de informes: planear la visibilidad entre equipos y la administración de carteras
• Normalización de procesos: promover prácticas coherentes al tiempo que permite la flexibilidad del equipo
• Alineación cultural: fomentar una mentalidad ágil y una cultura colaborativa

Descripción de las organizaciones de Azure DevOps

Una organización de Azure DevOps actúa como contenedor de nivel superior para los proyectos, lo que proporciona límites administrativos, seguridad y facturación. Las organizaciones le permiten:

• Centralización de la facturación y las licencias en proyectos y equipos relacionados
• Establecimiento de límites de seguridad con distintos controles de acceso y directivas
• Proporcionar aislamiento administrativo para diferentes unidades de negocio o requisitos de cumplimiento
• Conectarse a proveedores de identidades como Microsoft Entra ID para la autenticación unificada

Ventajas de la organización y nivel gratuito

Cada organización incluye servicios de nivel gratis para hasta cinco usuarios:

• Primeros cinco usuarios gratis (licencia básica)
• Azure Pipelines:
  • Un CI/CD hospedado por Microsoft (un trabajo simultáneo, hasta 30 horas al mes)
  • Un trabajo simultáneo de CI/CD autohospedado
• Azure Boards: seguimiento de elementos de trabajo y paneles
• Azure Repos: repositorios de Git privados ilimitados
• Azure Artifacts: Dos GiB gratis por organización

Patrones de organización comunes:

• Organización única: la mayoría de las empresas se benefician de una organización para la colaboración unificada
• Organizaciones de unidades de negocio: organizaciones independientes para distintos requisitos de cumplimiento o seguridad
• Organizaciones geográficas: separación regional para la residencia de datos o la gobernanza local

¿Cuántas organizaciones necesita?

Comience con una organización y expanda solo cuando tenga requisitos empresariales específicos que exijan separación.

Criterios de decisión para varias organizaciones

Cree más organizaciones cuando necesite:

Separación de seguridad y cumplimiento:

• Diferentes requisitos normativos (SOX, HIPAA, PCI-DSS)
• Requisitos de aislamiento de datos de clientes distintos
• Separación de seguimientos de auditoría y informes de cumplimiento

Requisitos de la estructura empresarial:

• Unidades de negocio independientes con gobernanza de TI independiente
• Diferentes requisitos de facturación y centro de costos
• Distintas conexiones del proveedor de identidades (diferentes inquilinos de Microsoft Entra)

Límites administrativos:

• Diferentes grupos de administradores sin superposición
• Separar directivas y controles de la organización
• Acuerdos de nivel de servicio independientes

Marco de evaluación

¿Qué es un equipo?

Un equipo es una unidad que admite muchas herramientas configurables por el equipo. Estas herramientas le ayudan a planear y administrar el trabajo, y facilitan la colaboración.

Crear un equipo para cada producto o equipo de características distinto

Cada equipo posee su propio trabajo pendiente. Para crear un nuevo trabajo pendiente, cree un nuevo equipo. Configure equipos y trabajos pendientes en una estructura jerárquica, por lo que los propietarios de programas pueden realizar un seguimiento más fácil del progreso entre equipos, administrar carteras y generar datos acumulativos. Se crea un grupo de equipo al crear un equipo. Puede usar este grupo en consultas o para establecer permisos para el equipo.

Descripción de proyectos

Los proyectos proporcionan el contenedor para el trabajo de desarrollo, que contiene estos servicios integrados:

• Azure Boards: planeamiento ágil con trabajos pendientes, sprints y seguimiento de elementos de trabajo
• Azure Pipelines: automatización continua de la integración e implementación
• Azure Repos: repositorios de Git o TFVC para la administración de código fuente
• Planes de pruebas de Azure: integración de pruebas manuales y automatizadas
• Recursos compartidos: wiki, paneles y configuración de nivel de proyecto

En el ejemplo siguiente, Contoso Manufacturing usa cuatro proyectos para organizar diferentes líneas de producto:

Ventajas y consideraciones del proyecto

Los proyectos habilitan:

• Programaciones de iteración compartidas y taxonomía entre equipos
• Plantillas de proceso coherentes y tipos de elementos de trabajo
• Administración integrada de informes y carteras
• Administración simplificada de usuarios y control de acceso

Los proyectos proporcionan límites para:

• Permisos de seguridad y acceso
• Personalización de procesos y seguimiento del trabajo
• Directivas administrativas y gobernanza
• Asignación de recursos y seguimiento de facturación

¿Cuántos proyectos necesita?

Tenga al menos un proyecto para empezar a usar un servicio de Azure DevOps, como Azure Boards, Azure Repos o Azure Pipelines. Al crear la organización, se crea un proyecto predeterminado automáticamente. En el proyecto predeterminado, hay un repositorio de código en el que empezar a trabajar, realizar un trabajo pendiente para realizar un seguimiento del trabajo y al menos una canalización para empezar a automatizar la compilación y la versión.

Dentro de una organización, puede realizar cualquiera de los siguientes enfoques:

• Crear un único proyecto que contenga muchos repositorios y equipos
• Crear muchos proyectos, cada uno con su propio conjunto de equipos, repositorios, compilaciones, elementos de trabajo y otros elementos

Incluso si tiene muchos equipos trabajando en cientos de aplicaciones y proyectos de software diferentes, puede administrarlos dentro de un solo proyecto en Azure DevOps. Sin embargo, si desea administrar la seguridad más granular entre los proyectos de software y sus equipos, considere la posibilidad de usar muchos proyectos. En el nivel más alto de aislamiento es una organización, donde cada organización está conectada a un único inquilino de Microsoft Entra. Sin embargo, un único inquilino de Microsoft Entra se puede conectar a muchas organizaciones de Azure DevOps.

Marco de decisión del proyecto

Elija la estructura de proyecto adecuada en función de sus necesidades de colaboración:

Enfoque de proyecto único:

• Mejor para: Organizaciones o equipos más pequeños con estrecha colaboración
• Ventajas: visibilidad máxima, recursos compartidos, informes unificados
• Considere cuándo: Los equipos trabajan en productos relacionados que tienen ciclos de lanzamiento similares

Enfoque de varios proyectos:

• Mejor para: Equipos independientes con requisitos distintos
• Ventajas: Mejores límites de seguridad, procesos personalizables, autonomía del equipo
• Tenga en cuenta cuándo: Diferentes necesidades de cumplimiento o unidades de negocio independientes

Azure DevOps proporciona experiencias entre proyectos para administrar el trabajo en varios proyectos.

Tenga en cuenta varios proyectos para:

• Restricción o administración del acceso a información específica
• Compatibilidad con procesos de seguimiento de trabajo personalizados para diferentes unidades de negocio
• Soporte para unidades de negocio separadas con políticas administrativas independientes
• Prueba de personalizaciones o extensiones antes del lanzamiento de producción

Al asignar proyectos a unidades de negocio, la empresa obtiene una sola organización y configura muchos proyectos con uno o varios proyectos que representan una unidad de negocio. Todos los recursos de Azure DevOps de la empresa se encuentran dentro de esta organización y se encuentran dentro de una geografía determinada (por ejemplo, Europa). Tenga en cuenta las instrucciones siguientes para asignar los proyectos a unidades de negocio:

Repositorios de estructura y control de versiones dentro de un proyecto

Considere el ámbito de trabajo estratégico específico para una de las organizaciones que creó anteriormente y quién necesita acceso. Use esta información para asignar un nombre y crear un proyecto. Este proyecto tiene una dirección URL definida en la organización en la que la creó y se puede acceder a ella en . https://dev.azure.com/{organization-name}/{project-name}.

Configure el proyecto en Configuración del proyecto.

Para más información sobre cómo administrar proyectos, consulte Administración de proyectos en Azure DevOps. Puede mover un proyecto a otra organización mediante la migración de los datos. Para obtener más información sobre la migración del proyecto, consulte la introducción a la migración.

Estrategia de repositorio y control de versiones

Configure la estrategia del repositorio en función del tamaño del equipo, la arquitectura del producto y los requisitos de implementación.

Selección del sistema de control de versiones

Elija entre Git y control de versiones de Team Foundation (TFVC):

Repositorios de Git:

• Enfoque recomendado para flujos de trabajo de desarrollo modernos
• Repositorios ilimitados por proyecto
• Control de versiones distribuido con bifurcación flexible
• Se integra con la mayoría de las herramientas de desarrollo y los sistemas de CI/CD

Control de versiones de Team Foundation (TFVC):

• Sistema de control de versiones centralizado
• Repositorio único por proyecto con organización basada en carpetas
• Adecuado para los equipos que prefieren flujos de trabajo centralizados

Patrones de organización del repositorio

Estrategia de Monorepo:

• Mejor para: Equipos pequeños que ganan impulso con los servicios relacionados
• Ventajas: uso compartido simplificado y cambios coordinados
• Desafíos: la complejidad del conocimiento aumenta con el crecimiento del equipo; acoplamiento de servicio no deseado; seguimiento de cambios difícil

Estrategia de repositorios independientes:

• Mejor para: Equipos más grandes con implementaciones de servicios independientes
• Ventajas: Borrar límites de servicio, incorporación más sencilla, ciclos de versión independientes
• Consideraciones: requiere una configuración más inicial, pero se escala de forma eficaz con el crecimiento del equipo.

Estrategia de alineación de repositorios y proyectos

Proyecto único con varios repositorios:

• Mejor para: Productos o servicios con programaciones de lanzamiento coordinadas
• Ventajas: Procesos compartidos, controles de acceso coherentes, administración simplificada
• Uso cuando: los desarrolladores suelen trabajar en varios repositorios y requieren herramientas coherentes

Varios proyectos con repositorios dedicados:

• Ideal para: Productos con programaciones independientes o requisitos distintos
• Ventajas: Personalización independiente, gobernanza independiente, límites claros

Factores de decisión para la organización del repositorio:

• Dependencias de código: colocar productos o servicios que se pueden implementar de forma independiente en repositorios independientes
• Necesidades de coordinación: mantener juntos los códigos base relacionados cuando se esperan cambios coordinados
• Arquitectura: Mantener monolitos existentes en repositorios individuales y separar servicios desconectados
• Acceso al equipo: implementación de la administración de permisos adecuada para controlar la creación del repositorio

Repositorio compartido frente a repositorios bifurcados

Se recomienda usar un repositorio compartido dentro de una organización de confianza. Los desarrolladores usan ramas para mantener el aislamiento de sus cambios entre sí. Con una buena estrategia de bifurcación y versión, un único repositorio se puede escalar para admitir el desarrollo simultáneo para más de mil desarrolladores. Para obtener más información sobre la estrategia de bifurcación y versión, consulte Adopción de una estrategia de bifurcación de Git y flujo de versión: Nuestra estrategia de bifurcación.

Las bifurcaciones pueden ser útiles cuando se trabaja con equipos de proveedor que no deben tener acceso directo para actualizar el repositorio principal. Las bifurcaciones también pueden ser útiles en escenarios en los que muchos desarrolladores contribuyen con poca frecuencia, como en un proyecto de código abierto. Al trabajar con bifurcaciones, es posible que quiera mantener un proyecto independiente para aislar los repositorios bifurcados del repositorio principal. Puede haber una sobrecarga administrativa adicional, pero mantiene el proyecto principal más limpio. Para obtener más información, consulte el artículo Bifurcaciones.

En la imagen siguiente se muestra un ejemplo de cómo "su empresa" podría estructurar sus organizaciones, proyectos, elementos de trabajo, equipos y repositorios.

Administración de recursos temporales y compartidos

Considere cómo administrar los recursos temporales y compartidos de forma eficaz mediante el uso de los siguientes procedimientos recomendados:

• Entornos temporales: los entornos temporales son de corta duración y se usan para tareas como pruebas, desarrollo o ensayo. Para administrar estos entornos de forma eficaz:
  • Repositorios y canalizaciones independientes: cada entorno temporal y sus recursos asociados, por ejemplo, Azure Functions, deben tener su propio repositorio y canalización. Esta separación le permite implementar y revertir el entorno y sus recursos simultáneamente, lo que facilita la puesta en marcha y descarte de ellos según sea necesario.
  • Ejemplo: cree un repositorio y una canalización específicamente para el entorno de desarrollo, incluidos todos los recursos necesarios, como Azure Functions, cuentas de almacenamiento y otros servicios.
• Recursos compartidos: los recursos compartidos suelen ser de larga duración y se usan en varios entornos. Estos recursos suelen tener tiempos de puesta en marcha más largos y mayores costos. Para administrar recursos compartidos de forma eficaz:
  • Repositorios y canalizaciones independientes: los recursos compartidos, como Azure SQL Database, deben tener su propio repositorio y canalización. Esta separación garantiza que los entornos temporales puedan usar estos recursos compartidos, lo que hace que sus implementaciones sean más rápidas y rentables.
  • Ejemplo: cree un repositorio y una canalización para Azure SQL Database, que pueden usar varios entornos temporales.
• Recursos de infraestructura compartida: los recursos de infraestructura compartidos, como nubes privadas virtuales (VPC) y subredes, también conocidos como zonas de aterrizaje, también deben tener sus propios repositorios y canalizaciones. Este enfoque garantiza que la infraestructura se administra de forma coherente y se puede reutilizar en distintos entornos.
  • Ejemplo: Cree un repositorio y una canalización para la configuración de vpc y subred, a la que pueden hacer referencia otros repositorios y canalizaciones.

Más información sobre la estructura organizativa

Elija el tipo de cuenta de administrador de la organización.

Al crear una organización, las credenciales que inicia sesión con definen el proveedor de identidades que usa su organización. Cree su organización con una cuenta microsoft o una instancia de Microsoft Entra. Use esas credenciales para iniciar sesión como administrador en la nueva organización en https://dev.azure.com/{YourOrganization}.

Uso de la cuenta Microsoft

Use su cuenta Microsoft si no necesita autenticar a los usuarios para una organización con el identificador de Microsoft Entra. Todos los usuarios deben iniciar sesión en su organización con una cuenta Microsoft. Si no tiene una, crear una cuenta de Microsoft.

Si no tiene una instancia de Microsoft Entra, cree una gratuitamente desde Azure Portal o use su cuenta Microsoft para crear una organización. A continuación, puede conectar su organización a Microsoft Entra ID.

Uso de la cuenta de Microsoft Entra

Es posible que ya tenga una cuenta de Microsoft Entra si usa Azure o Microsoft 365. Si trabaja para una empresa que usa microsoft Entra ID para administrar los permisos de usuario, probablemente tenga una cuenta de Microsoft Entra.

Si no tiene una cuenta de Microsoft Entra, regístrese en Microsoft Entra ID para conectar automáticamente su organización a su identificador de Microsoft Entra. Todos los usuarios deben ser miembros de ese directorio para acceder a su organización. Para agregar usuarios de otras organizaciones, use la colaboración B2B de Microsoft Entra.

Azure DevOps autentica a los usuarios a través del identificador de Microsoft Entra, de modo que solo los usuarios que son miembros de ese directorio tengan acceso a su organización. Al quitar usuarios de ese directorio, ya no pueden acceder a su organización. Solo los administradores específicos de Microsoft Entra administran los usuarios del directorio, por lo que los administradores controlan quién accede a su organización.

Para obtener más información sobre cómo administrar usuarios, consulte Administrar usuarios.

Asignación de organizaciones a unidades de negocio

Cada unidad de negocio de su empresa obtiene su propia organización en Azure DevOps, junto con su propio inquilino de Microsoft Entra. Puede configurar proyectos dentro de esas organizaciones individuales, según sea necesario, en función de los equipos o del trabajo en curso.

Para una empresa más grande, puede crear varias organizaciones con cuentas de usuario diferentes (lo más probable es que las cuentas de Microsoft Entra). Tenga en cuenta qué grupos y usuarios comparten estrategias y trabajo, y agrupelas en organizaciones específicas.

Por ejemplo, la empresa ficticia Fabrikam creó las tres organizaciones siguientes:

• Fabrikam-Marketing
• Fabrikam-Engineering
• Fabrikam-Sales

Cada organización tiene una dirección URL independiente, como:

• https://dev.azure.com/Fabrikam-Marketing
• https://dev.azure.com/Fabrikam-Engineering
• https://dev.azure.com/Fabrikam-Sales

Las organizaciones son para la misma empresa, pero están principalmente aisladas entre sí. No es necesario separar nada de esta manera. Solo cree límites cuando tenga sentido para su negocio.

Contenido relacionado

• Creación de una organización
• Creación de un proyecto
• Conectar su organización a Microsoft Entra ID
• Configuración de facturación
• Establecer preferencias de usuario