Microsoft AZ-400: Control de código fuente y gestión de repositorios — Guía de estudio

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Forma parte de la Microsoft DevOps Engineer Expert AZ-400 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Descripción general

Las prácticas modernas de DevOps se basan en un control de código fuente predecible y colaborativo y una gestión de repositorios disciplinada. Azure Repos y GitHub proporcionan capacidades complementarias para el control de versiones, la aplicación de políticas, la colaboración y la seguridad. El dominio de las estrategias de ramificación, los flujos de trabajo de pull requests, los permisos, los hooks, el manejo de archivos grandes, los patrones de migración, el escaneo de seguridad y el versionado es esencial para pipelines de entrega resilientes y para la auditabilidad. El objetivo no es solo almacenar código, sino crear un sistema de controles automatizado y exigible que escale el rendimiento del equipo sin sacrificar la calidad.

Fundamentos del control de código fuente en Azure Repos y GitHub

Azure Repos es compatible con Git y Team Foundation Version Control (TFVC). Git es distribuido, permite commits locales, una fácil ramificación y flujos de trabajo descentralizados. TFVC es centralizado con versionado del lado del servidor, check-outs bloqueados (opcional) y es muy adecuado para soluciones heredadas con activos binarios muy grandes o equipos formados en flujos de trabajo centralizados. El nuevo desarrollo debería usar Git por defecto; TFVC sigue siendo viable cuando el control de cambios incremental y los permisos centrales son primordiales y el costo de migración es prohibitivo.

Elige una estrategia de ramificación de forma deliberada:

• El desarrollo basado en el tronco (trunk-based development) favorece una única rama principal (main) de larga duración con ramas de funcionalidad (feature branches) de muy corta duración e integración continua. Esto acelera el flujo, reduce la deuda de merges y es ideal para equipos de alta cadencia con una fuerte automatización de pruebas.
• GitFlow utiliza ramas de larga duración develop y main (release), con ramas de feature, release y hotfix. Se adapta a productos con trenes de lanzamiento formales y necesidades de backporting, pero añade una sobrecarga de coordinación.
• GitHub Flow es un modelo simplificado con una única rama main, ramas temáticas de corta duración, despliegue continuo y lanzamientos frecuentes. Es eficaz para servicios que se entregan continuamente.

Monorepo versus multi-repo es principalmente una elección organizativa y de herramientas:

• Un monorepo consolida muchos componentes en un solo repositorio, facilitando cambios atómicos entre servicios, refactorización unificada y herramientas compartidas. Puede sobrecargar las operaciones de Git a medida que crece el historial. Las técnicas de mitigación incluyen sparse checkout, partial clone y filtros de ruta de CI para acotar las compilaciones y las pruebas.
• Un multi-repo aísla la propiedad, el historial y los límites de permisos, facilitando el versionado y la retención independientes. Puede aumentar la coordinación entre repositorios y la deriva de dependencias; los submódulos o los gestores de dependencias y la orquestación de lanzamientos son críticos.

La propiedad y el enrutamiento de cambios se benefician de las declaraciones de propiedad del código. El archivo CODEOWNERS de GitHub asigna rutas a revisores obligatorios automáticamente. En Azure Repos, utiliza revisores requeridos basados en rutas en las políticas de rama (y CODEOWNERS donde esté habilitado) para dirigir las revisiones a los equipos de componentes. Complementa la propiedad con convenciones de nomenclatura de ramas, mensajes de commit claros (p. ej., Conventional Commits) y plantillas de repositorio para mayor consistencia.

Gobernanza: Políticas, permisos y pull requests

Las políticas de rama en Azure Repos codifican las puertas de calidad (quality gates):

• Revisores requeridos exigen un número mínimo de revisores y pueden incluir individuos/grupos específicos o auto-revisores basados en rutas. Exige la resolución de comentarios para asegurar que el feedback sustantivo se aborde antes del merge.
• La validación de compilación requiere que uno o más pipelines de CI pasen antes del merge. Usa filtros de ruta para evitar compilaciones innecesarias y establece el desencadenamiento automático en nuevas actualizaciones. Integra comprobaciones externas a través de políticas de estado para escaneos de seguridad o pruebas de rendimiento.
• Las estrategias de merge pueden ser restringidas: Merge (no fast-forward) registra el historial del merge; Squash condensa los cambios en un único commit, manteniendo el historial lineal; Rebase y fast-forward reescribe la rama temática sobre main para una línea de historial recta; Rebase y merge reproduce los commits y preserva los commits separados sin un commit de merge. Alinea la estrategia con las necesidades de auditoría y las herramientas posteriores.
• Las comprobaciones adicionales incluyen elementos de trabajo vinculados requeridos, un mínimo de votos exitosos y el bloqueo si hay comentarios activos o revisores pendientes.

Los pull requests orquestan la conversación de integración:

• Los PRs en borrador (Draft PRs) señalan trabajo en progreso y bloquean su finalización hasta que se marcan como listos. Fomenta el feedback temprano sin activar las políticas prematuramente.
• La finalización automática (auto-complete) realiza el merge automáticamente una vez que todas las políticas pasan, reduciendo la latencia de coordinación y aumentando el flujo.
• La opción de omitir políticas (Bypass policies) existe para situaciones de emergencia o cuentas de automatización. Restringe esto con el permiso “Omitir políticas al completar pull requests” y audítalo a través de aprobaciones y gestión de cambios.
• Las plantillas de PR estandarizan el contexto: evidencia de pruebas, notas de riesgo, pasos de despliegue y plan de reversión (roll-back). En Azure Repos, coloca pull_request_template.md en la raíz del repositorio o en .azuredevops/. Proporciona listas de verificación para seguridad, rendimiento y documentación.

Los permisos y las ramas protegidas son tu última línea de defensa:

• Usa los grupos RBAC de Azure DevOps (Project Administrators, Contributors, Readers) y permisos de repositorio detallados (Crear rama, Crear etiqueta, Contribuir, Force push, Administrar permisos, Omitir políticas). Prefiere permitir/denegar en grupos en lugar de en individuos.
• Protege las ramas main y de release denegando el Force push y la eliminación, limitando la contribución solo a merges de PR y habilitando políticas de rama que requieran compilaciones y revisiones. Considera la opción de “Bloquear” (Lock) para congelar temporalmente los cambios.
• Usa permisos a nivel de rama para restringir quién puede crear o completar PRs contra ramas sensibles, y separa las responsabilidades entre desarrolladores y gestores de lanzamientos (release managers).

Automatización, hooks, archivos grandes y seguridad

Los hooks de Git refuerzan la calidad en los extremos:

• Los hooks de pre-commit aplican localmente el linting, el formato, la comprobación de secretos y las pruebas unitarias antes de que un desarrollador registre una confirmación (commit). Mantenlos rápidos y deterministas.
• Los hooks de pre-push bloquean el envío de código que no supera las pruebas de integración o las comprobaciones de políticas. Proporciona scripts de hooks para todo el equipo a través de herramientas (p. ej., Husky para JavaScript) y documenta la participación opcional (opt-in).
• Los hooks del lado del servidor en los servicios gestionados difieren: GitHub admite webhooks de servidor y comprobaciones de estado requeridas; Azure DevOps Services no permite hooks personalizados del lado del servidor, pero admite políticas de rama, validaciones de compilación, hooks de servicio y comprobaciones de estado de sistemas externos. En Azure DevOps Server (on-prem), los hooks de servidor son posibles.

El almacenamiento de archivos grandes (Git LFS) guarda los binarios grandes fuera de la base de datos de objetos de Git, manteniendo el rendimiento del repositorio:

• Rastrea patrones con git lfs track “*.psd” o tipos de archivos binarios específicos. Confirma el archivo .gitattributes para que todos los colaboradores apliquen LFS de manera consistente.
• Migra el historial ejecutando git lfs migrate import con filtros de ruta para reescribir binarios grandes a punteros. Coordina con el equipo y pausa los pushes; haz force-push con cautela y actualiza los clones.
• Gestiona el ancho de banda evitando el smudging innecesario. Usa GIT_LFS_SKIP_SMUDGE=1 y ejecuta git lfs fetch/pull selectivamente. Almacena en caché LFS en la CI y considera usar repositorios de artefactos para binarios que no necesitan vivir en Git.

La garantía de seguridad debe ser shift-left y basada en políticas:

• GitHub Advanced Security (GHAS) aporta escaneo de secretos (incluida la protección de push), escaneo de código con CodeQL y revisión de dependencias para detectar credenciales expuestas, vulnerabilidades de código y riesgos en la cadena de suministro. Aplícalo como comprobaciones requeridas en los PR. Para Azure Repos, usa Advanced Security for Azure DevOps para lograr un escaneo de secretos, SAST a través de CodeQL y análisis de dependencias similares.
• El escaneo de secretos debe configurarse para bloquear pushes con secretos de alta confianza y alertar a los responsables de seguridad. Admite detectores personalizados para patrones específicos de la organización.
• El escaneo de código de CodeQL debe ejecutarse en los triggers de pull_request y de programación (schedule), subiendo los resultados SARIF como comprobaciones de estado. Ajusta los paquetes de consultas (query packs) para reducir el ruido y asegurar la cobertura en las rutas críticas.
• La revisión de dependencias expone los cambios de versión y las advertencias conocidas durante la revisión de PR; úsala para los SLA de remediación y la gobernanza de licencias.

Migración, Versionado y Gestión de Versiones

Migrar de TFVC a Git requiere una estrategia y herramientas alineadas con la tolerancia al riesgo:

• Para una migración de alta fidelidad con historial profundo y vinculación de elementos de trabajo, use git-tfs para clonar las rutas de TFVC a Git, preservando los conjuntos de cambios (changesets) y mapeando usuarios. Particione por aplicación o rama para mantener los repositorios de Git manejables. Limpie los binarios grandes con LFS durante o después de la migración.
• Para una migración ligera del estado actual, use la herramienta de importación de Azure DevOps para inicializar un nuevo repositorio de Git desde TFVC (u otro host de Git), limitando opcionalmente el historial. Esto reduce la duración y el riesgo, pero sacrifica la granularidad histórica profunda.
• Preserve la trazabilidad migrando etiquetas/labels, mapeando las ramas de TFVC a ramas de Git y manteniendo un espejo de solo lectura de TFVC para auditoría. Valide con un piloto, congele el código fuente durante la transición y ejecute una matriz de verificación (compilaciones, pruebas y despliegue).

Adopte el versionado semántico para mayor claridad y automatización:

• Use SemVer 2.0.0: MAJOR.MINOR.PATCH con metadatos opcionales de prelanzamiento (ej., -rc.1) y de compilación (+build.45). Etiquete las versiones con etiquetas anotadas (git tag -a v1.4.2 -m “Release 1.4.2”) y firme las etiquetas para auditoría.
• Automatice los incrementos de versión en CI/CD:
  • Impulse la versión desde los commits con Conventional Commits y una herramienta de lanzamiento (ej., GitVersion o semantic-release) para calcular la siguiente versión basándose en los tipos y ámbitos de los commits.
  • Actualice los números de compilación y las versiones de los paquetes automáticamente; haga fallar la compilación si se producen desviaciones de versión o conflictos de etiquetas.
• Alinee el versionado con la estrategia de ramificación:
  • Basado en troncal (Trunk-based): la rama main siempre está en estado publicable; cree etiquetas de lanzamiento desde main; use ramas de lanzamiento de corta duración solo para estabilización.
  • GitFlow: las ramas release/* llevan una versión menor congelada; las ramas hotfix/* se crean desde main para parches urgentes; reintegre mediante merge tanto a develop como a main y etiquete al completar el merge.
  • GitHub Flow: etiquete main en el despliegue; use etiquetas de prelanzamiento para despliegues canary.

Integre la automatización de lanzamientos con las políticas del repositorio: requiera compilaciones exitosas (green builds) con pipelines de lanzamiento, bloquee los merges sin changelogs actualizados generados a partir de los commits y requiera commits/etiquetas firmados en entornos regulados.

Escenario de Problema Práctico

Starbucks debe consolidar múltiples aplicaciones heredadas (legacy) gestionadas en TFVC en Azure Repos Git, al tiempo que establece una gobernanza uniforme, escaneo de seguridad y flujos de trabajo escalables tanto para servicios como para aplicaciones móviles.

1. Elegir la topología de repositorios y la estrategia de ramificación

• Acción: Adoptar el desarrollo basado en troncal (trunk-based) con un monorepo para bibliotecas compartidas y unos pocos repositorios de servicios enfocados para servicios que se lanzan de forma independiente. Habilitar el sparse checkout para el monorepo en los scripts de incorporación de desarrolladores.
• Por qué: El desarrollo basado en troncal reduce la deuda de merges y acelera la integración; el monorepo centraliza el código compartido y permite refactorizaciones atómicas, mientras que el sparse checkout evita la sobrecarga del historial completo y del árbol de trabajo para los equipos que solo modifican subconjuntos.

2. Migrar proyectos de TFVC a Git con preservación del historial donde añade valor

• Acción: Usar git-tfs para migrar las bases de código principales web y móvil con historial completo, mapeando las rutas de activos grandes a Git LFS durante la migración. Para utilidades pequeñas, usar la herramienta de importación de Azure DevOps para traer solo el estado actual.
• Por qué: git-tfs preserva la trazabilidad crítica para las aplicaciones insignia; el uso selectivo de la herramienta de importación acelera las migraciones de bajo riesgo y reduce la duración del proyecto.

3. Establecer ramas protegidas y políticas de rama

• Acción: Proteger main y release/* con la denegación de Force push/Delete; requerir dos revisores, resolver todos los comentarios, vincular un elemento de trabajo y pasar la validación de compilación con filtros de ruta. Restringir los merges a Squash para los repositorios de servicios y a Rebase y fast-forward para el monorepo para mantener un historial lineal. Deshabilitar “Omitir políticas” (Bypass policies) excepto para un pequeño grupo de ingeniería de lanzamientos.
• Por qué: La política como código (Policy-as-code) refuerza las barreras de calidad y la auditabilidad. Las estrategias de merge reflejan las preferencias del equipo: Squash simplifica las operaciones de revert y cherry-pick para los servicios; el historial lineal en el monorepo acelera las operaciones de blame y bisect.

4. Estandarizar la práctica de los pull requests

• Acción: Añadir

undefined

en .azuredevops/ con secciones para riesgo, evidencia de pruebas, impacto en el rendimiento y plan de retroceso (rollback). Fomentar los Draft PRs (pull requests en borrador) desde el principio; habilitar la finalización automática (Auto-complete) en todos los PRs. Configurar revisores requeridos basados en rutas para emular la propiedad del código, y añadir

undefined

para los repositorios alojados en GitHub.

• Por qué: Las plantillas elevan el nivel mínimo de calidad de la revisión; los Draft PRs promueven la colaboración temprana; la finalización automática elimina el tiempo de inactividad; el enrutamiento por propiedad asigna los revisores correctos a los diffs correctos.

5. Implementar hooks y puertas de CI

• Acción: Distribuir hooks de pre-commit/pre-push a través de las herramientas del repositorio para forzar el linting, la comprobación de secretos y las pruebas unitarias; mantener una ejecución rápida. Usar la validación de compilación de Azure Pipelines como el mecanismo canónico de aplicación y añadir comprobaciones de estado de los escáneres de seguridad. Evitar hooks personalizados del lado del servidor; usar service hooks para notificar a sistemas externos.
• Por qué: Los hooks locales detectan problemas de forma temprana sin bloquear la colaboración; la aplicación del lado del servidor en Azure DevOps se logra mejor con políticas de rama y comprobaciones de estado para mayor fiabilidad y auditoría.

6. Gestionar activos grandes con Git LFS

• Acción: Rastrear patrones de binarios (imágenes, activos de diseño, medios de prueba) con

undefined

; migrar binarios heredados con

undefined

. Configurar el CI para establecer

undefined

y hacer fetch selectivamente para reducir el ancho de banda; cachear los artefactos de LFS en los agentes de compilación.

• Por qué: Mantiene los repositorios rápidos y evita el uso excesivo de la red, al tiempo que se mantienen compilaciones reproducibles.

7. Integrar Advanced Security

• Acción: Habilitar GitHub Advanced Security en los repositorios de GitHub y Advanced Security for Azure DevOps en Azure Repos. Activar el escaneo de secretos con protección en el push, ejecutar CodeQL en los PRs y de forma nocturna, y habilitar las comprobaciones de revisión de dependencias. Bloquear la finalización de PRs ante hallazgos de alta severidad.
• Por qué: Desplaza la seguridad a la izquierda (Shift-left), previniendo que fugas de credenciales y patrones explotables entren en la rama main, con información procesable durante la revisión.

8. Automatizar el versionado semántico y el etiquetado

• Acción: Usar GitVersion en Azure Pipelines para calcular SemVer a partir del historial de ramas y commits; firmar y subir etiquetas anotadas en los pipelines de lanzamiento; generar notas de la versión a partir de Conventional Commits. Usar ramas release/* solo para estabilización; crear hotfixes desde la rama main etiquetada.
• Por qué: Las versiones deterministas y automatizadas mejoran la trazabilidad y la reproducibilidad del despliegue, y las etiquetas firmadas apoyan el cumplimiento normativo (compliance).

Esta secuencia reduce el riesgo de la migración, impone una calidad y seguridad consistentes, y agiliza la entrega, alineando precisamente la gestión de repositorios con operaciones DevOps escalables.

Todos los dominios · Pipelines de CI →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Microsoft →