Partekatu honen bidez:

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

  • Artikulua

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, todo su contenido se convierte en público. No es posible mantener de forma selectiva determinados repositorios, rutas de acceso de área ni carpetas de compilación privadas.

Seguridad

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

  • Permisos: no se reconocen los permisos marcados como Denegar . Los miembros no miembros reciben automáticamente un nivel mínimo de funcionalidades que se pueden asignar a cualquier miembro del proyecto.
  • Canalizaciones de compilación: si una canalización de compilación está establecida 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.
  • Partes interesadas:
    • Repositorios: las partes interesadas tienen acceso total a estas características en proyectos públicos, pero no tienen acceso en proyectos privados.
    • Paneles: las partes interesadas tienen acceso total 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.
  • Usuarios de Basic + Test Plans: los usuarios de Basic + Test Plans pueden ver y ejecutar pruebas desde Planes de prueba. Los usuarios básicos pueden actualizar su nivel de acceso a Basic + Test Plans para obtener acceso completo, incluida la capacidad de crear planes de prueba y agregar casos de prueba.

Access

El acceso está restringido para los usuarios que no han iniciado sesión (usuarios anónimos o públicos) y los usuarios que han iniciado sesión, pero no son miembros de un proyecto (miembros que no son de proyecto). Ambas categorías de usuarios, denominadas no miembros, tienen acceso limitado de solo lectura, como se describe en la tabla siguiente.

Hub/Settings Acceso no miembro Acceso de Parte interesada Acceso Básico Acceso de lector Acceso de colaborador Acceso de administrador de proyectos
Paneles read, + 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
Boards leer partial full leer lectura y escritura read-write-administer
Repos leer full full leer lectura y escritura read-write-administer
Canalizaciones leer full full leer lectura y escritura read-write-administer
Test Plans sin acceso sin acceso acceso parcial leer lectura y escritura read-write-administer
Notificaciones sin acceso full full leer lectura y escritura read-write-administer
Búsqueda full full full full full full
Configuración sin acceso full full leer leer 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 bloqueada especial. 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

Antes de cambiar un proyecto privado a un proyecto público, habilite el acceso anónimo para su organización siguiendo estos pasos:

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

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

    Captura de pantalla que muestra el botón Configuración de la organización resaltado.

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

    Captura de pantalla que muestra la configuración de la organización, la página Directiva, el flujo de directivas de seguridad.

2. Establecer la visibilidad del proyecto

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

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

    Captura de pantalla que muestra la configuración del proyecto, información general, flujo de visibilidad.

Elementos de interfaz de usuario limitados para proyectos públicos

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:

  • Edite o cree artefactos, como archivos, elementos de trabajo y canalizaciones.
  • Favorito 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 nombres e imágenes. 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 solo pueden ir directamente a un proyecto público mediante una dirección URL.
  • Realizar búsquedas de código o elemento de trabajo en toda una organización.

Agregar colaboradores a un proyecto público

Para contribuir a un proyecto público, se agrega como miembro y se le asigna acceso a partes interesadas, básicas o básicas y planes de prueba. Para obtener más información, vea 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 las implicaciones de invitar a un usuario externo. Si ha creado el proyecto, se le asigna automáticamente al grupo Administradores de proyectos.

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.

Realice los pasos siguientes para migrar solo la sugerencia de Git:

  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