Planear la estructura de la organización

  • Artículo
  • 17 minutos para leer

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

La estructura empresarial debe actuar 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 trabajo empresarial o colaborativo en Azure DevOps:

También puede planear los siguientes escenarios:

Debe tener al menos una organización, que pueda representar su empresa, su colección más grande 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 la empresa, una organización solo para usted 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 muestra a continuación. Puede usar todos los servicios o elegir solo lo que necesita para complementar los flujos de trabajo existentes.

  • Azure Pipelines:un trabajo hospedado con 1800 minutos al mes para CI/CD y un trabajo auto-hospedado
  • Azure Boards:Seguimiento de elementos de trabajo y paneles Kanban
  • Azure Repos:repositorios de Git privados ilimitados
  • Azure Artifacts:Administración de paquetes
  • Partes interesadas ilimitadas
    • Cinco Azure DevOps usuarios (Básico)
    • Nivel gratuito de CI/CD hospedado por Microsoft (un trabajo simultáneo, hasta 30 horas al mes)
    • 2 GiB de Azure Artifacts almacenamiento
    • Un trabajo simultáneo de CI/CD auto-hospedado

Precaución

El servicio de prueba de carga basado en la nube ha quedado en desuso. Puede encontrar más información sobre el desuso, la disponibilidad del servicio y servicios alternativos aquí.

¿Cuántas organizaciones necesita?

Comience con una sola organización en Azure DevOps. A continuación, puede agregar organizaciones adicionales, que pueden requerir modelos de seguridad diferentes, más adelante. Un único repositorio o proyecto de código solo necesita una organización. Si tiene equipos independientes que necesitan trabajar en código u otros proyectos de forma aislada, considere 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.

Tómese un tiempo para revisar la estructura del trabajo y los distintos grupos de negocios y participantes que se administrarán. Para más información, consulte Mapping your projects to business units (Asignación de proyectos a unidades de negocio) y Structure considerations (Consideraciones de estructura).

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

Creación de 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. Al configurar equipos y trabajos pendientesen una estructura jerárquica, los propietarios de programas pueden realizar un seguimiento más sencillo del progreso entre equipos, administrar carteras y generar datos consolidados. Al crear un equipo, se crea un grupo de equipos. Puede usar este grupo en consultas o para establecer permisos para su equipo.

¿Qué es un proyecto?

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

  • Boards y trabajo pendiente para un planeamiento ágil
  • Pipelines integración e implementación continuas
  • Repos control de versiones y administración de código fuente y artefactos
  • Integración continua de pruebas a lo largo del ciclo de vida del proyecto Cada organización contiene uno o varios proyectos

En la imagen siguiente, la compañía ficticia Contoso tiene cuatro proyectos dentro de su Contoso-Manufacturing organización.

Imagen de una organización con cuatro proyectos

¿Cuántos proyectos necesita?

Debe tener 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 automáticamente un proyecto predeterminado. En el proyecto predeterminado, hay un repositorio de código en el que empezar a trabajar, trabajo pendiente para realizar un seguimiento del trabajo y al menos una canalización para empezar a automatizar la compilación y el lanzamiento.

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 único proyecto en Azure DevOps. Sin embargo, si desea administrar una 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 se encuentra una organización, donde cada organización está conectada a un único Azure AD inquilino. Sin embargo, Azure AD inquilino único se puede conectar a muchas Azure DevOps organizaciones.

Nota

Si el grupo conocido Project-ScopedUsers para ocultar la característica de vista previa de configuración está habilitado para la organización, los usuarios agregados al grupo Usuarios con ámbito de Project no podrán acceder a proyectos a los que no se hayan agregado. Para obtener más información, consulte Acerca de los proyectos y el escalado de la organización, Projectde usuarios con ámbito de aplicación .

Proyecto único

Un solo 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. Un solo proyecto permite a los equipos compartir repositorios de origen, definiciones de compilación, definiciones de versión, informes y fuentes de paquetes. Es posible que tenga un producto o servicio grande administrado por muchos equipos. Esos equipos tienen estrechas interdependencias entre sí a lo largo del 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 sobre el trabajo de los demá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 a entregar valor en la misma cadencia. Por ejemplo, la organización de Azure DevOps tiene más de 40 equipos de características y 500 usuarios en 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 lanzamiento común.

Un gran volumen de consultas y paneles puede hacer que sea difícil encontrar lo que busca. En función de la arquitectura del producto, esta dificultad se puede insocar en otras áreas, como compilaciones, versiones y repositorios. Asegúrese de usar buenas convenciones de nomenclatura y una estructura de carpetas simple. Al agregar un repositorio al proyecto, tenga en cuenta su estrategia y determine si ese repositorio se podría colocar en su propio proyecto.

Muchos proyectos

Project estructura está mejor determinada por cómo se envía el producto. Tener varios proyectos cambia 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 del equipo con muchos proyectos crea algunos desafíos de alineación. Si cada proyecto usa un proceso o una programación de iteración diferentes, puede dificultar 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, se mejora la capacidad de sume los datos y los informes entre los equipos.

Azure DevOps proporciona experiencias entre proyectos en lo que respecta a la administración del 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 su organización
  • Para admitir unidades de negocio completamente independientes que tengan sus propias directivas administrativas y administradores
  • Para admitir la prueba de actividades de personalización o la adición de extensiones antes de implementar cambios en el proyecto de trabajo

Al considerar 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 Azure DevOps activos de la empresa se encuentran dentro de esta organización y se encuentran 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
Guía general Lo mejor para organizaciones más pequeñas o organizaciones más grandes con equipos altamente alineados. Es bueno cuando los distintos esfuerzos requieren procesos diferentes. Resulta útil como parte de las migraciones heredadas de TFS y para los límites de seguridad duros entre 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 lo mejor a esta escala es que todos los equipos trabajen en los 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, entre otros. Procesos independientes para cada proyecto. Por ejemplo, diferentes tipos de elementos de trabajo, campos personalizados, entre otros. Igual que muchos proyectos.
Colaboración Mayor visibilidad predeterminada y reutilización entre el trabajo y los recursos de diferentes equipos. Es posible una buena visibilidad y reutilización, pero es más fácil ocultar los recursos entre proyectos, ya sea intencionado. Visibilidad, colaboración y reutilización deficientes entre organizaciones.
Implementación de informes y administración de carteras Mejor capacidad de succión entre equipos y coordinación entre equipos. Buenos informes posibles en todos los proyectos. Más difícil para la implementación entre proyectos y la coordinación de equipos. No hay ninguna implementación ni coordinación entre organizaciones.
Seguridad/aislamiento Puede bloquear los recursos en un nivel de equipo, pero el valor predeterminado es la visibilidad y colaboración abiertas. Mejor capacidad para bloquear entre proyectos. De forma predeterminada, proporciona una buena visibilidad dentro de los proyectos y un buen aislamiento entre proyectos. Límites duros entre organizaciones; aislamiento excelente y capacidad mínima de compartir entre organizaciones.
Cambio de contexto Es más fácil para los equipos trabajar juntos y para que los usuarios cambien entre los esfuerzos. Es relativamente fácil que los usuarios trabajen juntos y cambien contextos entre los esfuerzos. Más difícil para los usuarios que tienen que trabajar en distintas 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 ocultos entre 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 Se delega mucha administración en equipos individuales. Más fácil para las licencias de usuario y la administración de nivel de organización. Es posible que sea necesario realizar un trabajo adicional si se requiere alineación entre los esfuerzos. Administración adicional en el nivel de proyecto. Sobrecarga adicional, pero puede ser útil cuando los proyectos tienen necesidades administrativas diferentes. Al igual que con los proyectos adicionales, hay una sobrecarga administrativa adicional, lo que permite flexibilidad adicional entre organizaciones.

Repositorios de estructura y control de versiones dentro de un proyecto

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

Para configurar el proyecto, visite su dirección URL y seleccione Project configuración en la parte inferior izquierda de la página.

Captura de pantalla que muestra Project de configuración.

Para más información sobre la administración de 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 más información sobre cómo migrar el proyecto, consulte Opciones de migración.

Administración del control de versiones

En los proyectos donde el Azure Repos está habilitado, 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 puedan elegir:

  • 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 flexibilidad en los flujos de trabajo de desarrollador e se 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 el número 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. Sin embargo, dentro de ese repositorio, las carpetas y las ramas se usan para organizar el código de varios productos y servicios, si se desea. Los proyectos pueden usar TFVC y Git, si procede.

Uno frente a muchos repositorios

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

Un proyecto que contiene varios repositorios funciona bien si los productos o servicios funcionan en una programación de versión coordinada. Si los desarrolladores trabajan con frecuencia con varios repositorios, consúltelos en un solo proyecto para asegurarse de que los procesos permanecen 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 el cumplimiento 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 mantiene un historial de confirmaciones de plena fidelidad. Otros historiales, como las solicitudes de extracción o el historial de compilación, no se migran fácilmente.

La decisión de uno frente a muchos repositorios debe basarse en gran medida en las dependencias de código y la arquitectura. Una buena primera regla que se debe aplicar es colocar 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 no hay herramientas que ayuden a coordinar esos cambios. Si el código base ya es un monolítica, manténgalo en un repositorio. Para obtener más información sobre los repositorios monolíticas, consulte Cómo Microsoft desarrolla software moderno con DevOps artículos. Si tiene muchos servicios desconectados, un repositorio por servicio es una buena estrategia.

Nota

Considere la posibilidad de administrar los permisos para que no todos los usuarios de su organización puedan crear un repositorio. Un desafío al que se enfrentan cada vez más equipos o empresas es la rápida proliferación de repositorios. Si tiene demasiados repositorios, es difícil realizar un seguimiento de quién posee qué 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í. Usado 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 más información sobre la estrategia de bifurcación y versión, consulte Adopt a Git branching strategy (Adopción de una estrategia de bifurcación de Git) y Release Flow: Our Branching Strategy(Adopción de una estrategia de bifurcación de Git) y Release Flow: Our Branching Strategy ( Nuestra estrategia de bifurcación).

Las bifurcaciones pueden ser útiles cuando se trabaja con equipos de proveedores 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. Cuando trabaje 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, vea 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.

Más información sobre la estructura organizativa

Elección del tipo de cuenta de administrador de la organización

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

Uso de su cuenta Microsoft

Use su cuenta Microsoft si no necesita autenticar a los usuarios de una organización con Azure AD. Todos los usuarios deben iniciar sesión en su organización con una cuenta Microsoft. Si no tiene una, puede crear una cuenta Microsoft ahora.

Escriba su contraseña e inicie sesión.

Si no tiene una instancia de Azure AD, cree una de forma gratuita desde el Azure Portal o use su cuenta Microsoft para crear una organización. A continuación, puede conectar su organización a Azure AD.

Uso de la cuenta Azure AD cliente

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

Si no tiene una cuenta de Azure AD, obtenga información sobre cómo registrarse en Azure AD para conectar automáticamente su organización a su Azure AD. Todos los usuarios deben ser miembros de ese directorio para acceder a su organización. Para agregar usuarios de otras organizaciones, use Azure AD colaboración B2B.

Azure DevOps autentica a los usuarios a través de su Azure AD, de modo que solo los usuarios que son miembros de ese directorio tengan acceso a su organización. Cuando se quitan usuarios de ese directorio, ya no pueden acceder a su organización. Solo los administradores Azure AD específicos 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 la administración de usuarios, vea Administrar usuarios.

Asignación de organizaciones a unidades de negocio

Cada unidad de negocio dentro de la empresa obtiene su propia organización en Azure DevOps, junto con su propio Azure AD inquilino. 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 diferentes cuentas de usuario (lo más probable es que Azure AD cuentas). Tenga en cuenta qué grupos y usuarios comparten estrategias y trabajo, y a agruparlos en organizaciones específicas. Por ejemplo, la empresa (ficticia) Fabrikam podría crear tres organizaciones: Fabrikam-Marketing, Fabrikam-Engineering y Fabrikam-Sales. Cada organización tiene una dirección URL independiente, como https://dev.azure.com/Fabrikam-Marketinghttps://dev.azure.com/Fabrikam-Engineering , y https://dev.azure.com/Fabrikam-Sales. Todas las organizaciones son para la misma empresa, pero están aisladas unas de otras. No es necesario separar nada, pero solo debe crear límites cuando tenga sentido para su negocio. Puede crear particiones de una organización existente con proyectos más fácilmente que combinar diferentes organizaciones.