Configurar permisos en Azure DevOps es uno de esos pasos que define qué tan seguro y ordenado será tu proyecto. Aquí aprenderás a administrar accesos para usuarios invitados, crear grupos personalizados y entender las políticas de seguridad que ofrece la plataforma para proyectos pequeños y medianos.

La idea es simple: en lugar de asignar permisos uno por uno, Azure DevOps te permite agruparlos y aplicarlos en bloque. Eso ahorra tiempo y reduce errores cuando tu equipo crece.

¿Qué políticas de seguridad ofrece Azure DevOps?

Dentro de organization settings, la sección de policies concentra las reglas generales que afectan cómo entran los usuarios y qué tipo de proyectos puedes tener. Es el primer lugar al que debes ir antes de tocar permisos individuales [01:30].

Estas son las opciones clave que encontrarás:

• Third party application access: habilita el login para aplicaciones que no son Outlook ni Office 365, útil cuando integras herramientas externas al ecosistema Microsoft.
• SSH authentication: activa o desactiva la autenticación por SSH, común para conectar repositorios desde la terminal.
• Public projects: permite crear proyectos visibles sin login. Cualquiera puede ver el contenido, pero nadie puede editarlo sin permisos.
• GitHub user invitations: deja invitar a personas con cuentas de GitHub aunque no tengan correo de Microsoft, por ejemplo Gmail.

¿Puedo invitar a alguien sin cuenta de Microsoft a Azure DevOps? Sí, pero debes habilitar la política de invitaciones de GitHub. Por defecto solo se aceptan cuentas de Outlook u Office 365.

¿Por qué los proyectos públicos aparecen deshabilitados al inicio?

Cuando creas una organización, la opción de proyectos públicos viene apagada por seguridad. Si quieres compartir un proyecto open source o mostrar tu trabajo, primero activas esta política y luego marcas el proyecto como público. Los visitantes podrán ver todo, pero no editar nada.

¿Cómo funciona la administración de permisos por grupos?

Azure DevOps maneja los permisos a través de grupos predefinidos que se crean automáticamente al iniciar la organización. Esto evita que tengas que configurar cada permiso de forma manual para cada persona [03:15].

Algunos grupos que vienen listos:

• Collection Administrators: otorga todos los privilegios de administrador sobre la organización.
• Grupos por área funcional: por ejemplo, uno enfocado en pruebas, que solo da acceso a las secciones de testing.
• Project Collection Valid Users: agrupa a quienes tienen acceso básico a los proyectos.

La lógica es asignar a cada persona el grupo que mejor refleje su rol, en lugar de configurar permisos sueltos.

¿Cómo crear un grupo personalizado paso a paso?

Los grupos predefinidos cubren casos comunes, pero a veces necesitas algo más específico. Crear un grupo propio te da control total sobre qué puede hacer cada miembro.

El flujo es este:

1. Entra a organization settings y ve a la sección de permissions.
2. Da clic en new group y asígnale un nombre, por ejemplo Platzi Group.
3. Agrega miembros al momento o crea el grupo vacío y añádelos después desde la pestaña members.
4. Configura los permisos en la pestaña correspondiente activando los accesos que necesite el equipo.

Los cambios se guardan automáticamente con cada ajuste, así que no hay un botón de save al final.

¿Qué accesos conviene activar para un usuario invitado?

Un usuario invitado normalmente necesita moverse por varias áreas del proyecto sin ser administrador. La configuración personalizada que muestra la clase activa los accesos generales más cuatro bloques específicos [05:40].

• General: permisos básicos para navegar la organización.
• Boards: para asignar tickets, ver tareas pendientes y participar en la planificación.
• Repos: acceso a los repositorios de código.
• Pipelines: para revisar y operar los flujos de integración y despliegue.

¿Cuál es la diferencia entre un grupo predefinido y uno personalizado? Los predefinidos cubren roles estándar como administrador o tester. Los personalizados los creas tú combinando permisos exactos para un caso particular de tu equipo.

Con esta configuración, el usuario invitado puede colaborar en el día a día del proyecto sin tener privilegios de administración sobre la organización completa. Es el balance ideal entre acceso y control para equipos pequeños.

¿Tu equipo trabaja con grupos predefinidos o prefieren crear grupos personalizados? Cuéntame en los comentarios cómo organizas los permisos en tus proyectos.