Acerca de los proyectos y el escalado de la organización

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

Un proyecto proporciona un repositorio para el código fuente y un lugar para que los usuarios planeen, realicen un seguimiento del progreso y colaboren en la creación de soluciones de software. Un proyecto representa un contenedor fundamental donde se almacenan los datos cuando se agregan a Azure DevOps.

Al crear el proyecto, se crea automáticamente un equipo con el mismo nombre. Esto es suficiente para equipos pequeños. Sin embargo, para las organizaciones de nivel empresarial, puede ser necesario escalar verticalmente para crear equipos y proyectos adicionales. Estas adiciones se pueden crear dentro de la única cuenta o colección.


Proyecto único y equipo definidos dentro de
una organización o colección

Varios proyectos y equipos definidos dentro de
una organización o colección


Conceptual image, Scaled collection-project-team. null


La estructura collection-project-team proporciona a los equipos un alto nivel de autonomía para configurar sus herramientas de maneras que funcionen para ellos. También admite que las tareas administrativas se produzcan en el nivel adecuado. A medida que crece la organización, las herramientas pueden crecer para admitir una cultura de autonomía de equipo y alineación organizativa.

¿Cómo se administra el trabajo en toda la empresa?

¿Cómo se escalan las herramientas DevOps y Agile para dar soporte a su empresa en crecimiento?

Cuando se conecta a Azure DevOps, se conecta a una organización o colección de proyectos. Dentro de ese contenedor, se pueden definir uno o varios proyectos. Se debe crear al menos un proyecto para usar el sistema.

Puede escalar la organización de las maneras siguientes:

  • Para admitir diferentes unidades de negocio, puede agregar proyectos
  • Dentro de un proyecto, puede agregar equipos
  • Agregar repositorios y ramas
  • Para admitir la integración e implementación continuas, puede agregar agentes, grupos de agentes y grupos de implementación.
  • Para administrar un gran número de usuarios, puede administrar el acceso a través de Azure Active Directory

Puede escalar la implementación local Azure DevOps de las siguientes maneras:

  • Para aumentar el rendimiento, puede agregar instancias de servidor
  • Para admitir diferentes unidades de negocio, puede agregar proyectos y colecciones de proyectos.
  • Dentro de un proyecto, puede agregar equipos
  • Agregar repositorios y ramas
  • Para admitir la integración e implementación continuas, puede agregar agentes, grupos de agentes y grupos de implementación.
  • Para administrar un gran número de usuarios, puede administrar el acceso a través de Active Directory

Azure DevOps Services y Azure DevOps Server son plataformas listas para la empresa. Estas plataformas admiten equipos de cualquier tamaño, de decenas a miles. Azure DevOps Services, nuestro servicio en la nube, proporciona un servicio hospedado escalable, confiable y disponible globalmente. Cuenta con el respaldo de un Acuerdo de Nivel de Servicio del 99,9 %, supervisado por nuestro equipo de operaciones 24 horas al día y disponible en centros de datos locales de todo el mundo.

Visualización de proyectos

Para ver los proyectos definidos para su organización, abra la página Proyectos.

  1. Seleccione Azure DevOps para abrir Proyectos.

    Abrir proyectos

  2. Desde allí, puede elegir un proyecto del conjunto de proyectos enumerado.

Para crear o enumerar proyectos, consulte Creación de un proyecto

  1. Seleccione Azure DevOps para abrir Proyectos.

    Captura de pantalla del botón Abrir proyectos, navegación horizontal

  2. Desde allí, puede elegir un proyecto del conjunto de proyectos enumerado.

    Elija un proyecto del conjunto de proyectos enumerado.

  1. Elija el nombre del servidor.

    Captura de pantalla de proyectos abiertos, TFS 2013 - 2015

  2. Desde allí, puede elegir un proyecto del conjunto de proyectos enumerado.

Limitación de la visibilidad del usuario para los proyectos mediante el grupo Project-Scoped usuarios

De forma predeterminada, los usuarios agregados a una organización pueden ver toda la información y la configuración de la organización y del proyecto.

La característica limitar la visibilidad del usuario para proyectos en versión preliminar de la organización limita el acceso de los usuarios de dos maneras:

  • Restringir las vistas que muestran la lista de usuarios, la lista de proyectos, los detalles de facturación, los datos de uso y mucho más a los que se accede a través de la Configuración .
  • Limitar el conjunto de personas o grupos que aparecen a través de las selecciones de búsqueda del selector de personas y la capacidad de los @mention usuarios.

Importante

Las características de visibilidad limitadas descritas en esta sección solo se aplican a las interacciones a través del portal web. Con las API REST o los comandos de la CLI de Azure Devops, los miembros del proyecto pueden acceder a los datos restringidos.

Limitar el acceso a la configuración de la organización

Para restringir usuarios selectos, como partes interesadas, Azure Active Directory usuarios invitados o miembros de un grupo de seguridad determinado, puede habilitar la característica de vista previa Limitar visibilidad de usuarios para proyectos para la organización. Una vez habilitado, cualquier usuario o grupo agregado al grupo Usuarios con ámbito Project, tiene restringido el acceso a las páginas de Configuración organización, excepto para Información general y Proyectos ; y están restringidos a acceder solo a los proyectos a los que se han agregado.

Para habilitar esta característica, consulte Administración o habilitación de características.

Nota

Todos los grupos de seguridad son entidades de nivel de organización, incluso aquellos grupos que solo tienen permisos para un proyecto específico. Desde el portal web, los usuarios sin acceso a un proyecto no pueden ver los grupos que solo tienen permisos para un proyecto específico. Sin embargo, puede detectar los nombres de todos los grupos de una organización mediante la herramienta de la CLI de Azure Devops o nuestras API REST. Para más información, consulte Adición y administración de grupos de seguridad.

Limitar la visibilidad dentro de los selectores de personas

En el caso de las organizaciones que administran usuarios y grupos mediante Azure Active Directory (Azure AD), los selectores de personas proporcionan compatibilidad para buscar todos los usuarios y grupos agregados a Azure AD, no solo los usuarios y grupos agregados al proyecto. Los selectores de personas admiten las Azure DevOps siguientes:

  • Selección de una identidad de usuario desde un campo de identidad de seguimiento de trabajo como Asignado a
  • Selección de un usuario o grupo mediante en una discusión de elementos de trabajo o un campo de texto enriquecido, una discusión de solicitud de extracción, comentarios de confirmación o comentarios de conjunto de cambios @mention o conjunto de cambios
  • Selección de un usuario o grupo mediante @mention una página wiki

Como se muestra en la siguiente imagen, basta con empezar a escribir en un cuadro de selección de personas hasta que encuentre una coincidencia con un nombre de usuario o grupo de seguridad.

Captura de pantalla del selector de personas

Advertencia

Cuando la característica de vista previa Limitar visibilidad de usuarios para proyectos está habilitada para la organización, los usuarios con ámbito de proyecto no pueden buscar usuarios que se agregaron Azure Active Directory la organización Azure Active Directory través de la pertenencia Azure Active Directory grupos, en lugar de a través de una invitación de usuario explícita. Se trata de un comportamiento inesperado en el que se está trabajando una resolución. Para resolver este problema de forma independiente, deshabilite la característica limitar la visibilidad del usuario para proyectos en versión preliminar para la organización.

Los usuarios y grupos que se agregan al grupo Usuarios con ámbito Project solo pueden ver y seleccionar usuarios y grupos en el proyecto al que están conectados desde un selector de personas. Para limitar el ámbito de los selectores de personas para todos los miembros del proyecto, vea Administrar el proyecto, Limitar búsqueda de identidad y selección.

Los datos históricos permanecen visibles

Las identidades que se han agregado a un comentario, discusión o asignación siguen siendo visibles para todos los miembros del proyecto. Por ejemplo, los elementos de trabajo que se asignaron a un usuario que ha dejado un proyecto desde entonces, el nombre del usuario en ese elemento de trabajo sigue siendo visible para todos los usuarios del proyecto, incluso para los usuarios con la nueva restricción. Lo mismo sucede con @mentions las preguntas y las preguntas, los comentarios, las discusiones, etc.

Cuándo agregar otro proyecto

En general, se recomienda usar un solo proyecto para admitir su organización o empresa. Un solo proyecto minimiza el mantenimiento de las tareas administrativas y admite la experiencia de objeto entre vínculos más optimizada o con flexibilidad completa.

Incluso si tiene muchos equipos trabajando en cientos de aplicaciones y proyectos de software diferentes, puede administrarlos más fácilmente dentro de un único proyecto. Un proyecto sirve para aislar los datos almacenados en él. No se pueden mover fácilmente datos de un proyecto a otro. Cuando se mueven datos de un proyecto a otro, normalmente se pierde el historial asociado a los datos.

Para obtener más información sobre cuándo agregar otro proyecto, vea ¿Cuántos proyectos necesita?.

Motivos para agregar otro proyecto

Es posible que desee agregar otro proyecto en las instancias siguientes:

  • Para prohibir o administrar el acceso a la información contenida en un proyecto para seleccionar grupos
  • 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
  • Para admitir un proyecto de software de código abierto (OSS)

Es posible que desee agregar otro proyecto en las instancias siguientes:

  • Para prohibir o administrar el acceso a la información contenida en 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

Proyectos privados y públicos

Puede agregar proyectos públicos y privados a su organización. También puede cambiar la visibilidad de un proyecto de privado a público.

Los proyectos privados requieren que agregue y administre el acceso de los usuarios. Los usuarios deben iniciar sesión para obtener acceso a un proyecto, incluso si se trata de acceso de solo lectura. Todos los usuarios agregados a un proyecto tienen acceso a la información del proyecto y de la organización. Para más información, consulte Recursos concedidos a los miembros del proyecto.

Un proyecto público no requiere que los usuarios inicien sesión para obtener acceso de solo lectura a muchos de los servicios. Los proyectos públicos proporcionan compatibilidad para compartir código con otros usuarios y para admitir la integración continua/implementación continua (CI/CD) de software de código abierto. Para obtener más información sobre los proyectos públicos, vea ¿Qué es un proyecto público?.

Estructuración del proyecto

Al agregar un proyecto, vea el uso de los siguientes elementos para estructurarlo para satisfacer sus necesidades empresariales:

Personalización y configuración de proyectos

Puede configurar y personalizar la mayoría de los servicios y aplicaciones para satisfacer sus necesidades empresariales o la forma en que trabajan sus equipos. Dentro de cada proyecto, puede realizar las siguientes tareas. Para obtener una vista completa de los recursos que se pueden configurar, vea Acerca de la configuración de equipo, proyecto y nivel de organización.

  • Paneles: cada equipo puede configurar su conjunto de paneles para compartir información y supervisar su progreso.
  • Control de código fuente: para cada repositorio de Git,puede aplicar directivas de rama y definir permisos de rama. En el caso de los repositorios de TFVC, puede establecer directivas de protección.
  • Seguimiento de trabajo: puede agregar campos, cambiar el flujo de trabajo, agregar reglas personalizadas y agregar páginas personalizadas al formulario de elemento de trabajo de la mayoría de los tipos de elementos de trabajo. También puede agregar tipos de elementos de trabajo personalizados. Para más información, consulte Personalización de un proceso de herencia.
  • Azure Pipelines: puede personalizar completamente las canalizaciones de compilación y versión, definir pasos de compilación, entornos de versión y programación de implementación. Para más información, consulte Compilación y versión.
  • Azure Test Plans: puede definir y configurar planes de pruebas, conjuntos de pruebas, casos de prueba y entornos de prueba. También puede agregar pasos de prueba dentro de las canalizaciones de compilación. Para más información, consulte Exploración & pruebas manuales y pruebas continuas para las compilaciones.
  • Paneles: cada equipo puede configurar su conjunto de paneles para compartir información y supervisar su progreso.
  • Control de código fuente: para cada repositorio de Git,puede aplicar directivas de rama y definir permisos de rama. En el caso de los repositorios de TFVC, puede establecer directivas de protección.
  • Seguimiento de trabajo: puede agregar campos, cambiar el flujo de trabajo, agregar reglas personalizadas y agregar páginas personalizadas al formulario de elemento de trabajo de la mayoría de los tipos de elementos de trabajo. También puede agregar tipos de elementos de trabajo personalizados. Para obtener más información, vea Personalizar el modelo de proceso XML local.
  • Compilación y versión: puede personalizar completamente las canalizaciones de compilación y versión, definir pasos de compilación, entornos de versión y programación de implementación. Para más información, consulte Compilación y versión.
  • Prueba: puede definir y configurar planes de pruebas, conjuntos de pruebas, casos de prueba y entornos de prueba. También puede agregar pasos de prueba dentro de las canalizaciones de compilación. Para más información, consulte Exploración & pruebas manuales y pruebas continuas para las compilaciones.

Cuándo agregar un equipo, escalado de las herramientas de Agile en toda la empresa

A medida que crece la organización, agregue equipos para proporcionarles las herramientas de Agile que cada equipo puede configurar para satisfacer su flujo de trabajo. Para más información, consulte los siguientes artículos:

  • Escala de Agile a equipos grandes
  • Acerca de los equipos y las herramientas de Agile
  • Administre una cartera de trabajo pendiente y obtenga información sobre el progreso de cada equipo y el progreso de todos los programas.
  • Use planes de entrega para revisar la programación de casos o características que los equipos planean entregar. Los planes de entrega muestran los elementos de trabajo programados por sprint (ruta de iteración) de los equipos seleccionados en una vista de calendario.
  • Adopte de forma incremental prácticas que se escalan para crear un ritmo y un flujo mayores dentro de la organización, atraer a los clientes, mejorar la visibilidad del proyecto y desarrollar un personal productivo.
  • Estructura proyectos para obtener visibilidad entre equipos o para admitir epopeyas, entrenamientos de versión y varios trabajos pendientes para admitir Scaled Agile Framework.

Para revisar historias y vídeos cortos sobre cómo Microsoft ha pasado de la cascada a Agile, consulte Escalado de Agile a través del Enterprise.

Clientes que admiten la conexión a un proyecto

Además de conectarse a través de un explorador web, puede conectarse a un proyecto desde los siguientes clientes:

Consulte también Compatibilidad con Azure DevOps Server versiones.

Preguntas y respuestas

P: ¿Puedo mover o transferir un proyecto a otra organización o colección?

A: No sin perder datos. No se puede mover un proyecto de una colección o organización a otra recopilación o organización sin perder datos. Puede copiar recursos manualmente y dejar algunos, o usar una herramienta de terceros, como OpsHub Visual Studio Migration Utility,que copia datos mediante las API REST.

P: ¿Qué herramientas de programación admiten proyectos?

R. Consulte Projects REST API (API rest de proyectos).

Además, puede usar los comandos del proyecto az devops.