Compartir vía

Planear la estructura de la organización

  • Artículo

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

Use la estructura empresarial como guía para el número de organizaciones, proyectos y equipos que cree en Azure DevOps. Este artículo le ayuda a planear diferentes estructuras y escenarios para Azure DevOps.

Tenga en cuenta las siguientes estructuras para su negocio y trabajo colaborativo en Azure DevOps:

También puede planear los siguientes escenarios:

Tener al menos una organización, que puede representar a su empresa, su mayor colección de proyectos de código o incluso varias unidades de negocio relacionadas.

¿Qué es una organización?

Una organización de Azure DevOps es un mecanismo para organizar y conectar grupos de proyectos relacionados. Algunos ejemplos son las divisiones empresariales, las divisiones regionales u otras estructuras empresariales. Puede elegir una organización para toda su empresa, una organización para usted mismo o organizaciones independientes para unidades de negocio específicas.

Cada organización obtiene su propio nivel gratuito de servicios (hasta cinco usuarios para cada tipo de servicio), como se indica a continuación. Puede usar todos los servicios o elegir solo lo que necesita para complementar los flujos de trabajo existentes.

Nota:

El servicio de pruebas de carga basado en la nube de Azure DevOps está en desuso, pero Azure Load Testing sigue estando disponible. Este servicio de pruebas de carga totalmente administrado le permite generar una carga a gran escala mediante los scripts de Apache JMeter existentes. Para más información, consulte ¿Qué es Azure Load Testing? y Cambios en la funcionalidad de prueba de carga en Visual Studio y pruebas de carga en la nube en Azure DevOps.

¿Cuántas organizaciones necesita?

Comience con una organización en Azure DevOps. A continuación, puede agregar más organizaciones, que pueden requerir modelos de seguridad diferentes, más adelante. Un único repositorio de código o proyecto solo necesita una organización. Si tiene equipos independientes que necesitan trabajar en código u otros proyectos de forma aislada, plantéese la posibilidad de crear organizaciones independientes para esos equipos. Tendrán direcciones URL diferentes. Agregue proyectos, equipos y repositorios, según sea necesario, antes de agregar otra organización.

Dedique algún tiempo a revisar la estructura de trabajo y los diferentes grupos de negocios y participantes que se administrarán. Para obtener más información, consulte Asignación de proyectos a unidades de negocio y Consideraciones sobre la estructura.

Sugerencia

En el caso de las organizaciones de Microsoft Entra propiedad de la empresa, considere la posibilidad de restringir a los usuarios la creación de nuevas organizaciones como una manera de proteger la dirección IP. Para obtener más información, consulte Restringir la creación de la organización a través de la directiva de inquilinos de Microsoft Entra. Los usuarios pueden crear organizaciones con sus cuentas de MSA o GitHub sin restricciones.

¿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.

¿Qué es un proyecto?

Un proyecto de Azure DevOps contiene el siguiente conjunto de características:

  • Paneles y trabajos pendientes para la planificación ágil
  • Canalizaciones para la integración e implementación continuas
  • Repositorios para el control de versiones y la administración del código fuente y los artefactos
  • Integración de pruebas continuas a lo largo del ciclo de vida del proyecto Cada organización contiene uno o varios proyectos

En la imagen siguiente, la empresa ficticia Contoso tiene cuatro proyectos dentro de su organización Contoso-Manufacturing.

Imagen de una organización con cuatro proyectos

¿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.

Nota:

Si la característica Limitar la visibilidad del usuario y la colaboración a proyectos específicos está habilitada para la organización, los usuarios agregados al grupo Usuarios con ámbito de proyecto no podrán acceder a los proyectos a los que no se hayan agregado. Para obtener más información e importantes llamadas relacionadas con la seguridad, consulte Administrar su organización, Limitar la visibilidad del usuario para proyectos y mucho más.

Proyecto único

Un único proyecto coloca todo el trabajo en el mismo nivel de "cartera" para toda la organización. El trabajo tiene el mismo conjunto de repositorios y rutas de acceso de iteración. Con un solo proyecto, los equipos comparten repositorios de origen, definiciones de compilación, definiciones de versión, informes y fuentes de paquetes. Es posible que tenga un gran producto o servicio administrado por muchos equipos. Esos equipos tienen estrechas dependencias entre ellos en el ciclo de vida del producto. Cree un proyecto y divida el trabajo mediante equipos y rutas de acceso de área. Esta configuración proporciona a los equipos visibilidad del trabajo entre sí, por lo que la organización permanece alineada. Los equipos usan la misma taxonomía para el seguimiento de elementos de trabajo, lo que facilita la comunicación y la coherencia.

Sugerencia

Cuando varios equipos trabajan en el mismo producto, tener todos los equipos en la misma programación de iteración ayuda a mantener los equipos alineados y ofrecer valor en la misma cadencia. Por ejemplo, nuestra organización en Azure DevOps tiene más de 40 equipos de características y 500 usuarios dentro de un solo proyecto: esto funciona bien porque todos estamos trabajando en un conjunto de productos común con objetivos comunes y una programación de versión común.

Un gran volumen de consultas y paneles puede dificultar la búsqueda de lo que está buscando. En función de la arquitectura del producto, esta dificultad se puede sangr en otras áreas, como compilaciones, versiones y repositorios. Asegúrese de usar buenas convenciones de nomenclatura y una estructura de carpetas sencilla. Al agregar un repositorio al proyecto, tenga en cuenta la estrategia y determine si ese repositorio podría colocarse en su propio proyecto.

Muchos proyectos

Puede determinar mejor la estructura del proyecto mediante el envío del producto. Tener varios proyectos desplaza la carga de administración y proporciona a los equipos más autonomía para administrar el proyecto a medida que el equipo decide. También proporciona un mayor control de la seguridad y el acceso a los recursos en los distintos proyectos. Sin embargo, tener independencia de equipo con muchos proyectos crea algunos desafíos de alineación. Si cada proyecto usa un proceso diferente o una programación de iteración, puede dificultarse la comunicación y la colaboración si las taxonomías no son las mismas.

Sugerencia

Si usa las mismas programaciones de proceso e iteración en todos los proyectos, la capacidad de acumular datos e informar en todos los equipos mejora.

Azure DevOps proporciona experiencias entre proyectos para administrar el trabajo.

Es posible que desee agregar otro proyecto debido a los siguientes escenarios:

  • Para prohibir o administrar el acceso a la información dentro de un proyecto
  • Para admitir procesos de seguimiento de trabajo personalizados para unidades de negocio específicas dentro de la organización
  • Para admitir unidades de negocio completamente independientes que tengan sus propias directivas administrativas y administradores
  • Para admitir las actividades de personalización de prueba o agregar extensiones antes de implementar los cambios en el proyecto de trabajo

Cuando esté considerando muchos proyectos, tenga en cuenta que la portabilidad del repositorio de Git facilita la migración de repositorios (incluido el historial completo) entre proyectos. No se puede migrar otro historial entre proyectos. Algunos ejemplos son el historial de solicitudes de inserción y extracció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 dentro de una región determinada (por ejemplo, Europa occidental). Tenga en cuenta las instrucciones siguientes para asignar los proyectos a unidades de negocio:

Un proyecto, muchos equipos Una organización, muchos proyectos y equipos Muchas organizaciones
Orientación general Mejor para organizaciones más pequeñas o organizaciones de mayor tamaño con equipos altamente alineados. Es bueno cuando los diferentes esfuerzos requieren procesos diferentes. Resulta útil como parte de las migraciones heredadas de TFS y para los límites de seguridad estrictos entre las organizaciones. Se usa con varios proyectos y equipos dentro de cada organización.
Escala Admite decenas de miles de usuarios y cientos de equipos, pero mejor a esta escala si todos los equipos están trabajando en esfuerzos relacionados. Igual que con un proyecto, pero muchos proyectos pueden ser más fáciles.
Process Procesos alineados entre equipos; flexibilidad del equipo para personalizar paneles, paneles, etc. Procesos independientes para cada proyecto. Por ejemplo, diferentes tipos de elementos de trabajo, campos personalizados, etc. Igual que con muchos proyectos.
Colaboración Visibilidad y reutilización predeterminada más alta entre el trabajo y los recursos de diferentes equipos. Una buena visibilidad y reutilización son posibles, pero es más fácil ocultar activos entre proyectos si es intencionado. Poca visibilidad, colaboración y reutilización entre organizaciones.
Acumulación de informes y administración de carteras La mejor capacidad para acumularse entre equipos y coordinar entre equipos. Buenos informes posibles en todos los proyectos. Más difícil para la acumulación entre proyectos y la coordinación de equipos. No hay acumulación ni coordinación entre organizaciones.
Aislamiento/Seguridad Puede bloquear los recursos en un nivel de equipo, pero el valor predeterminado es la visibilidad y colaboración abiertas. Mejor capacidad de bloqueo entre proyectos. De forma predeterminada, proporciona una buena visibilidad dentro de los proyectos y un buen aislamiento entre proyectos. Límites estrictos entre organizaciones; excelente aislamiento y capacidad mínima para compartir entre organizaciones.
Cambios de contexto Más fácil para que los equipos trabajen juntos y para que los usuarios cambien de tareas. Relativamente fácil para que los usuarios trabajen juntos y cambien de contexto entre tareas. Más difícil para los usuarios que tienen que trabajar en diferentes organizaciones.
Sobrecarga de información De forma predeterminada, todos los recursos son visibles para los usuarios que usan "favoritos" y mecanismos similares para evitar la "sobrecarga de información". Menor riesgo de sobrecarga de información; la mayoría de los recursos de proyecto están ocultos más allá de los límites del proyecto. Los recursos de las organizaciones están aislados, lo que reduce el riesgo de sobrecarga de información.
Sobrecarga administrativa Gran parte de la administración se delega a equipos individuales. Más fácil para las licencias de usuario y la administración de nivel de organización. Es posible que se necesite más trabajo si se requiere alineación entre los esfuerzos. Más administración en el nivel de proyecto. Más sobrecarga, pero puede ser útil cuando los proyectos tienen necesidades administrativas diferentes. Al igual que con más proyectos, hay más sobrecarga administrativa, lo que permite una mayor flexibilidad entre las organizaciones.

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.

Captura de pantalla que muestra el botón 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.

Administración del control de versiones

En proyectos en los que está habilitado el servicio Azure Repos, los repositorios de control de versiones pueden almacenar y revisar el código. Tenga en cuenta las siguientes opciones al configurar repositorios.

Git frente a Control de versiones de Team Foundation (TFVC)

Azure Repos ofrece los siguientes sistemas de control de versiones para que los equipos elijan:

  • Git y TFVC. Los proyectos pueden tener repositorios de cada tipo. De forma predeterminada, los nuevos proyectos tienen un repositorio de Git vacío. Git permite una gran cantidad de flexibilidad en los flujos de trabajo de desarrollador e integra con casi todas las herramientas pertinentes del ecosistema de desarrolladores. Cualquier proyecto puede usar repositorios de Git. No hay ningún límite en la cantidad de repositorios de Git que se pueden agregar a un proyecto.

TFVC es un sistema de control de versiones centralizado que también está disponible. A diferencia de Git, solo se permite un repositorio TFVC para un proyecto. Pero, dentro de ese repositorio, se usan carpetas y ramas para organizar el código de varios productos y servicios, si lo desea. Los proyectos pueden usar TFVC y Git, si procede.

Monorepo frente a un repositorio por servicio

La implementación de varios servicios independientes desde un monorepo puede ser eficaz para los equipos pequeños con el objetivo de crear un impulso temprano. Sin embargo, esta estrategia puede resultar problemática a medida que el equipo crece debido a varios factores:

  • El conocimiento necesario para los nuevos miembros aumenta con la complejidad general del sistema.
  • El uso compartido de código dentro de un único repositorio puede dar lugar a un acoplamiento no deseado entre los servicios.
  • Los cambios en el código compartido pueden afectar al comportamiento de varios servicios, lo que dificulta el seguimiento de estos cambios.

Para equipos más grandes, la administración de un monorepo requiere una sólida materia de ingeniería y herramientas sólidas. Como alternativa, puede optar por repositorios individuales para cada servicio, junto con un repositorio independiente para los recursos compartidos. Aunque este enfoque implica una configuración más inicial, se escala más eficazmente a medida que crece el equipo. También facilita la incorporación de nuevos miembros, que pueden concentrarse únicamente en su repositorio de servicios específico.

Si estás empezando con un equipo pequeño, un monorepo puede ser una buena opción. A medida que el equipo se expande y aumenta la complejidad, puede realizar la transición a repositorios independientes.

Uno frente a muchos repositorios dentro de un proyecto

¿Necesita configurar varios repositorios dentro de un único proyecto o tener un repositorio configurado por proyecto? Las instrucciones siguientes se relacionan con las funciones de planeación y administración en esos repositorios.

Un proyecto que contiene varios repositorios funciona bien si los productos o servicios están trabajando en una programación de versión coordinada. Si los desarrolladores suelen trabajar con varios repositorios, manténgalos en un único proyecto para garantizar que los procesos permanezcan compartidos y coherentes. Es más fácil administrar el acceso al repositorio dentro de un solo proyecto, ya que los controles de acceso y las opciones, como la aplicación de casos y el tamaño máximo de archivo, se establecen en el nivel de proyecto. Puede administrar los controles de acceso y la configuración individualmente, incluso si los repositorios están en un solo proyecto.

Si los productos almacenados en varios repositorios funcionan en programaciones o procesos independientes, puede dividirlos en varios proyectos. La portabilidad del repositorio de Git facilita el traslado de un repositorio entre proyectos y sigue manteniendo el historial de confirmaciones de plena fidelidad. Otros historiales, como las solicitudes de incorporación de cambios o el historial de compilación, no se migran fácilmente.

Base la decisión de uno frente a muchos repositorios en los siguientes factores y sugerencias:

  • Dependencias de código y arquitectura
  • Coloque cada producto o servicio con capacidad de implementación independiente en su propio repositorio
  • No separe un código base en muchos repositorios si espera realizar cambios de código coordinados en esos repositorios, ya que ninguna herramienta puede ayudar a coordinar esos cambios.
  • Si el código base ya es un monolito, manténgalo en un repositorio. Para obtener más información sobre los repositorios monolíticos, consulte El modo en que Microsoft desarrolla software moderno con DevOps .
  • Si tiene muchos servicios desconectados, un repositorio por servicio es una buena estrategia.

Sugerencia

Considere la posibilidad de administrar los permisos, por lo que no todos los usuarios de su organización pueden crear un repositorio. Si tiene demasiados repositorios, es difícil realizar un seguimiento de quién es el propietario del código u otro contenido almacenado en esos repositorios.

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 desee 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.

Diagrama que muestra la estructura organizativa de una empresa.

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.

Escribir la contraseña e iniciar sesión

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.

Sugerencia

Puede crear particiones más fácilmente de una organización existente con proyectos, que combinar diferentes organizaciones.