Hacer que el proyecto privado sea público

Azure DevOps Services

Cuando decide hacer público un proyecto, se incluyen todos sus contenidos. No puede elegir repositorios, rutas de acceso de área o carpetas de compilación específicos para mantener la propiedad privada.

El acceso está limitado cuando el usuario no ha iniciado sesión. Estos usuarios también se conocen como usuarios anónimos o usuarios públicos. Además, hay usuarios que han iniciado sesión en Azure DevOps, pero no son miembros de un proyecto. A ambos tipos de usuarios se les concede acceso limitado de solo lectura, como se indica en la tabla siguiente.

Todos los miembros del proyecto experimentan los siguientes efectos cuando se hace público un proyecto privado:

• No se respetan los permisos marcados como Denegar . Los permisos concedidos automáticamente a un miembro actúan como "floor" en las funcionalidades que se pueden asignar a cualquier miembro del proyecto.
• Si una canalización de compilación especifica un ámbito de colección de proyectos, se ejecuta con el ámbito de Project en su lugar, lo que reduce los riesgos de un usuario malintencionado que obtiene el token de autenticación del servicio de compilación.
• Las partes interesadas tienen acceso total a las características de repositorios o código en proyectos públicos, pero no tienen acceso en proyectos privados.
• Las partes interesadas tienen acceso total a los paneles o trabajar en proyectos públicos, pero tienen acceso parcial en proyectos privados. Para obtener más información, consulte Referencia rápida sobre el acceso a las partes interesadas.
• 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	lectura	lectura y escritura	read-write-administer
Wiki	lectura	full	full	lectura	lectura y escritura	read-write-administer
Paneles (trabajo)	lectura	partial	full	lectura	lectura y escritura	read-write-administer
Repositorios (código)	lectura	full	full	lectura	lectura y escritura	read-write-administer
Canalizaciones (compilación y versión)	lectura	full	full	lectura	lectura y escritura	Read-Write-Administer
Test Plans	sin acceso	sin acceso	acceso parcial (consulte la última viñeta anterior a la tabla)	lectura	lectura y escritura	Read-Write-Administer
Notificaciones	sin acceso	Completo	Completo	Leer	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

• Debe tener una organización creada en Azure DevOps. Si no tienes una, haz eso ahora.
• Debe ser miembro del grupo Administradores de la colección de proyectos. Los propietarios de la organización son automáticamente miembros de este grupo.
• Comprenda [niveles de acceso y características no disponibles para proyectos públicos]. (#access-levels-and-unavailable-features-for-public-projects).
• Tenga en cuenta las opciones de migración parcial.
• Revise los elementos de la lista de comprobación de migración.

Lista de comprobación para la migración

La mayoría de los proyectos privados existentes contienen una gran cantidad de datos históricos. Es posible que los elementos de trabajo antiguos, las confirmaciones tempranas y las canalizaciones de compilación anteriores tengan contenido que no quiera compartir públicamente.

La siguiente lista de comprobación indica los elementos que puede que desee revisar antes de que un proyecto sea público. 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. Si no está familiarizado con exponer toda la base de datos de elementos de trabajo, hay opciones de migración. Para obtener más información, vea Instrucciones para mover elementos de trabajo.

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.

Tenga en cuenta que 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 de prueba de carga manual y en la nube no están disponibles para los no 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 los no 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. Las fuentes públicas no pueden tener orígenes ascendentes. 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 ha puesto a disposición de los no miembros mediante su prueba. Si no es así, pida al autor de la extensión que agregue compatibilidad con los no miembros. Para obtener más información, consulte Extensiones y compatibilidad con proyectos públicos.

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. Desde el explorador web, inicie sesión en Azure DevOps. Debe haber iniciado sesión para crear un proyecto público.

2. Elija Azure DevOps para abrir Proyectos. A continuación, elija Configuración de la organización.

   

3. Elija la página Directivas y seleccione Activado para Permitir proyectos públicos.

   

2. Hacer que un proyecto privado sea público

1. Elija Configuración del proyecto en la barra lateral.

   

2. Elija Overview (Información general).

3. Para cambiar de privado a público, elija Público en el menú Visibilidad de las opciones.

   

   Para cambiar de público a privado, elija Privado en el menú Visibilidad de las opciones.

4. Elija Guardar.

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 es compatible con los 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.

Nota:

Al habilitar el acceso gratuito a la característica de versión preliminar Canalizaciones para partes interesadas de la organización, las partes interesadas obtienen acceso a todas las características de canalización . Sin esta característica habilitada, las partes interesadas solo pueden ver y aprobar las versiones. Para más información, consulte Proporcionar a las partes interesadas acceso para editar canalizaciones de compilación y versión.

Además, los no miembros no pueden realizar las siguientes tareas:

• Edite o cree artefactos, como archivos, elementos de trabajo y canalizaciones.
• Favoritos y siguen los artefactos existentes.
• Ver las direcciones de correo electrónico de los miembros del proyecto y otra información de contacto; los 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 toda una organización.

Migración parcial

Las organizaciones que contienen material confidencial no deben habilitar la directiva de proyectos públicos. En ese caso, se recomienda crear una organización completamente independiente para hospedar los proyectos públicos.

Mover elementos de trabajo a un proyecto privado

Si uno o varios elementos de trabajo son confidenciales, puede moverlos a un proyecto privado independiente. Los vínculos entre proyectos siguen funcionando para los miembros. Los no miembros no tendrán 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 la sugerencia 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 importa hacer público.

Advertencia

El nuevo repositorio no tendrá conexión con la antigua. No podrá migrar fácilmente los cambios entre ellos en el futuro. Además, el historial de solicitudes de incorporación de cambios no se migrará.

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