En el examen AZ-400, la sección de control de código fuente pregunta cómo los equipos dividen, fusionan y protegen el código. Abarca criterios de elección de estrategia de ramificación, configuración de políticas de Pull Request y diferencias entre plataformas de repositorios. Una estrategia incorrecta puede desencadenar una crisis en el despliegue; una política de PR ausente puede dejar pasar una vulnerabilidad directo a main. El control de código fuente es la base de todo pipeline DevOps.
Estrategias de Ramificación: El Plano de Cómo Colaboran los Equipos
Imagina a dos personas intentando tomar prestado el mismo libro de biblioteca al mismo tiempo — sin un sistema claro de préstamo, el conflicto es inevitable. El código fuente enfrenta el mismo problema: cuando varios desarrolladores modifican el mismo archivo simultáneamente, los conflictos de fusión se acumulan. Una estrategia de ramificación es el sistema acordado por el equipo para minimizar esas colisiones e integrar los cambios de forma segura.
usa cinco tipos de ramas: , , , y . Es adecuado para equipos con ciclos de lanzamiento definidos que mantienen varias versiones activas simultáneamente, como aplicaciones móviles que soportan distintas versiones de SO. La contrapartida es la complejidad: muchas ramas de larga vida dificultan la automatización de CI/CD.
usa únicamente y ramas de corta duración. El desarrollador abre un Pull Request y fusiona de vuelta en main tras la revisión. Rápido y simple, ideal para equipos pequeños con despliegues web frecuentes.
hace que todos los desarrolladores hagan commits directamente en varias veces al día. Las ramas son tan efímeras que los conflictos de fusión prácticamente no se acumulan. El habilitador clave son los Feature Flags: funcionalidades incompletas se envían ocultas detrás de un interruptor. En el examen AZ-400, 'ciclo de lanzamiento rápido' o 'integración profunda con CI' apunta a TBD.
es la estrategia interna de Microsoft — los equipos crean ramas desde main, despliegan desde allí y aplican hotfixes mediante cherry-pick. El propio Azure DevOps se desarrolla así.
| Estrategia | Cantidad de ramas | Cadencia de lanzamiento | Tamaño del equipo | |------------|------------------|------------------------|-------------------| | GitFlow | Alta | Periódica | Mediano–Grande | | GitHub Flow | Baja | Continua | Pequeño–Mediano | | Trunk-Based | Mínima | Integración continua | Cualquiera | | Release Flow | Media | Por sprint | Grande |
Protección de Ramas: Mantener main Segura ante Errores Accidentales
Una caja fuerte bancaria no depende de un solo candado: combina una cerradura de combinación, un escáner biométrico y un guardia de seguridad. El branch merece la misma defensa en capas. Si cualquiera puede hacer push directo a main, un error tipográfico o un commit malicioso puede llegar a producción de inmediato. La protección de ramas impone condiciones que deben cumplirse antes de que cualquier PR pueda fusionarse.
En Azure Repos, controla qué condiciones deben darse antes de que un PR se fusione en una rama protegida.
: se requiere un número mínimo de aprobaciones : un pipeline debe pasar antes de permitir la fusión : obliga a vincular el trabajo a Azure Boards : restringe a Squash, Rebase o Merge commit Desactivar para evitar la autoaprobación
Las de GitHub ofrecen controles equivalentes.
: aprobación de revisores obligatoria : los resultados de CI deben estar en verde : limita quién puede hacer push directo : solo se aceptan commits firmados con GPG
Ambas plataformas bloquean el force-push y la eliminación de branches protegidos por defecto.
Políticas de Pull Request y CODEOWNERS
En un rodaje cinematográfico, el director no es la única autoridad. El director de fotografía es responsable de cada encuadre, el diseñador de sonido de cada detalle auditivo. Las revisiones de código funcionan igual: nadie puede revisar significativamente cada archivo de un repositorio grande. es el mecanismo que declara quién es responsable de qué parte del código.
Coloca un archivo en (GitHub) o en la raíz del repositorio (Azure DevOps) y asigna rutas a sus propietarios.
Cuando un PR toca una ruta listada, los propietarios designados se añaden automáticamente como revisores. Activar en la Branch Protection Rule impide la fusión sin su aprobación.
Azure Repos también admite basados en rutas, configurados directamente en la Branch Policy. Ambas plataformas permiten conectar resultados de CI externos, análisis de seguridad y puertas de calidad de código a los requisitos de aprobación del PR mediante status checks.
La estrategia de fusión también incide en la limpieza del historial.
: preserva todo el historial del branch feature; crea un commit de fusión en main : comprime todos los commits de la feature en uno solo en main; elegir cuando el historial del PR es demasiado ruidoso : reaplica los commits de la feature sobre main, produciendo un historial lineal
En el examen AZ-400, los escenarios con 'historial de PR desordenado' o 'mantener el historial de main limpio' apuntan al Squash merge.
Estructura del Repositorio y Gestión de Archivos Git
Un centro comercial reúne supermercado, ropa y electrónica bajo el mismo techo: conveniente pero complejo de gestionar. Las tiendas especializadas independientes son más sencillas de operar pero requieren desplazarse entre ellas. La estructura del repositorio de código presenta el mismo equilibrio entre comodidad y autonomía.
Un aloja todos los servicios y bibliotecas en un único repositorio. Compartir código es inmediato y los builds entre servicios se coordinan en una sola ejecución de pipeline. La contrapartida es el crecimiento del tamaño del repositorio y los tiempos de CI más largos. Git LFS, Scalar y sparse-checkout son esenciales para mantener operable un monorepo grande.
El mantiene cada servicio o equipo en su propio repositorio. La autonomía del equipo es alta y el control de acceso está naturalmente aislado. El punto de dolor es la actualización de bibliotecas compartidas: cada repositorio debe parchearse y versionarse de forma independiente.
lista archivos que Git no debe rastrear: salidas de compilación, carpetas de dependencias como y archivos de entorno local como . define el tratamiento por tipo de archivo: normalización de saltos de línea () y enrutamiento de punteros Git LFS (). Si una pregunta del examen AZ-400 menciona 'activos binarios que aumentan el tamaño del repositorio', la respuesta involucra y Git LFS.
Azure Repos vs GitHub: Elegir Según el Ecosistema
Elegir entre iOS y Android suele depender del ecosistema: iOS se integra sin fricciones con otros dispositivos Apple, mientras que Android ofrece más variedad de hardware. La elección entre Azure Repos y GitHub sigue la misma lógica: depende del ecosistema en el que ya estás trabajando.
| Aspecto | Azure Repos | GitHub | |---------|-------------|--------| | CI/CD nativo | Azure Pipelines | GitHub Actions | | Gestión de identidad | Azure AD, políticas de organización | GitHub Org, SAML SSO | | On-premises | Azure DevOps Server | GitHub Enterprise Server | | Seguimiento de trabajo | Azure Boards | GitHub Issues/Projects |
Azure Repos es la opción natural para equipos que ya usan Azure Pipelines, Azure Boards y Azure Artifacts como plataforma unificada. Los puntos fuertes de GitHub son la comunidad open-source, GitHub Copilot y la amplitud del GitHub Actions Marketplace. En el examen AZ-400, los escenarios de 'mantener el entorno Azure DevOps existente' favorecen Azure Repos, mientras que los de 'contribución open-source' o 'aprovechar el ecosistema de GitHub Actions' favorecen GitHub.
!Azure Repos vs GitHub
Resumen para el Examen
"CI rápido, rama única, commits de corta duración" -- Trunk-Based Development "Múltiples versiones de lanzamiento, entrega programada" -- GitFlow "Forzar el pipeline de build a pasar antes de fusionar PR" -- Build Validation (Branch Policy) "Asignar revisores automáticamente cuando cambian rutas específicas" -- CODEOWNERS "Comprimir historial de PR en un solo commit en main" -- Squash merge "Bloquear push directo a main en Azure Repos" -- Branch Policy número mínimo de revisores "Impedir force push en GitHub" -- Branch Protection Rule "Gestionar archivos binarios grandes en un monorepo" -- Git LFS + .gitattributes "Excluir artefactos de build y archivos de entorno del seguimiento" -- .gitignore "Repositorio integrado en el ecosistema Azure" -- Azure Repos "Contribución open-source, GitHub Actions Marketplace" -- GitHub "Forzar commits firmados con GPG en ramas protegidas" -- Require signed commits
GitFlow = lanzamientos periódicos con múltiples versiones, Trunk-Based = integración continua en rama única, CODEOWNERS = asignación automática de revisores por ruta.