Compartir vía

Cambio de la visibilidad del proyecto a público o privado

  • Artículo

Azure DevOps Services

En este artículo, aprenderá a cambiar la visibilidad del proyecto a público o privado.

Al cambiar un proyecto privado a visibilidad pública, abarca todo su contenido. No es posible mantener de forma selectiva determinados repositorios, rutas de acceso de área ni carpetas de compilación privadas.

El acceso está restringido para los usuarios que no han iniciado sesión, a menudo denominados usuarios anónimos o públicos. También hay usuarios que han iniciado sesión en Azure DevOps, pero no forman parte de un proyecto. Ambas categorías de usuarios tienen acceso limitado y de solo lectura, como se describe en la tabla siguiente.

Al cambiar un proyecto privado a público, todos los miembros del proyecto experimentan los cambios siguientes:

  • Los permisos marcados como Denegar no se reconocen. Los permisos concedidos automáticamente a un miembro no miembro establecen un nivel mínimo de funcionalidades que se pueden asignar a cualquier miembro del proyecto.
  • Si una canalización de compilación se establece en el ámbito de la colección de proyectos, se ejecuta con un ámbito de Proyecto en su lugar, lo que reduce el riesgo de que los usuarios malintencionados obtengan acceso al token de autenticación del servicio de compilación.
  • Las partes interesadas tienen acceso total a las características repos o code de los proyectos públicos, pero no tienen acceso a proyectos privados.
  • Las partes interesadas tienen acceso total a las juntas o a trabajar en proyectos públicos, pero solo tienen acceso parcial en proyectos privados. Para obtener más información, consulte Referencia rápida sobre el acceso de parte interesada.
  • Los usuarios de Basic + Test Plans pueden ver y ejecutar pruebas desde Test Plans o Test. Los usuarios básicos deben actualizar su nivel de acceso a Basic + Test Plans para obtener acceso completo, lo que incluye la capacidad de crear planes de prueba y agregar casos de prueba.
Hub/Settings Acceso no miembro Acceso de Parte interesada Acceso Básico Acceso de lector Acceso de colaborador Acceso a Project Administración
Paneles leer (muchos widgets no están disponibles) partial full leer lectura y escritura read-write-administer
Wiki leer full full leer lectura y escritura read-write-administer
Paneles (trabajo) leer partial full leer lectura y escritura read-write-administer
Repositorios (código) leer full full leer lectura y escritura read-write-administer
Canalizaciones (compilación y versión) leer full full leer lectura y escritura Read-Write-Administer
Test Plans sin acceso sin acceso acceso parcial (consulte la última viñeta anterior a la tabla) leer lectura y escritura Read-Write-Administer
Notificaciones sin acceso Completo Completo Lectura lectura y escritura read-write-administer
Búsqueda full full full full full full
Configuración Sin acceso Completo Completo Lectura Lectura Read-Write-Administer

Requisitos previos

Lista de comprobación para la migración

La mayoría de los proyectos privados contienen una gran cantidad de datos históricos. Los elementos de trabajo antiguos, las confirmaciones anticipadas y las canalizaciones de compilación anteriores pueden contener información que no desea compartir públicamente.

La siguiente lista de comprobación indica los elementos que puede revisar antes de hacer público un proyecto. También proporciona sugerencias para migrar elementos de trabajo o archivos a un nuevo proyecto para que solo pueda exponer contenido actual y futuro.

Categoría

Guía

Identidades y configuraciones de la organización

Comprenda que un usuario obtiene acceso a los siguientes recursos y detalles sobre la organización:

  • Identidades: lista de todos los miembros agregados a la organización y a la dirección de correo electrónico de cada miembro.
  • Configuración: vista de solo lectura de toda la organización y la configuración del proyecto.
  • Metadatos de proceso: todos los valores de lista desplegable de todos los proyectos de la organización.
  • Compilaciones y versiones: nombres de personas que las desencadenó, además de identidades, incluidas las direcciones de correo electrónico insertadas en confirmaciones de Git.
  • Confirmaciones y elementos de trabajo: información insertada, como el nombre, el apellido y la dirección de correo electrónico.

Vínculos a objetos entre proyectos

Compruebe si existen vínculos entre proyectos, ya que los detalles sobre el artefacto vinculado del proyecto privado están visibles en el proyecto público. Puede usar los siguientes tipos de vínculo: rama, compilación, conjunto de cambios, confirmación, que se encuentra en la compilación, integrada en la compilación, solicitud de incorporación de cambios y elemento con versiones. Los títulos y nombres se exponen en los siguientes tipos de vínculos: elemento con versión, rama, página wiki, solicitud de incorporación de cambios y elemento de trabajo.

Herramientas ágiles y elementos de trabajo

Confirme que los elementos de trabajo, incluso los cerrados, no contienen detalles confidenciales: errores de seguridad, credenciales y datos de cliente no cerrados. Los elementos de trabajo mantienen su historial cuando se migran de un proyecto privado a público. Todos los debates y descripciones están disponibles. Compruebe que ninguno contiene voz problemática.

Confirme que ninguna de las rutas de acceso de área tiene una configuración de seguridad especial bloqueada. Los permisos denegados no se aplican en un proyecto público, por lo que las rutas de acceso de área restringidas se convierten en públicas.

Código

Confirme que no tiene detalles confidenciales en el historial de los repositorios: errores de seguridad sin revisión, credenciales y código que no tiene derecho a distribuir.

Todos los contenidos de los archivos y los mensajes de confirmación están disponibles. Compruebe que ninguno contiene voz problemática. Si no está familiarizado con exponer un repositorio completo, puede migrar la sugerencia a otro proyecto. Para obtener más información, consulte Instrucciones para una migración de propinas.

Compilación y versión

Confirme que ninguna de las canalizaciones expone datos confidenciales: credenciales o secretos, direcciones URL ocultas y nombres de entorno privados.

Confirme que los no miembros no requieren acceso a las fuentes privadas. Las compilaciones todavía pueden acceder a fuentes, pero no pueden ser miembros. Si necesita migrar canalizaciones de compilación a un nuevo proyecto, puede importarlas y exportarlas mediante YAML.

Prueba

Comprenda que las características manuales y de pruebas de carga en la nube no están disponibles para miembros de un proyecto público.

Análisis y paneles

Considere la posibilidad de crear un panel destinado al público. Algunos widgets no están disponibles para miembros que no son miembros.

Artefactos

Confirme que ninguno de los paquetes de ninguna de las fuentes cuyo ámbito es el proyecto tiene problemas de privacidad. Todos los paquetes de las fuentes cuyo ámbito es el proyecto se convierten en públicos. Todas las configuraciones ascendentes existentes de las fuentes cuyo ámbito es el proyecto se deshabilitan una vez que el proyecto se convierte en público.

Extensiones

Confirme si hay extensiones vitales para la experiencia del proyecto. Por ejemplo, ¿tiene un control en el formulario de elemento de trabajo que representa los datos de una manera determinada? ¿Hay extensiones personalizadas que exponen detalles importantes?

Confirme que el autor de cada extensión lo puso a disposición de los no miembros probando. Si no es así, pida al autor de la extensión que agregue compatibilidad con miembros que no sean miembros.

1. Habilitar el acceso anónimo a proyectos

Para poder cambiar un proyecto privado a un proyecto público, debe habilitar el acceso anónimo para su organización.

  1. Inicie sesión en su organización (https://dev.azure.com/{yourorganization}).

  2. Seleccione Configuración de la organización.

    Screenshot showing highlighted Organization settings button.

  3. Seleccione Directivas y, a continuación, active la directiva Permitir la seguridad de proyectos públicos.

    Screenshot showing Organization settings, Policy page, Security policies flow.

2. Establecer la visibilidad del proyecto

  1. Inicie sesión en el proyecto (https://dev.azure.com/{YourOganization}{YourProject}).

  2. Seleccione Configuración del proyecto>Información general> en el menú desplegable Visibilidad, elija Público o Privado y, a continuación, Guardar.

    Screenshot showing Project Settings, Overview, Visibility flow.

Niveles de acceso y características no disponibles para proyectos públicos

Un miembro del proyecto tiene acceso a características basadas en el nivel de acceso asignado. A los usuarios no miembros o públicos se les concede acceso limitado automáticamente. Para contribuir a un proyecto público, debe agregarse como miembro de ese proyecto y asignarle acceso a partes interesadas, Básicas o Básicas + Test Plans. Los niveles de acceso determinan las interfaces de usuario a las que puede acceder. El grupo de seguridad al que está asignado determina las características que puede ejercer. Para obtener más información, consulte Acerca de los niveles de acceso.

Los miembros del proyecto se agregan de la misma manera que para los proyectos privados. Asegúrese de comprender lo que significa invitar a un usuario externo a tener acceso al proyecto. Si ha creado el proyecto, se le asigna automáticamente al grupo Administradores de proyectos.

Los siguientes elementos de la interfaz de usuario están ocultos para los no miembros.

Servicio

Elementos ocultos de la interfaz de usuario

Boards

Los elementos de trabajo están disponibles, pero los trabajos pendientes, los paneles, los sprints, las consultas y los planes están ocultos.

Repos

Control de versiones de Team Foundation repositorios (TFVC) están ocultos.

Pipelines

Las compilaciones y versiones están disponibles, pero la biblioteca, los grupos de tareas, los grupos de implementación, los paquetes y el sistema de compilación XAML están ocultos. Los editores de canalizaciones y tareas para canalizaciones de compilación y versión no están disponibles. Solo la página Nuevas versiones, que se encuentra en versión preliminar pública, está disponible.

Test Plans

Test Plans y las características de pruebas de carga manuales y en la nube asociadas están ocultas.

Análisis

Las vistas de análisis están ocultas y la fuente OData de análisis no se admite para miembros que no son miembros. No se admite la integración de Power BI en general.

Configuración

La configuración y las páginas administrativas están ocultas.

Los miembros no pueden realizar las siguientes tareas:

  • Editar o crear artefactos, como archivos, elementos de trabajo y canalizaciones
  • Favoritos y seguimiento de artefactos existentes
  • Ver las direcciones de correo electrónico de los miembros del proyecto y otra información de contacto; los miembros que no son miembros solo pueden ver el nombre y la imagen. Además, filtre las listas de artefactos por identidad
  • Cambiar entre dos proyectos públicos en la misma organización; los miembros que no son miembros deben ir directamente a un proyecto público mediante una dirección URL
  • Realizar búsquedas de código o elemento de trabajo en una organización

Migración parcial

Si su organización contiene material confidencial, no debe activar la directiva de proyectos públicos. Se recomienda crear una organización completamente independiente para hospedar los proyectos públicos.

Mover elementos de trabajo a un proyecto privado

Si algún elemento de trabajo es confidencial, puede moverlos a un proyecto privado independiente. Los vínculos entre proyectos siguen funcionando para los miembros, pero los no miembros no tienen acceso al contenido, ya que reside en un proyecto privado.

Si tiene un gran número de elementos de trabajo confidenciales, considere la posibilidad de mantener privado el proyecto actual. En su lugar, cree un nuevo proyecto público en otra organización. La migración de elementos de trabajo se puede realizar mediante el código abierto WiMigrator mantenido por Microsoft.

Migración solo de sugerencias de Git

Si un repositorio no se puede compartir debido a un historial problemático, considere la posibilidad de realizar una migración de solo propina a un nuevo repositorio en un proyecto diferente. Mantenga el proyecto que contiene el repositorio problemático privado. Cree el nuevo repositorio en un proyecto que no le importe hacer público.

Advertencia

  • El nuevo repositorio no se conecta al anterior.
  • No se pueden migrar fácilmente los cambios entre ellos en el futuro.
  • El historial de solicitudes de incorporación de cambios no se migra.
  1. Clone el repositorio existente: git clone <clone_URL>.
  2. Asegúrese de que está en la raíz del repositorio: cd <reponame>.
  3. Asegúrese de que está en la punta de la rama desde la que desea empezar: git checkout main.
  4. Elimine los datos de Git: rmdir /s .git en Windows, rm -rf .git en macOS o Linux.
  5. Inicialice un nuevo repositorio de Git: git init.
  6. Cree un repositorio vacío en el proyecto público.
  7. Agregue el nuevo repositorio como origen remoto: git remote add origin <new_clone_URL>.
  8. Inserte el nuevo repositorio: git push --set-upstream origin main.

Pasos siguientes

Código con Git