Repositorios: estructura y actualización. Generación de código y documentación. Metodologías de desarrollo. Pruebas. Programas para control de versiones. Plataformas de desarrollo colaborativo de software.

Índice

1. Por qué este tema se contesta con comandos y nombres propios
2. El control de versiones: qué problema resuelve
3. Git por dentro
4. Estrategias de ramas y convenios
5. Plataformas de desarrollo colaborativo
6. Estructura y actualización de repositorios
7. Generación de código y documentación
8. Metodologías de desarrollo
9. Pruebas
10. Calidad del código y deuda técnica
11. Cuadros para memorizar
12. Lo que ya ha preguntado el tribunal

1. Por qué este tema se contesta con comandos y nombres propios

Este tema tiene la firma más reconocible de todo el bloque: de las 72 preguntas del corpus que lo tocan, la mayoría se contestan sabiendo un comando, un nombre de fichero o un nombre de producto. No hay teoría que sustituya a haber visto la orden escrita.

La prueba está en lo que ha caído literalmente:

• Qué hace exactamente git fetch —y su respuesta correcta menciona incluso el fichero .git/FETCH_HEAD—.
• Cuáles son los cuatro tipos de datos del modelo de Git, con tres listas verosímiles como trampa.
• Dónde van los ficheros de flujos de trabajo de la plataforma y con qué extensión.
• Cómo se llama la operación que lleva un commit suelto a otra rama, con tres nombres de fruta inventados alrededor.
• Qué fichero explica el propósito del proyecto y cómo arrancarlo.
• Cuál de estas tres ternas de productos sirve para el control de versiones y cuál mezcla herramientas de pruebas.
• Qué herramienta formatea el código, frente a las que lo analizan.
• Y, en la parte de metodología, qué rol pertenece al Equipo de Scrum y en qué reunión se plantea una mejora del proceso.

Así que el tema se estudia con tres listas delante: los comandos de Git, los ficheros del repositorio y los nombres de producto, sabiendo además para qué sirve cada uno, porque la trampa favorita del tribunal es colocar un producto real en la categoría equivocada —Mercurial entre las herramientas de calidad, Selenium entre los sistemas de control de versiones—.

2. El control de versiones: qué problema resuelve

2.1. El problema

Sin control de versiones, un equipo que toca el mismo código acaba en el mismo sitio: carpetas llamadas proyecto_final_v2_bueno_ESTE, cambios que se pisan al copiar, imposibilidad de saber quién tocó qué y cuándo, y ninguna forma de volver a una versión que funcionaba. Un sistema de control de versiones resuelve las cuatro cosas a la vez:

Necesidad	Qué aporta el sistema
Histórico	Cada cambio queda registrado con su autor, su fecha y su motivo.
Reversión	Se puede volver a cualquier estado anterior del proyecto.
Trabajo en paralelo	Varias personas trabajan a la vez sobre el mismo código sin pisarse.
Trazabilidad	Se sabe qué cambio introdujo qué comportamiento, y por qué se hizo.

Y hay una quinta razón que hoy pesa tanto como las anteriores: el repositorio se ha convertido en la fuente de la verdad de todo el proyecto. No solo del código: también de la configuración de la infraestructura, de la documentación, de las pruebas y de las tuberías de construcción. De ahí la expresión «todo como código».

2.2. Centralizado frente a distribuido

Es la clasificación de partida y se pregunta por sus consecuencias prácticas, no por la definición:

	Centralizado	Distribuido
Dónde está el histórico	Solo en el servidor. El puesto tiene una copia de trabajo.	En cada clon: todo el mundo tiene el historial completo.
Sin conexión	Casi nada se puede hacer: confirmar exige servidor.	Se confirma, se crean ramas y se consulta el histórico en local.
Punto único de fallo	Sí: si se pierde el servidor y no hay respaldo, se pierde el histórico.	No: cualquier clon completo sirve para reconstruirlo.
Ramas	Caras y poco usadas en la práctica.	Baratas e inmediatas: es la operación central del flujo de trabajo.
Ejemplos	CVS, Apache Subversion, Team Foundation Version Control.	Git, Mercurial, Bazaar.

2.3. Los programas de control de versiones que hay que reconocer

El enunciado oficial del tema habla literalmente de programas para control de versiones, y esa es exactamente la forma en que se pregunta: por el nombre del producto. Conviene separar dos cosas que el examen mezcla a propósito —el programa que lleva el control de versiones y la plataforma que aloja los repositorios y añade colaboración— porque son capas distintas.

🚨 La pregunta oficial es de reconocimiento puro: «¿cuál de las siguientes opciones se utilizan para el control de versiones?», con cuatro ternas. La respuesta correcta era GitLab, GitHub y Apache Subversion, y las tres opciones falsas colaban Selenium o Cucumber, que son herramientas de pruebas, no de control de versiones. Conviene tener el cuadro:

Producto	Qué es
Git	El sistema distribuido dominante. Lo creó Linus Torvalds en 2005 para el núcleo de Linux.
Apache Subversion (SVN)	El sistema centralizado más extendido, todavía muy presente en la Administración.
CVS	El centralizado clásico, anterior al anterior. Prácticamente en desuso.
Mercurial	Sistema distribuido, competidor histórico de Git. ⚠️ El tribunal lo coló entre herramientas de CALIDAD del código, donde no pinta nada.
GitHub, GitLab, Bitbucket	⚠️ NO son sistemas de control de versiones: son plataformas que alojan repositorios de Git y añaden colaboración. La pregunta oficial las aceptó dentro de la terna, pero conviene saber la diferencia.
Selenium, Cucumber	Herramientas de pruebas: automatización de navegador y desarrollo guiado por comportamiento. Son los distractores de esta pregunta.

3. Git por dentro

Aquí está el grueso de las preguntas del tema, así que conviene entenderlo de verdad y no memorizar comandos sueltos.

3.1. Las tres zonas y los cuatro estados de un fichero

Todo Git se explica con tres zonas y el viaje de un fichero entre ellas:

Zona	Qué es	Cómo se llega
Directorio de trabajo	Los ficheros tal como están en el disco.	Editando.
Área de preparación (el index)	La antesala: lo que entrará en la próxima confirmación.	git add
Repositorio local	El historial de confirmaciones, dentro del directorio .git.	git commit

Y los estados en que puede estar un fichero:

• Sin seguimiento (untracked): Git no lo conoce todavía.
• Modificado (modified): ha cambiado respecto de la última confirmación, pero no se ha preparado.
• 🚨 Preparado (staged): los cambios están marcados para incluirse en la próxima confirmación. Esa es la definición literal que preguntó el tribunal, y sus distractores decían que estaba subido al remoto —que es pushed— o que estaba modificado sin confirmar —que es el estado anterior—.
• Confirmado (committed): guardado de forma segura en la base de datos local.

La existencia del área de preparación es lo que distingue a Git de casi todos los demás sistemas, y su utilidad práctica es poder confirmar solo una parte de lo que se ha tocado, agrupando los cambios por sentido y no por el momento en que se escribieron.

3.2. 🚨 El modelo de datos: los cuatro tipos

Esta es una pregunta oficial de 2026, y de las que no se razonan. Los cuatro tipos de datos que componen el modelo de datos de Git son:

Tipo	Qué guarda
Objects (objetos)	El contenido en sí: los cuatro objetos que veremos enseguida —blob, tree, commit y tag—, cada uno identificado por el resumen criptográfico de su contenido.
References (referencias)	Punteros con nombre a un objeto: las ramas, las etiquetas y HEAD. Son lo que hace legible el grafo.
Index (índice)	El área de preparación: la foto de lo que entrará en la próxima confirmación.
Reflogs (registros de referencias)	El histórico de por dónde han pasado las referencias. Es la red de seguridad: permite recuperar un commit que parecía perdido tras un reinicio brusco.

⚠️ La trampa de esa pregunta era ofrecer «Commits, Trees, Blobs y Tags», que es una lista correcta… pero de los OBJETOS, no del modelo de datos completo. Es decir: los cuatro objetos son un subconjunto del primer tipo. Quien confunda los dos niveles falla.

3.3. Los cuatro objetos

Objeto	Qué representa
Blob	El contenido de un fichero. No guarda el nombre ni los permisos: solo los bytes.
Tree (árbol)	Un directorio: la lista de nombres con el blob o el árbol al que apunta cada uno, y sus permisos.
Commit	Una instantánea: apunta a un árbol raíz, a su commit o commits padres, y lleva autor, fecha y mensaje.
Tag (etiqueta anotada)	Un puntero con nombre a un objeto —normalmente un commit—, con su propio mensaje y su autor.

Dos ideas que explican el resto del sistema y que se preguntan:

• Git guarda instantáneas, no diferencias. Cada confirmación referencia el estado completo del proyecto; los ficheros que no cambiaron simplemente reutilizan el mismo blob. Eso es lo que hace que cambiar de rama sea instantáneo.
• Todo se identifica por el resumen de su contenido. Si el contenido cambia, cambia el identificador; y como cada commit incluye el de su padre, alterar el pasado cambia todos los identificadores posteriores. De ahí que reescribir el historial de una rama compartida sea una operación grave.

3.4. Los comandos que hay que llevar sabidos

Comando	Qué hace	El matiz que se pregunta
git init	Crea un repositorio nuevo y vacío en el directorio actual.	Se usa al empezar de cero, NO para traerse uno existente.
🚨 git clone	Trae una copia completa de un repositorio remoto.	Es la respuesta cuando el enunciado dice «se han sustituido los equipos y hay que traerse el repositorio».
git status	Dice en qué rama estamos y qué hay modificado o preparado.	No cambia nada: solo informa.
git add	Mueve los cambios al área de preparación.	Deja los ficheros en estado staged.
🚨 git commit	Guarda en el repositorio LOCAL una instantánea de los cambios previamente preparados.	Esa frase es literal del examen. No sube nada al servidor: eso es otro comando.
git log	Muestra el historial de confirmaciones.	Con la opción de una línea por commit es como se lee un grafo de ramas.
git diff	Muestra las diferencias entre zonas.	Sin argumentos compara trabajo contra índice, no contra la última confirmación.
git branch	Lista, crea o borra ramas.	Crear una rama es escribir un fichero de 41 bytes: por eso es instantáneo.
git checkout / git switch	Cambia de rama o restaura ficheros.	Las versiones modernas separaron las dos funciones en switch y restore.
git merge	Integra una rama en otra creando una confirmación de fusión.	Conserva la historia real, con sus bifurcaciones.

3.5. 🚨 Trabajar con remotos: fetch, pull y push

Aquí está la pregunta más fina que ha puesto el tribunal sobre Git, y merece el detalle completo porque su respuesta correcta llegaba a citar un fichero interno.

Comando	Qué hace exactamente
🚨 git fetch	Descarga objetos y referencias del remoto y actualiza las ramas de seguimiento remoto, registrando lo obtenido en .git/FETCH_HEAD, SIN integrar los cambios en la rama actual. Es decir: trae, pero no toca tu trabajo.
git pull	Es fetch seguido de merge —o de rebase, si así se configura—: trae Y integra en la rama actual.
git push	Envía las confirmaciones locales al remoto y actualiza allí la rama correspondiente.
git remote	Gestiona los remotos configurados. Por convenio, el principal se llama origin.

⚠️ La distinción que se explota: los tres distractores de aquella pregunta describían, respectivamente, un pull —descargar y fusionar automáticamente—, un push —subir los commits locales— y un reinicio brusco contra el remoto —sustituir el historial local reescribiendo commits—. Es decir: los tres describían operaciones REALES, pero de otros comandos. Por eso la única forma de acertar es saber que el rasgo distintivo de fetch es que no integra nada.

La consecuencia práctica de esa diferencia es una recomendación habitual en los equipos: usar fetch y mirar lo que ha llegado antes de integrarlo, en vez de un pull a ciegas que puede dejar el trabajo a medias en mitad de una fusión con conflictos.

3.6. Deshacer y mover cambios

Operación	Qué hace	Cuándo se usa
git revert	Crea una confirmación NUEVA que deshace los cambios de otra.	Cuando el commit ya está compartido: no reescribe el historial, así que es la vía segura.
git reset	Mueve la rama a otra confirmación. Con la opción suave conserva los cambios; con la dura los destruye.	Solo en local, antes de compartir. ⚠️ La opción dura borra trabajo sin preguntar.
🚨 git cherry-pick	Aplica en la rama actual un commit concreto tomado de otra rama.	Es la respuesta a «he detectado un error en un commit y quiero llevarlo a una rama aparte para investigarlo».
git stash	Guarda temporalmente los cambios sin confirmar y deja el directorio limpio.	Cuando hay que cambiar de rama a toda prisa con trabajo a medias.
git rebase	Reescribe una serie de confirmaciones sobre otra base, dejando el historial lineal.	⚠️ Nunca sobre una rama ya compartida: cambia todos los identificadores.
git bisect	Busca por bisección el commit que introdujo un fallo.	Cuando se sabe que antes funcionaba y ahora no, pero no dónde se rompió.

⚠️ La familia de distractores de la pregunta del cherry-pick merece mención aparte porque retrata al tribunal: las tres opciones falsas eran banana-pick, berry-pick y grape-pick. Es un caso extremo de la mecánica habitual —inventar nombres verosímiles alrededor del real—, y la única defensa es haber visto el comando escrito.

3.7. Fusiones y conflictos

Un conflicto aparece cuando dos ramas modifican las mismas líneas de un mismo fichero y Git no puede decidir cuál vale. Lo que hay que saber:

• Git marca el fichero con las marcas de conflicto que delimitan la versión de cada lado, y detiene la fusión.
• Lo resuelve una persona: se edita el fichero dejando el contenido correcto, se prepara con add y se confirma.
• Si dos ramas tocan ficheros distintos, o líneas distintas del mismo fichero, la fusión es automática: no hay conflicto.
• La fusión rápida ocurre cuando la rama de destino no ha avanzado: entonces basta con mover el puntero y no se crea confirmación de fusión.

Y la regla práctica que evita la mitad de los conflictos: ramas cortas y fusiones frecuentes. Una rama que vive tres semanas acumula divergencia y termina en una fusión dolorosa.

3.8. El fichero .gitignore y lo que nunca debe entrar

El fichero .gitignore declara, con patrones, qué no debe seguir Git. Lo que se queda fuera por norma:

• Los artefactos de construcción —el directorio de compilación, los ejecutables— porque se regeneran.
• Las dependencias descargadas: se declaran en el fichero de dependencias, no se copian al repositorio.
• Los ficheros del entorno de desarrollo y del sistema operativo.
• 🚨 Los secretos: claves, contraseñas y certificados. Y si uno entra por error, hay que darlo por comprometido y rotarlo: borrarlo después no lo quita del historial.

4. Estrategias de ramas y convenios

4.1. Los tres modelos que se preguntan

Modelo	Cómo funciona	Cuándo encaja
Git Flow	Ramas de larga vida: main y develop, más ramas de característica, de publicación y de corrección urgente.	Productos con versiones que conviven y despliegues espaciados.
GitHub Flow	Una sola rama principal siempre desplegable, y ramas cortas de característica que entran por propuesta de fusión.	Servicios web con despliegue continuo.
Desarrollo sobre el tronco	Todo el mundo integra en la rama principal a diario, con las funciones a medias ocultas tras indicadores de característica.	Equipos con integración continua madura y buena batería de pruebas.

La rama develop que menciona uno de los supuestos oficiales es precisamente la del primer modelo: la rama de integración donde se acumula lo que irá en la próxima publicación.

4.2. Convenios de mensajes y de versiones

Dos convenios que van juntos y que conviene reconocer:

• Mensajes convencionales: el mensaje de la confirmación empieza por un tipo —feat, fix, docs, refactor, test, chore— seguido de dos puntos y una descripción breve en imperativo. Lo importante no es el estilo, sino que una máquina puede leerlo y deducir qué versión toca publicar.
• Versionado semántico: tres cifras —mayor, menor y parche—, donde la primera sube cuando el cambio ROMPE la compatibilidad, la segunda cuando se AÑADE algo compatible y la tercera cuando solo se CORRIGE. Enlazado con lo anterior, un mensaje que declare un cambio rompedor obliga a subir la primera cifra.

5. Plataformas de desarrollo colaborativo

5.1. Cuáles son y qué añaden

Una plataforma de desarrollo colaborativo aloja repositorios y añade encima todo lo demás: revisión de código, seguimiento de incidencias, documentación, automatización y gestión de permisos. Las que hay que reconocer:

Plataforma	Rasgo característico
GitHub	La mayor comunidad de código abierto. Su automatización se llama GitHub Actions y su propuesta de fusión, pull request.
GitLab	Plataforma completa con integración continua propia. Se puede instalar en las instalaciones propias, lo que explica su presencia en la Administración. Su propuesta se llama merge request.
Bitbucket	Integrada con el resto de herramientas de su fabricante, muy usada en entornos corporativos.
Gitea y similares	Alternativas ligeras y de código abierto para alojar repositorios en casa.

5.2. 🚨 La propuesta de fusión

Cayó en 2026 en los dos modelos con este enunciado: «en el contexto de una plataforma de desarrollo colaborativo, ¿qué describe mejor una pull request?». Y la respuesta es:

Una propuesta para fusionar un conjunto de cambios de una rama en otra.

⚠️ Es una función de la PLATAFORMA, no un comando de Git. Ese es el corazón de la pregunta: el primer distractor describía git pull, el segundo el etiquetado y el tercero inventaba un mecanismo para volver a la versión anterior en producción. Ninguno de los tres es la propuesta de fusión.

Lo que ocurre dentro de una propuesta de fusión y que conviene saber:

• Se abre desde una rama y contra otra, y muestra el conjunto de diferencias completo.
• Permite revisión por pares: comentarios línea a línea, peticiones de cambio y aprobación.
• Dispara la integración continua: se ejecutan las pruebas y los análisis sobre la propuesta, y su resultado se muestra en ella.
• Puede exigir condiciones para fusionar: número mínimo de aprobaciones, pruebas en verde, revisión de las personas propietarias del código.
• Al aceptarse se integra, y la plataforma ofrece varias formas: fusión corriente, aplastar todo en una confirmación o reorganizar sobre la base.

5.3. 🚨 Los ficheros del repositorio

Otra pregunta de reconocimiento: «va a crear un fichero en el que incluirá el propósito del proyecto y cómo arrancarlo localmente». La respuesta es README.MD. Los cuatro ficheros que se preguntan juntos:

Fichero	Para qué sirve
🚨 README	La puerta de entrada: qué es el proyecto, para qué sirve, cómo instalarlo y cómo arrancarlo. Es lo que la plataforma muestra al abrir el repositorio.
LICENSE	La licencia bajo la que se publica el código. Sin ella, por defecto, nadie tiene derecho a reutilizarlo.
CODEOWNERS	Quién es propietario de cada parte del código: se usa para pedir su revisión automáticamente en las propuestas de fusión.
CONTRIBUTING	Cómo contribuir: convenios, proceso, requisitos antes de abrir una propuesta.
CHANGELOG	El registro de cambios por versión, legible por personas.
CITATION	Cómo citar el proyecto en un trabajo académico. Es el distractor menos conocido de esa pregunta.

5.4. Incidencias, tableros y documentación

Las plataformas incorporan además tres piezas que sustituyen a herramientas separadas:

• Incidencias: cada tarea, error o propuesta tiene su hilo, sus etiquetas, su responsable y su hito. Al citar su número en un mensaje de confirmación, la plataforma enlaza las dos cosas, y ahí está la trazabilidad entre el requisito y el código que lo implementa.
• Tableros de proyecto: la vista de columnas para gestionar el flujo de trabajo, que es donde se apoya un equipo que trabaja con Kanban.
• Documentación: desde una wiki hasta un sitio generado a partir de ficheros de marcado que viven en el propio repositorio, que es la práctica de tratar la documentación como código.

5.5. 🚨 La integración continua de la plataforma

La pregunta oficial es de una precisión inusual: «¿dónde deben almacenarse los ficheros de flujos de trabajo y qué extensión deben tener?». La respuesta:

En el directorio .github/workflows, con extensión .yml o .yaml.

⚠️ Los tres distractores cambiaban una pieza cada uno: el directorio —.github/actions, que existe pero es para acciones propias, o .git/workflows, que es meterse en las tripas del repositorio— o el formato —JSON en vez de YAML—. Conviene además retener que las dos extensiones son válidas: quien haya memorizado solo una de las dos falla si el enunciado ofrece la otra.

Un flujo de trabajo se compone de disparadores —una subida, una propuesta de fusión, una hora programada—, trabajos que se ejecutan en un entorno y pasos dentro de cada trabajo. Es donde se enganchan la construcción, las pruebas, el análisis de calidad y el despliegue: la traducción práctica de la integración y la entrega continuas.

3.9. Apache Subversion, el centralizado que sigue vivo

Merece apartado propio porque el tribunal lo nombró en su pregunta de control de versiones y porque en la Administración sigue habiendo repositorios en producción con él. Su vocabulario es distinto del de Git y conviene no mezclarlos:

Subversion	Qué hace	Su equivalente en Git
checkout	Trae del servidor una copia de trabajo, sin el historial.	Se parece a clone, pero el clon SÍ trae el historial completo.
commit	Envía los cambios directamente al servidor. Es una operación de red.	En Git, commit es local y hace falta un push aparte.
update	Trae al puesto los cambios que otros han confirmado.	pull
revision	Un número correlativo que identifica el estado del repositorio entero.	En Git el identificador es el resumen criptográfico del contenido, no un número.
trunk, branches, tags	Tres directorios por convenio: el tronco, las ramas y las etiquetas.	En Git son referencias, no directorios.
lock	Bloqueo de un fichero para que nadie más lo toque.	Git no bloquea: apuesta por la fusión.

⚠️ La diferencia conceptual que se pregunta: en Subversion una rama es una copia de un directorio, y por eso crear ramas resulta costoso y poco frecuente; en Git es un puntero de cuarenta y un bytes, y por eso el flujo de trabajo entero gira alrededor de ellas. Y la consecuencia práctica más visible: sin red, en Subversion no se puede confirmar.

3.10. Un flujo de trabajo completo, paso a paso

Ordenar los comandos en una secuencia real es la mejor forma de fijarlos, y de paso resuelve varios supuestos prácticos de los que pone el tribunal. El caso típico —una persona que se incorpora al equipo y hace su primera aportación— es este:

1. Traerse el proyecto. git clone con la dirección del repositorio: baja el código y el historial completo, y deja configurado el remoto con el nombre origin.
2. Ponerse al día. git fetch para ver qué ha llegado sin tocar nada, y solo después integrar. Es la comprobación que evita empezar sobre una base desfasada.
3. Abrir una rama. Una rama corta con nombre significativo, creada desde la rama de integración que corresponda.
4. Trabajar y preparar. Se edita, y con git add se llevan al área de preparación los cambios que forman una unidad con sentido: los ficheros quedan en estado staged.
5. Confirmar. git commit guarda la instantánea en el repositorio local, con un mensaje que explique el POR QUÉ. El qué ya lo dice el propio cambio.
6. Publicar la rama. git push la sube al remoto por primera vez, dejándola disponible para los demás.
7. Abrir la propuesta de fusión desde la plataforma. Ahí se disparan las pruebas y el análisis de calidad, y empieza la revisión por pares.
8. Atender la revisión. Se corrige lo señalado con nuevas confirmaciones sobre la misma rama, que aparecen solas en la propuesta.
9. Integrar. Cumplidas las condiciones —aprobaciones y pruebas en verde—, se fusiona y se borra la rama.

Y los dos desvíos habituales, que son justo los que pregunta el examen en forma de supuesto:

• «He detectado el error en un commit concreto y quiero investigarlo aparte» → se crea una rama y se lleva ese commit con git cherry-pick. No hace falta arrastrar toda la rama de origen.
• «Hay que deshacer algo que ya está en la rama compartida» → git revert, que añade una confirmación inversa. Nunca un reinicio duro sobre una rama que otros ya han descargado: les reescribiría el historial.

3.11. La gestión de la configuración del software

El control de versiones es la herramienta; la gestión de la configuración es la disciplina que lo engloba, y aparece como interfaz transversal en Métrica v3, así que conviene tener su vocabulario:

Concepto	Qué significa
Elemento de configuración	Cada pieza sometida a control: no solo el código, también los documentos, los guiones de despliegue y la configuración.
Línea base	Un conjunto de elementos revisado y aprobado en un momento dado, que se convierte en la referencia: a partir de ahí, los cambios pasan por un procedimiento formal.
Control de cambios	El procedimiento para solicitar, evaluar, aprobar y verificar una modificación sobre una línea base.
Auditoría de la configuración	La comprobación de que lo que hay coincide con lo que debería haber, y de que todo cambio está justificado.
Informe de estado	Qué versión está en cada entorno y qué cambios contiene.

La traducción moderna de todo esto es directa: la línea base es una etiqueta en el repositorio, el control de cambios es la propuesta de fusión con sus aprobaciones, y el informe de estado se obtiene del propio historial. Lo que antes era papeleo hoy lo produce la herramienta, pero los conceptos y las preguntas siguen siendo los mismos.

3.12. Entornos y publicación

La cadena habitual, que se pregunta por su orden:

1. Local: el puesto de quien desarrolla.
2. Integración: donde se construye y se prueba automáticamente cada cambio.
3. Preproducción: una réplica lo más fiel posible de producción, con datos anonimizados, para las pruebas de sistema y de aceptación.
4. Producción: el entorno real.

Y tres estrategias de despliegue cuyos nombres conviene reconocer: el despliegue azul-verde, que mantiene dos entornos idénticos y conmuta el tráfico de uno a otro —con vuelta atrás inmediata—; el despliegue canario, que envía primero un porcentaje pequeño del tráfico a la versión nueva y lo aumenta si no hay incidencias; y los indicadores de característica, que permiten llevar código a producción con la funcionalidad apagada y encenderla después sin desplegar.

6. Estructura y actualización de repositorios

El enunciado oficial del tema empieza por «repositorios: estructura y actualización», y conviene entender que la palabra repositorio designa dos cosas distintas que el examen puede cruzar.

6.1. Repositorio de código y repositorio de artefactos

	Repositorio de código fuente	Repositorio de artefactos
Qué guarda	El código y su historial completo.	Lo construido: bibliotecas, paquetes, imágenes de contenedor.
Cómo se actualiza	Con confirmaciones y fusiones.	Publicando una versión nueva; los artefactos son inmutables.
Ejemplos	Git sobre GitHub, GitLab o Subversion.	Repositorios de paquetes públicos o privados de cada tecnología.

⚠️ La regla que se pregunta sobre los artefactos: una versión publicada no se reemplaza. Si algo va mal, se publica una versión nueva, porque quien ya descargó la anterior no puede quedar con un contenido distinto bajo el mismo número. Esa inmutabilidad es lo que hace reproducible una construcción.

6.2. La estructura típica de un repositorio

No hay una norma única, pero sí un patrón que se repite y que conviene reconocer:

• Código fuente separado del código de pruebas, en directorios paralelos.
• Fichero de dependencias y de construcción en la raíz: el modelo de objetos del proyecto en Maven, el guion de Gradle, el fichero de proyecto en la plataforma .NET o el descriptor de paquete en Node.
• Documentación en su directorio, tratada como código.
• Configuración de la automatización en el directorio que exija la plataforma.
• Ficheros de convivencia en la raíz: el que explica el proyecto, la licencia, el de exclusiones y los de contribución.

6.3. Un repositorio o muchos

	Repositorio único	Un repositorio por componente
Ventaja	Un cambio que atraviesa varios módulos se hace y se revisa de una vez; la refactorización global es viable.	Cada equipo despliega y versiona por su cuenta, con permisos separados.
Inconveniente	Crece mucho y exige herramientas de construcción capaces de compilar solo lo afectado.	Un cambio transversal obliga a coordinar varias propuestas de fusión y varias publicaciones.

6.4. Repositorios de dependencias y su actualización

Cada plataforma tiene el suyo, y el nombre se pregunta: el repositorio central de Maven en el mundo Java, el registro de paquetes de Node, el de la plataforma .NET y el índice de paquetes de Python. Tres reglas de gestión que conviene tener:

• Fijar las versiones con un fichero de bloqueo, para que dos construcciones del mismo código den exactamente el mismo resultado.
• Actualizar de forma continua y automatizada, con análisis de vulnerabilidades en cada construcción: una dependencia con un fallo conocido y sin parchear es uno de los riesgos del catálogo de OWASP.
• Usar un repositorio interno espejo en organizaciones grandes, para no depender de la disponibilidad de un servicio externo y poder filtrar lo que entra.

7. Generación de código y documentación

7.1. Generación de código

Generar código es producirlo automáticamente a partir de una descripción de nivel más alto. Las formas que hay que reconocer:

Forma	De qué parte	Qué produce
Andamiaje	De una plantilla y unos parámetros.	El esqueleto de un proyecto o de un componente, listo para rellenar.
Desde el modelo de datos	Del esquema de la base o de las entidades.	Clases de acceso a datos y objetos de transferencia.
Desde el contrato de la interfaz	De un documento OpenAPI o de un WSDL.	El cliente o el esqueleto del servidor, en el lenguaje que se elija.
Desde el modelo	De un modelo en UML u otro lenguaje de modelado.	Es la idea de la arquitectura dirigida por modelos: transformar un modelo independiente de la plataforma en uno específico y de ahí al código.
Compilación	Del código fuente.	El caso extremo y más antiguo: todo compilador es un generador de código.

⚠️ La advertencia práctica que acompaña a todo esto: el código generado no se edita a mano, porque la siguiente regeneración se lleva los cambios por delante. Si hay que añadir algo, se hace en un fichero aparte —una clase parcial, una herencia, un fichero de extensión— y se deja el generado intacto. Es un error clásico y caro.

7.2. Documentación: la que se genera y la que se escribe

Conviene distinguir tres capas, porque cada una tiene su herramienta y su público:

Capa	Qué documenta	Cómo se produce
Del código	Clases, métodos, parámetros y valores devueltos.	Se genera a partir de los comentarios estructurados del propio código: la herramienta del kit de Java y sus equivalentes en otros lenguajes.
De la interfaz	Rutas, parámetros, esquemas y respuestas de una API.	Se genera desde las anotaciones, con la especificación OpenAPI, y de ella sale la página navegable.
Del proyecto	Qué hace, cómo se arranca, cómo se despliega y por qué se decidió así.	Se escribe, en ficheros de marcado que viven en el repositorio.

La práctica de tener la documentación en el repositorio, revisada en la misma propuesta de fusión que el código, se conoce como documentación como código, y su ventaja es evidente: si se revisan juntas, no se desincronizan.

Y una pieza que conviene conocer por su nombre: los registros de decisiones de arquitectura. Son documentos cortos y numerados que dejan constancia de una decisión —qué se decidió, en qué contexto, qué alternativas se descartaron y con qué consecuencias—. Resuelven el problema de que, dos años después, nadie recuerda por qué se eligió aquella base de datos.

8. Metodologías de desarrollo

8.1. Los ciclos de vida clásicos

Modelo	Cómo funciona	Su problema
Cascada	Fases secuenciales: requisitos, análisis, diseño, construcción, pruebas e implantación. Cada una termina antes de empezar la siguiente.	Los requisitos se congelan al principio, y el error solo aparece al final, cuando corregirlo es carísimo.
En V	La cascada doblada: cada fase de la izquierda tiene enfrente su nivel de prueba —los requisitos con la aceptación, el diseño del sistema con las pruebas del sistema, el detallado con las unitarias—.	Sigue siendo secuencial, pero al menos vincula cada nivel con su verificación.
Prototipos	Se construye una maqueta para aclarar requisitos y se desecha o se evoluciona.	El riesgo de que el prototipo acabe en producción.
Incremental	El sistema se entrega por partes funcionales sucesivas.	Exige una arquitectura que aguante el crecimiento.
Espiral	Ciclos que repiten planificación, análisis de riesgos, construcción y evaluación. Su rasgo distintivo es el análisis de riesgos en cada vuelta.	Es pesado y solo se justifica en proyectos grandes y de riesgo alto.

8.2. Métrica versión 3

Es la metodología de planificación, desarrollo y mantenimiento de sistemas de información promovida por la Administración General del Estado, y aunque tiene años sigue apareciendo en los exámenes con preguntas literales. Lo que hay que saber:

• Ofrece dos caminos: el estructurado —con el modelo entidad-relación y los diagramas de flujo de datos— y el orientado a objetos, que emplea la notación UML.
• Se organiza en procesos principales —planificación de sistemas de información, desarrollo y mantenimiento— y el de desarrollo se divide en estudio de viabilidad, análisis, diseño, construcción e implantación y aceptación.
• Incorpora interfaces que atraviesan todos los procesos: gestión de proyectos, aseguramiento de la calidad, seguridad y gestión de la configuración.
• Y describe técnicas y prácticas —de desarrollo, de gestión y prácticas— que es de donde salen varias preguntas oficiales, incluida la de la optimización del modelo físico de datos.

8.3. El enfoque ágil

El manifiesto ágil de 2001 enunció cuatro valores, y su forma importa porque el examen los cita: se valora lo de la izquierda más que lo de la derecha, sin que lo de la derecha carezca de valor.

Se valora más…	…que
Individuos e interacciones	Procesos y herramientas
Software funcionando	Documentación extensiva
Colaboración con el cliente	Negociación contractual
Respuesta ante el cambio	Seguir un plan

⚠️ El error que se pregunta: ágil NO significa «sin documentación» ni «sin plan». Significa que la documentación y el plan están al servicio del producto y no al revés. Los doce principios que acompañan al manifiesto insisten en la entrega temprana y continua, en aceptar el cambio incluso tarde, en el ritmo sostenible y en la reflexión periódica del equipo.

7.3. Los tipos de documentación de un proyecto

El enunciado oficial pone la documentación al mismo nivel que la generación de código, así que conviene tener el mapa completo de qué se documenta y para quién. La clasificación que se maneja:

Documento	Para quién	Qué contiene
De requisitos	Para quien encarga y para quien construye.	Qué debe hacer el sistema, con sus requisitos funcionales y no funcionales.
De análisis y diseño	Para el equipo técnico.	Modelos de datos y de procesos, arquitectura, decisiones y diagramas.
Técnica del código	Para quien mantiene.	Clases, métodos y parámetros. Se genera desde los comentarios estructurados.
De la interfaz	Para quien consume la API.	Rutas, parámetros, esquemas y respuestas. Se genera con OpenAPI.
De explotación	Para quien opera el sistema.	Cómo desplegar, cómo vigilar, qué hacer ante los fallos conocidos.
De usuario	Para quien lo usa.	Manuales y ayuda, que también deben ser accesibles.

Las reglas de oro que se preguntan como buenas prácticas son tres, y las tres apuntan al mismo problema —la documentación que miente—:

• Lo que puede generarse, se genera. Una lista de parámetros escrita a mano queda desfasada en la primera semana.
• Lo que se escribe, vive con el código y se revisa en la misma propuesta de fusión. Es la documentación como código.
• Se documenta el POR QUÉ, no el qué. El qué ya lo dice el código; lo que el código no puede contar es por qué se descartaron las otras dos alternativas.

8.7. El proceso unificado

Entre los ciclos clásicos y los ágiles conviene situar el proceso unificado de desarrollo, porque comparte vocabulario con UML y con Métrica. Sus tres rasgos característicos se preguntan juntos:

• Dirigido por casos de uso: los casos de uso guían el análisis, el diseño, la implementación y las pruebas.
• Centrado en la arquitectura: se construye pronto un esqueleto ejecutable que valida las decisiones estructurales.
• Iterativo e incremental: se avanza en iteraciones cortas que añaden funcionalidad.

Se organiza en cuatro fases —inicio, elaboración, construcción y transición—, y cada fase contiene varias iteraciones en las que se hacen, en distinta proporción, todas las disciplinas —modelado del negocio, requisitos, análisis y diseño, implementación, pruebas y despliegue—. Esa idea de que todas las disciplinas están presentes en todas las fases, con distinta intensidad, es lo que lo separa de la cascada y su gráfico característico.

8.8. Estimación y seguimiento en los marcos ágiles

Un bloque de vocabulario que aparece en los supuestos y que conviene reconocer:

Término	Qué es
Historia de usuario	La descripción breve de una necesidad desde el punto de vista de quien la tiene: como tal persona, quiero tal cosa, para tal fin. Se acompaña de criterios de aceptación.
Puntos de historia	Una medida relativa de esfuerzo y complejidad, no de horas. Se estiman en equipo, con frecuencia por una escala tipo Fibonacci.
Velocidad	Los puntos que el equipo completa por sprint. Sirve para PREVER, no para comparar equipos ni para presionar.
Gráfico de trabajo pendiente	La curva que muestra cuánto queda a lo largo del sprint.
Refinamiento	La actividad continua de desglosar y aclarar los elementos de la lista de producto. No es un evento formal de Scrum, pero está previsto como actividad.
Definición de terminado	El acuerdo del equipo sobre qué significa que algo está acabado: probado, documentado, revisado y desplegable. Es un compromiso del incremento.

⚠️ Dos confusiones que se preguntan. La primera: la definición de terminado es del equipo y vale para todo, mientras que los criterios de aceptación son específicos de cada historia. Y la segunda: los puntos de historia no son horas, y traducirlos a horas destruye su utilidad.

8.4. 🚨 Scrum, según su guía oficial

Es el marco ágil más preguntado, y el tribunal lo hace citando expresamente «la Guía de Scrum», así que hay que usar su vocabulario exacto. Scrum se define por tres responsabilidades, cinco eventos y tres artefactos.

Las tres responsabilidades del Equipo de Scrum

Responsabilidad	De qué responde
Product Owner	De maximizar el valor del producto. Es quien gestiona y ordena la lista de producto, y decide qué entra y en qué orden. Es una persona, no un comité.
🚨 Scrum Master	De que Scrum se entienda y se aplique. Es un líder al servicio del equipo: retira impedimentos, facilita los eventos y forma a la organización. NO es un jefe de proyecto ni asigna tareas.
Developers	De crear el incremento en cada sprint. Son autogestionados: deciden cómo hacer el trabajo.

⚠️ La pregunta oficial ponía como distractores «Sprint Owner», «Scrum Planner» y «Stakeholder». Los dos primeros NO existen. Y el tercero es especialmente traicionero porque sí existe como concepto —las partes interesadas— pero NO forma parte del Equipo de Scrum: es alguien externo que aporta información y recibe el incremento.

Los cinco eventos

Evento	Para qué	Duración orientativa
El Sprint	Es el contenedor de los demás: un periodo fijo, de un mes o menos, al final del cual hay un incremento utilizable. No se alarga ni se acorta.	Hasta un mes.
Sprint Planning	Planificar el sprint: por qué es valioso, qué se puede hacer y cómo se hará.	Hasta ocho horas para un sprint de un mes.
Daily Scrum	Sincronizar el trabajo del día y detectar impedimentos. Es de los developers.	Quince minutos, a la misma hora y en el mismo sitio.
Sprint Review	Inspeccionar el incremento con las partes interesadas y adaptar la lista de producto. Mira al PRODUCTO.	Hasta cuatro horas para un sprint de un mes.
🚨 Sprint Retrospective	Inspeccionar cómo ha trabajado el equipo —personas, interacciones, procesos y herramientas— y decidir mejoras. Mira al PROCESO.	Hasta tres horas para un sprint de un mes.

🚨 La pregunta que ha caído sobre esto plantea que, durante un sprint, alguien detecta una mala práctica que puede ralentizar el proyecto y pregunta en qué reunión la comentará para buscar la mejora continua y evitar aplicarla en los siguientes sprints. La respuesta es la Sprint Retrospective, y la clave para no fallarla es la distinción anterior: la revisión mira el producto y la retrospectiva mira el proceso. La reunión diaria sirve para sincronizarse, no para mejorar el método, y la planificación mira hacia delante.

Los tres artefactos y sus compromisos

Artefacto	Qué es	Su compromiso
Product Backlog	La lista ordenada de todo lo que podría necesitar el producto.	El objetivo de producto.
Sprint Backlog	Lo seleccionado para el sprint más el plan para entregarlo.	El objetivo del sprint.
Incremento	El paso concreto hacia el objetivo del producto, ya utilizable.	La definición de terminado.

Y dos ideas que se preguntan por su matiz: el alcance del sprint puede negociarse con el responsable del producto a medida que se aprende, pero el objetivo del sprint no cambia; y solo el responsable del producto puede cancelar un sprint, cosa que en la práctica casi nunca ocurre.

8.5. Kanban y otros marcos

Marco	Su rasgo distintivo
Kanban	Visualizar el flujo en un tablero y limitar el trabajo en curso. No tiene iteraciones fijas ni roles propios: es un método de mejora evolutiva que se superpone al proceso existente.
Programación extrema	Prácticas de ingeniería: programación por parejas, desarrollo guiado por pruebas, integración continua, refactorización, propiedad colectiva del código y cliente en el equipo.
Lean	Eliminar el desperdicio, decidir lo más tarde posible, entregar lo antes posible y optimizar el conjunto y no las partes.
Escalado	Marcos para coordinar varios equipos sobre un mismo producto.

⚠️ La diferencia que más se pregunta: Scrum trabaja por iteraciones de duración fija y Kanban por flujo continuo. En Scrum el compromiso es el objetivo del sprint; en Kanban, el límite de trabajo en curso. Y las dos cosas pueden combinarse.

8.6. DevOps

No es una metodología de desarrollo sino una cultura y un conjunto de prácticas que unen desarrollo y operación para acortar el tiempo entre escribir un cambio y tenerlo funcionando, sin perder estabilidad. Sus piezas:

• Integración continua: cada cambio se integra en la rama principal y se verifica automáticamente con la construcción y las pruebas.
• Entrega continua: la rama principal está siempre en condiciones de desplegarse, y el despliegue es una decisión de negocio.
• Despliegue continuo: se va un paso más allá y todo lo que pasa las pruebas se despliega solo.
• Infraestructura como código: los servidores y la red se declaran en ficheros versionados, no se configuran a mano.
• Vigilancia y observabilidad: métricas, registros y trazas para saber qué está pasando en producción.

⚠️ La distinción entre entrega y despliegue continuos es exactamente la que se pregunta: en la primera el paso final lo autoriza una persona; en el segundo, no hay paso manual.

9. Pruebas

9.1. 🚨 Los niveles de prueba de Métrica v3

Es la clasificación que usa el tribunal cuando pregunta «según establece Métrica v3», y hay que llevarla con la definición de cada nivel porque la pregunta la da literal:

Nivel	Qué verifica
Unitarias	Cada componente por separado, comprobando que su lógica interna funciona según lo especificado.
🚨 De integración	Que los componentes o subsistemas interactúan correctamente a través de sus interfaces, tanto internas como externas, cubriendo la funcionalidad y ajustándose a los requisitos.
Del sistema	El sistema completo frente a los requisitos: funcionalidad, rendimiento, seguridad, volumen, sobrecarga.
De implantación	El sistema en su entorno real de operación, con sus comunicaciones y sus interfaces con otros sistemas.
De aceptación	Las realiza el usuario para dar por bueno el sistema desde el punto de vista de su funcionalidad y su rendimiento.
🚨 De regresión	Que los cambios sobre un componente no introducen un comportamiento no deseado ni errores adicionales en otros componentes no modificados.

🚨 La pregunta de 2026 sobre pruebas de software se contestaba precisamente con la definición de las de regresión, y sus tres distractores son un catálogo de errores que conviene reconocer:

• Decía que las de caja blanca consideran «exclusivamente las entradas y salidas sin preocuparse por la estructura interna». Es al revés: eso describe la caja NEGRA.
• Decía que las unitarias sirven para que el usuario determine su aceptación final. Eso son las de aceptación.
• E inventaba unas «pruebas circunstanciales» a las que atribuía la descripción de las de integración. Ese nombre no existe.

9.2. Caja blanca, caja negra y caja gris

Enfoque	Qué se conoce	Qué se diseña
Caja negra	Solo entradas y salidas: la estructura interna no importa.	Casos por clases de equivalencia, valores límite, tablas de decisión.
Caja blanca	La estructura interna del código.	Casos que recorran sentencias, decisiones, condiciones y caminos: es donde se mide la cobertura.
Caja gris	Un conocimiento parcial del interior.	Combina las dos: se conoce la estructura de datos o la arquitectura, pero se prueba por la interfaz.

Dos técnicas de caja negra que conviene nombrar: las clases de equivalencia —dividir el rango de entradas en grupos que deberían comportarse igual y probar un representante de cada uno— y el análisis de valores límite —probar justo en la frontera y a un paso de ella, porque ahí es donde se concentran los errores—.

9.3. La pirámide y las herramientas

La imagen que ordena las pruebas automatizadas: muchas unitarias abajo, rápidas y precisas; menos de integración en medio; y pocas de extremo a extremo arriba, lentas y caras pero las únicas que comprueban el sistema como lo vive el usuario. Las herramientas que hay que reconocer:

Herramienta	Para qué
JUnit, NUnit, xUnit	Pruebas unitarias en Java y en la plataforma .NET.
Mockito, Moq	Objetos simulados: sustituyen una dependencia y permiten comprobar cómo se la llamó.
Selenium	Automatización del navegador para pruebas de extremo a extremo.
Cucumber	Desarrollo guiado por comportamiento: los casos se escriben en lenguaje casi natural.
JMeter	Pruebas de carga y de rendimiento.
Postman	Prueba manual y automatizada de servicios REST.

🚨 Y un detalle de nomenclatura que preguntó el tribunal: para implementar pruebas unitarias de un componente del lado del cliente, el fichero con el que se trabaja es el de extensión .spec —de specification—, que es el convenio de los marcos de JavaScript. Los distractores ofrecían las extensiones del propio componente, de su módulo y una genérica de prueba.

9.4. Desarrollo guiado por pruebas

El ciclo es rojo, verde, refactor: primero se escribe una prueba que falla, luego el código mínimo que la hace pasar y por último se limpia el diseño sin romperla. Su valor no está solo en las pruebas resultantes, sino en que obliga a diseñar desde fuera, pensando en cómo se va a usar el código antes de escribirlo.

Y dos advertencias que se preguntan: la cobertura es una medida de cantidad, no de calidad —se puede recorrer todo el código sin comprobar nada—, y una prueba que falla de forma intermitente sin que cambie el código es una prueba inestable: hay que arreglarla o quitarla, porque el equipo aprende a ignorar los fallos y con ellos se ignoran también los reales.

9.5. Las pruebas no funcionales

Los niveles de Métrica dicen dónde se prueba; esta clasificación dice qué se comprueba, y sus nombres se preguntan por separado:

Prueba	Qué mide	Cómo se distingue de su vecina
De carga	El comportamiento con la carga esperada.	Se busca confirmar que aguanta lo previsto.
De estrés	El comportamiento más allá del límite previsto.	Se busca el punto de rotura y, sobre todo, cómo se rompe: si degrada con dignidad o se cae de golpe.
De resistencia	El comportamiento con carga sostenida durante mucho tiempo.	Es la que descubre las fugas de memoria, que solo se manifiestan tras horas.
De volumen	El comportamiento con grandes cantidades de datos.	No mide usuarios simultáneos, sino tamaño de la información.
De seguridad	La resistencia frente a ataques.	Incluye el análisis estático, el dinámico y la prueba de penetración.
De accesibilidad	La conformidad con los criterios de las pautas.	Automática en parte, manual en el resto.
De usabilidad	La eficacia, la eficiencia y la satisfacción de uso.	Se hace con personas, no con herramientas.
De compatibilidad	El funcionamiento en distintos navegadores, sistemas y dispositivos.	Es donde se detectan los fallos que solo ocurren en un entorno.
De recuperación	La vuelta al servicio tras una caída.	Es la que da valor real al objetivo de tiempo de recuperación.

⚠️ La pareja que más se cruza es carga y estrés: la primera comprueba que el sistema aguanta lo que se espera de él, y la segunda lo lleva a propósito más allá para ver dónde y cómo cede. Confundirlas es el error típico.

9.6. El mantenimiento y sus cuatro tipos

Cerrar el ciclo de vida exige hablar del mantenimiento, que es donde se consume la mayor parte del esfuerzo de un sistema a lo largo de su vida. Métrica v3 y la normalización internacional distinguen cuatro tipos, y la clasificación se pregunta con enunciados de caso:

Tipo	Por qué se hace	Ejemplo
Correctivo	Para corregir un defecto detectado.	Un cálculo que redondea mal.
Adaptativo	Para adaptarse a un cambio del entorno.	Una versión nueva del sistema operativo, un cambio normativo, un tipo impositivo distinto.
Perfectivo	Para mejorar lo que ya funciona: más prestaciones o mejor rendimiento.	Optimizar una consulta lenta, añadir una funcionalidad pedida.
Preventivo	Para evitar problemas futuros.	Refactorizar un módulo enrevesado, actualizar una dependencia antes de que quede sin soporte.

⚠️ La confusión clásica es entre adaptativo y perfectivo. La regla que la resuelve: si el cambio viene de fuera —el entorno, la ley, la plataforma—, es adaptativo; si viene de dentro, porque se quiere mejorar algo que ya funcionaba, es perfectivo. Y el preventivo es el que nadie pide y todos agradecen: es exactamente la devolución de la deuda técnica.

6.5. Actualización y migración de repositorios

La segunda palabra del enunciado oficial es «actualización», y en el ciclo de vida de un repositorio hay tres operaciones que conviene conocer:

• Migrar de un sistema a otro. El caso frecuente en la Administración es pasar de un sistema centralizado a Git, y las herramientas de conversión permiten conservar el historial: cada revisión del sistema antiguo se convierte en una confirmación, con su autor y su fecha. Perder el historial en una migración es un error evitable, porque con él se pierde la trazabilidad de años.
• Archivar un repositorio cuyo proyecto termina: se marca como solo lectura, se etiqueta la última versión y se documenta dónde queda. Borrarlo destruye información que puede hacer falta años después.
• Depurar el historial cuando ha crecido demasiado —ficheros binarios grandes subidos por error, secretos filtrados—. Es una operación delicada porque reescribe todos los identificadores, obliga a que todo el equipo vuelva a clonar y, en el caso de los secretos, no exime de rotarlos.

Y una recomendación que enlaza con la copia de seguridad: aunque Git sea distribuido y cada clon contenga el historial, la plataforma que aloja el repositorio también necesita respaldo, porque en ella viven las incidencias, las propuestas de fusión, los comentarios de revisión y la configuración de la automatización, y nada de eso está en los clones.

10.4. La revisión de código: lo que ninguna herramienta hace

Las herramientas del apartado anterior encuentran lo mecánico. Lo demás lo encuentra una persona leyendo el cambio, y por eso la revisión por pares es la práctica de calidad con mejor relación entre coste y defectos detectados.

Qué se mira en una revisión, en orden de importancia:

1. ¿Hace lo que dice que hace? Es lo primero y lo que más se olvida: comprobar el cambio contra la incidencia que lo motiva.
2. ¿Se entiende? Un código que hay que descifrar dos veces se convertirá en un problema dentro de un año.
3. ¿Está probado? Un cambio de comportamiento sin prueba que lo fije se romperá sin que nadie se entere.
4. ¿Tiene efectos colaterales? Es donde el conocimiento del sistema del revisor supera a cualquier herramienta.
5. ¿Introduce riesgos de seguridad o de rendimiento? Una consulta dentro de un bucle, un dato del usuario concatenado, una llamada sin tiempo de espera.

Y las tres reglas de convivencia que hacen que funcione: cambios pequeños —una revisión de mil líneas no se hace, se firma—, comentarios sobre el código y no sobre la persona, y distinguir lo bloqueante de la sugerencia, para que quien recibe la revisión sepa qué debe corregir y qué es una opinión.

10.5. Métricas del proceso

Cierran el tema porque son las que permiten saber si todo lo anterior está funcionando. Las cuatro que se manejan como referencia:

Métrica	Qué mide	Qué revela si va mal
Frecuencia de despliegue	Cada cuánto se lleva algo a producción.	Lotes grandes y arriesgados.
Tiempo de entrega del cambio	Desde que se confirma hasta que está en producción.	Cuellos de botella en la cadena o en las aprobaciones.
Tiempo medio de restauración	Cuánto se tarda en recuperar el servicio tras un incidente.	Falta de vigilancia o de procedimientos ensayados.
Porcentaje de cambios fallidos	Qué proporción de despliegues provoca un incidente.	Pruebas insuficientes o entornos que no se parecen a producción.

⚠️ La lectura que importa es que las cuatro mejoran juntas: los equipos que despliegan más a menudo no rompen más, sino menos, porque los lotes pequeños son más fáciles de probar y de deshacer. Es lo contrario de lo que sugiere la intuición, y es el argumento de fondo de todo lo que se ha explicado en este tema.

10. Calidad del código y deuda técnica

10.1. 🚨 Analizar no es formatear

El tribunal ha puesto dos preguntas distintas sobre herramientas de calidad, y la única forma de acertar las dos es tener clara esta separación:

Categoría	Qué hace	Herramientas
Formateador	Impone un estilo uniforme —sangrado, comillas, longitud de línea— sin cambiar lo que el código hace. Se ejecuta al guardar y no admite discusión.	🚨 Prettier, y los formateadores equivalentes de cada lenguaje.
Analizador estático o linter	Detecta problemas: código muerto, variables sin usar, complejidad excesiva, malas prácticas y vulnerabilidades.	SonarQube, PMD, los analizadores de JavaScript.
Control de versiones	Nada que ver con la calidad del código.	⚠️ Mercurial, que es lo que el tribunal coló entre las herramientas de calidad.

Las dos preguntas oficiales, con su respuesta:

• «¿cuál de las siguientes NO le será de ayuda para analizar y mejorar la calidad del código?» → Mercurial, porque es un sistema de control de versiones. Las otras tres —el analizador de código abierto, un analizador de JavaScript y el analizador de Java— sí lo son.
• «¿cuál es una opción válida para formatear el código?» → Prettier. Y aquí la trampa es fina: SonarQube y PMD son herramientas reales de calidad, pero ANALIZAN, no formatean. Quien no distinga las dos funciones elige cualquiera de ellas y falla.

10.2. Qué mide un analizador de calidad

Un analizador como el más extendido de código abierto clasifica lo que encuentra en categorías que conviene reconocer:

• Errores: código que se comportará mal, como un puntero nulo garantizado.
• Vulnerabilidades: problemas de seguridad, como una consulta construida por concatenación.
• Puntos calientes de seguridad: código que puede ser un problema y necesita revisión humana.
• Olores del código: no rompe nada, pero dificulta el mantenimiento —métodos larguísimos, duplicación, complejidad ciclomática alta—.
• Cobertura y duplicación, tomadas de los informes de las pruebas.

🚨 Y el nombre exacto, porque el tribunal lo preguntó en 2023 en las dos convocatorias: «¿cuál es una herramienta de análisis de seguridad y calidad de código?». La respuesta es SonarQube, y los tres distractores eran SonarCode, SonarCuality —con la falta de ortografía incluida— y SonarSrc. Ninguno de los tres existe: son variaciones del nombre real, que es exactamente la misma mecánica de los banana-pick de la pregunta de Git y de las herramientas inventadas de accesibilidad. Cuando las cuatro opciones se parecen tanto entre sí, el examen no está midiendo comprensión: está midiendo si se ha visto el producto.

Del mismo apartado conviene reconocer también las anotaciones inventadas con que el tribunal rodeó a las de NUnit en 2026 —TestSample y TestGroup, que tampoco existen— frente a las reales, que son las de clase de pruebas, método de prueba y preparación y limpieza.

Y una idea que se pregunta por su nombre: la puerta de calidad. Es el conjunto de condiciones que un análisis debe cumplir para que la construcción se dé por buena —por ejemplo, ninguna vulnerabilidad nueva y una cobertura mínima en el código nuevo—. Colocada en la propuesta de fusión, impide que entre código que empeora el proyecto.

10.3. La deuda técnica

Es la metáfora que describe el coste futuro de una decisión cómoda tomada hoy: como una deuda financiera, se puede asumir conscientemente para llegar a tiempo, pero genera intereses —cada cambio posterior cuesta un poco más— y hay que devolverla.

Se distingue la deuda deliberada —se sabe que se está tomando un atajo y se apunta— de la accidental, que aparece porque el equipo aprendió algo después. La primera es gestionable; la segunda solo se descubre midiendo. En los dos casos, la práctica sana es hacerla visible: anotarla como incidencia, estimarla y planificar su devolución, en vez de dejar que crezca hasta que nadie se atreva a tocar un módulo.

11. Cuadros para memorizar

11.1. Los comandos de Git que se preguntan

Comando	En una frase
git clone	Traerse un repositorio existente.
git init	Crear uno nuevo y vacío.
git add	Pasar los cambios al área de preparación: quedan staged.
git commit	Guardar en el repositorio LOCAL la instantánea de lo preparado.
git fetch	Traer del remoto SIN integrar; registra en .git/FETCH_HEAD.
git pull	Traer E integrar: es fetch más merge.
git push	Subir los commits locales al remoto.
git cherry-pick	Llevarse UN commit concreto a la rama actual.
git revert	Deshacer con un commit nuevo, sin reescribir el historial.
git reset	Mover la rama atrás; con la opción dura, destruye trabajo.
git stash	Guardar temporalmente lo no confirmado.

11.2. Los nombres propios, por categoría

Categoría	Productos
Control de versiones	Git, Apache Subversion, CVS, Mercurial.
Plataformas colaborativas	GitHub, GitLab, Bitbucket, Gitea.
Calidad y análisis	SonarQube, PMD, los analizadores de cada lenguaje.
Formato	Prettier y equivalentes.
Pruebas unitarias	JUnit, NUnit, xUnit.
Dobles de prueba	Mockito, Moq.
Pruebas de interfaz y de carga	Selenium, Cucumber, JMeter, Postman.
Construcción	Maven, Gradle, MSBuild.

11.3. Scrum de un vistazo

	Los tres
Responsabilidades	Product Owner, Scrum Master, Developers.
Artefactos	Product Backlog, Sprint Backlog, Incremento.
Compromisos	Objetivo de producto, objetivo del sprint, definición de terminado.
Eventos	El Sprint, Planning, Daily (15 minutos), Review (producto) y Retrospective (proceso).

11.4. Las cifras y las cadenas literales

Dato	Valor
Modelo de datos de Git	Objects, References, Index, Reflogs
Objetos de Git	Blob, tree, commit, tag
Flujos de trabajo de la plataforma	.github/workflows, extensión .yml o .yaml
Fichero que explica el proyecto	README.MD
Pruebas unitarias del cliente	Ficheros .spec
Duración de la reunión diaria	15 minutos
Duración máxima de un sprint	Un mes
Valores del manifiesto ágil	Cuatro, con doce principios

12. Lo que ya ha preguntado el tribunal

Año	Qué preguntó	Respuesta
2024	Cuál de estas ternas sirve para el control de versiones	GitLab, GitHub y Apache Subversion. Las falsas colaban Selenium o Cucumber.
2024	Cuál NO ayuda a analizar y mejorar la calidad del código	Mercurial: es control de versiones.
2024	Fichero con el propósito del proyecto y cómo arrancarlo	README.MD.
2024	Pruebas que verifican la interacción por las interfaces, según Métrica v3	De integración.
2024	Reunión de Scrum para plantear una mejora del proceso	Sprint Retrospective.
2026	Qué describe mejor una pull request	Una propuesta para fusionar cambios de una rama en otra.
2026	Afirmación correcta sobre las pruebas de software	La definición de las de regresión; los distractores invertían la caja blanca e inventaban las «circunstanciales».
2026	Qué significa el estado Staged	Los cambios están marcados para el próximo commit.
2026	Comando que guarda la instantánea en el repositorio local	git commit.
2026	Qué hace git fetch	Descarga y actualiza las ramas de seguimiento sin integrar; registra en .git/FETCH_HEAD.
2026	Los cuatro tipos del modelo de datos de Git	Objects, References, Index y Reflogs.
2026	Operación para llevar un commit concreto a otra rama	git cherry-pick.
2026	Comando para clonar el repositorio en un equipo nuevo	git clone.
2026	Dónde van los flujos de trabajo y con qué extensión	.github/workflows, con .yml o .yaml.
2026	Un rol del Equipo de Scrum	Scrum Master. «Stakeholder» NO forma parte del equipo.
2026	Herramienta para formatear el código	Prettier: SonarQube y PMD analizan, no formatean.
2026	Tipo de fichero para pruebas unitarias del cliente	Ficheros .spec.

La lectura de conjunto no deja lugar a dudas: es el tema más práctico del temario. Se aprueba habiendo usado Git y reconociendo los nombres de las herramientas, y se suspende estudiándolo como si fuera teoría de la ingeniería del software.