Si es miembro de una organización que ha migrado de Azure DevOps a GitHub, esta guía explicará los cambios en los flujos de trabajo para que la migración sea lo más fluida posible.
Estructura
En Azure DevOps, los repositorios se anidan dentro de los proyectos de equipo, por lo que la estructura del entorno tiene este aspecto:
- Organización
- Proyecto de equipo
- Repositorios
- Proyecto de equipo
- Repositorios
- Proyecto de equipo
Los permisos y la visibilidad fluyen desde el proyecto del equipo.
GitHub se estructura de forma diferente. Los repositorios se anidan directamente dentro de las organizaciones, que también contienen equipos:
- Cuenta de empresa
- Organización
- Equipos
- Repositorios
- Organización
- Equipos
- Repositorios
- Organización
Los permisos y la visibilidad se determinan mediante una combinación de pertenencia a la organización, pertenencia al equipo y permisos individuales.
El concepto de un proyecto de equipo, que se usa para agrupar repositorios en Azure DevOps, no existe en GitHub y tratar las organizaciones en GitHub como equivalente a proyectos de equipo no se recomienda.
Aunque inicialmente puede encontrar cada organización migrada en GitHub tiene una larga lista no organizada de repositorios, puede conceder acceso y permisos a través de equipos de miembros de la organización, lo que facilita mucho la navegación por los repositorios de la organización.
Autenticación, permisos y equipos
Hay dos métodos para autenticarse en GitHub. El método que use dependerá de cómo se configure la cuenta de empresa.
Si la cuenta empresarial usa Enterprise Managed Users, iniciará sesión en GitHub a través del proveedor de identidad (por ejemplo, Entra ID) y usará una cuenta aprovisionada vinculada a la cuenta empresarial.
De lo contrario, usarás una cuenta personal de GitHub. Esa cuenta será invitada a unirse a la cuenta de empresa y a todas las organizaciones en las que participe. Si la cuenta empresarial está configurada con restricciones de acceso de SAML adicionales, su cuenta personal se vinculará a su IdP. Se le pedirá que se autentique con el IdP cuando necesite acceder a los recursos dentro de la cuenta de empresa.
En una empresa de GitHub, los repositorios pueden ser públicos, privados o internos. Los repositorios privados solo son visibles para personas y equipos con acceso explícito, y los repositorios internos son visibles para todos los miembros de su empresa, pero no para personas ajenas a la empresa. Los repositorios internos son útiles cuando varias organizaciones de la misma empresa necesitan detectar y reutilizar código. Si la empresa usa Enterprise Managed Users, las cuentas de usuario no pueden crear repositorios públicos ni otro contenido público.
Utilizar GitHub
Para seguir trabajando en los repositorios mediante Git, deberá realizar algunos cambios.
- Actualice las direcciones URL remotas para que apunten a GitHub. Consulta Administrar repositorios remotos.
- Actualice cómo se autentica.
- Para usar la autenticación HTTPS, deberá crear un personal access token. Consulta Administración de tokens de acceso personal.
- Para usar la autenticación SSH, deberá crear o agregar una clave SSH existente a GitHub. Consulta Conectar a GitHub con SSH.
- Si su empresa u organización usa el inicio de sesión único (SSO) de SAML, debe autorizar los datos personal access token o la clave SSH para poder acceder a los recursos.
Flujo de solicitud de incorporación de cambios
Con el código base ahora hospedado en GitHub, propondrá cambios mediante "pull requests" (solicitudes de incorporación de cambios) creadas en sus repositorios de GitHub.
Si la empresa ha integrado Azure Boards y Pipelines, ambas funcionarán con GitHub. Puede seguir haciendo referencia a elementos de trabajo en los mensajes de confirmación y las solicitudes de incorporación de cambios. Por ejemplo: Fix login bug (AB#1234).
Puede seguir viendo y administrando los elementos de trabajo en Azure Boards. También puede vincular ramas, confirmaciones y solicitudes de incorporación de cambios a elementos de trabajo desde Azure. Consulte Vinculación de confirmaciones, solicitudes de incorporación de cambios, ramas e incidencias de GitHub a elementos de trabajo en Azure Boards en Microsoft Learn.
Protecciones de rama
Los usuarios con acceso de administrador a un repositorio pueden configurar reglas de protección de rama en GitHub. Son similares a las directivas de rama en Azure DevOps y establecen reglas como un número mínimo de revisores aprobados, comprobaciones de estado correctas y requerir confirmaciones firmadas.
GitHub también admite la asignación automática de revisores en función de los patrones file, folder y glob en el archivo CODEOWNERS de un repositorio. Consulta Acerca de los propietarios de código.
Paquetes y artefactos
En Azure DevOps, es posible que haya usado Azure Artifacts para publicar y consumir paquetes (por ejemplo, paquetes NuGet, paquetes npm o paquetes maven) y para almacenar artefactos de compilación generados por Azure Pipelines.
En GitHub, los paquetes normalmente se publican en GitHub Packages y se asocian a un repositorio u organización. En función de cómo la empresa haya completado la migración, puede seguir publicando paquetes en Azure Artifacts, mover paquetes a GitHub Packages, o usar una combinación de ambos.
Si ya no puede restaurar las dependencias después de la migración, compruebe la configuración del origen del paquete. Por ejemplo, puede que tenga que actualizar una dirección URL del Registro o credenciales en archivos como nuget.config, .npmrc, settings.xmlo en la configuración de la canalización.
Para más información, consulta Introducción a los paquetes de GitHub.
GitHub Copilot
Hospedar sus repositorios en GitHub libera todo el potencial de Copilot. Su base de código proporciona a Copilot todo el contexto que necesita para responder preguntas en Chat de Copiloto, revisar y hacer sugerencias en las solicitudes de incorporación de cambios e incluso realizar cambios automáticamente con Agente de codificación de Copilot.
Consulta Inicio rápido para GitHub Copilot.