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 proyectos team, 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 está estructurado 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. Tratar a las organizaciones en GitHub como equivalente de proyectos de equipo no es recomendable.
Aunque puede que inicialmente encuentre que 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 enormemente la navegación por sus repositorios.
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ás sesión en GitHub a través del proveedor de identidades (por ejemplo, Entra ID) y utilizarás una cuenta provisionada asociada a la cuenta empresarial.
De lo contrario, usarás una cuenta personalGitHub. 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 en 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 su empresa usa Enterprise Managed Users, las cuentas de usuario no pueden crear repositorios públicos u 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 Conexión a GitHub con SSH.
- Si su empresa u organización utiliza SAML de inicio de sesión único (SSO), debe autorizar su personal access token o clave SSH antes de que pueda 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 creados en los repositorios de GitHub.
Si tu 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 Link GitHub confirmaciones, solicitudes de incorporación de cambios, ramas y problemas para los 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 branch en Azure DevOps y establecen reglas como un número mínimo de revisores que aprueben, comprobaciones de estado exitosas y la necesidad de 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 [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).
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 o 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 los repositorios en GitHub desbloquea toda la potencia de Copilot. El código base proporciona a Copilot todo el contexto que necesita para responder a preguntas en Chat de Copiloto, revisar y realizar sugerencias en las solicitudes de incorporación de cambios e incluso realizar cambios en su lugar con agente en la nube de Copilot.
Consulta Inicio rápido para GitHub Copilot.