diff --git a/src/main/resources/temas/bloque3/B3T9.md b/src/main/resources/temas/bloque3/B3T9.md index e3d3657..c207ffd 100644 --- a/src/main/resources/temas/bloque3/B3T9.md +++ b/src/main/resources/temas/bloque3/B3T9.md @@ -12,15 +12,22 @@ - Locales, centralizados (SVN), distribuidos (Git) **Metodologías de desarrollo** -- Tradicionales: cascada, espiral +- Tradicionales: cascada, modelo en V, espiral, RUP - Ágiles: Scrum, Kanban, XP **Pruebas de software** -- Unitarias, integración, sistema, aceptación -- Caja blanca vs. caja negra +- Unitarias, integración, sistema, aceptación (UAT) +- Caja blanca vs. caja negra vs. caja gris +- Pirámide de pruebas: unitarias → integración → E2E +- TDD (Red → Green → Refactor) y BDD (Given-When-Then) **Plataformas colaborativas** -- GitHub, GitLab, Bitbucket +- GitHub (Microsoft, 2018), GitLab (on-premise), Bitbucket (Atlassian) + +**Conceptos transversales** +- CI/CD: integración, entrega y despliegue continuos +- SemVer: MAJOR.MINOR.PATCH +- .gitignore, hooks, protección de ramas, Pull Request --- @@ -28,60 +35,97 @@ ## 2.1 Qué es un repositorio -Un **repositorio** (*repository* o *repo*) es un almacén centralizado o distribuido donde se guarda el código fuente y el historial de todos los cambios realizados sobre él. +Un **repositorio** (*repository* o *repo*) es un almacén centralizado o distribuido donde se guarda el código fuente y el historial completo de todos los cambios realizados sobre él. + +Un repositorio no solo almacena el estado actual del código: actúa como una **base de datos de cambios** que permite conocer quién modificó qué, cuándo y por qué. Esto hace posible colaborar en equipo, revertir errores y gestionar versiones paralelas. Contiene: -- El **árbol de trabajo** (*working tree*): los archivos actuales. -- El **historial de commits**: cada instantánea del proyecto. -- Las **ramas** (*branches*): líneas de desarrollo paralelas. -- Las **etiquetas** (*tags*): marcas en commits concretos (versiones). +- El **árbol de trabajo** (*working tree*): los archivos actuales del proyecto. +- El **historial de commits**: cada instantánea del proyecto en el tiempo. +- Las **ramas** (*branches*): líneas de desarrollo paralelas e independientes. +- Las **etiquetas** (*tags*): marcas inmutables en commits concretos (versiones de release). - Los **metadatos** del sistema de control de versiones. ## 2.2 Tipos de repositorios ### Repositorio local - Existe solo en el equipo del desarrollador. -- Sin colaboración directa. +- Sin historial compartido ni colaboración directa. +- Adecuado solo para proyectos personales sin colaboradores. ### Repositorio centralizado (VCS centralizado) -- Un único servidor central almacena el historial. -- Los desarrolladores hacen *checkout* del servidor. -- Ejemplos: **SVN (Subversion)**, CVS. -- Desventaja: punto único de fallo; sin acceso hay sin historial. +- Un único servidor central almacena todo el historial. +- Los desarrolladores hacen *checkout* del servidor para obtener los archivos; solo guardan los ficheros en local, **no el historial**. +- Ejemplos: **SVN (Subversion)**, **CVS (Concurrent Versions System)**. +- **Desventaja principal:** punto único de fallo; si el servidor no está disponible, nadie puede consultar el historial ni confirmar cambios. ### Repositorio distribuido (DVCS) -- Cada desarrollador tiene una copia completa del repositorio (historial incluido). -- Se puede trabajar sin conexión. -- Ejemplos: **Git**, Mercurial. -- Ventaja: redundancia, velocidad, flujos de trabajo flexibles. +- Cada desarrollador tiene una **copia completa del repositorio**, incluyendo todo el historial. +- Se puede trabajar sin conexión al servidor remoto. +- Ejemplos: **Git**, **Mercurial**. +- **Ventajas:** sin punto único de fallo, operaciones locales muy rápidas, flujos de trabajo muy flexibles. ## 2.3 Estructura de un repositorio Git +El directorio `.git/` es el núcleo del repositorio. La estructura completa es: + ``` proyecto/ ├── .git/ ← Directorio oculto con todos los metadatos de Git -│ ├── HEAD ← Apunta a la rama actual -│ ├── config ← Configuración del repositorio -│ ├── objects/ ← Objetos (blobs, trees, commits, tags) +│ ├── HEAD ← Referencia a la rama activa actualmente +│ ├── config ← Configuración local del repositorio +│ ├── hooks/ ← Scripts ejecutados en eventos (pre-commit, post-merge…) +│ ├── objects/ ← Almacén de objetos: blobs, trees, commits, tags +│ │ └── pack/ ← Objetos empaquetados (packfiles) para mayor eficiencia │ ├── refs/ │ │ ├── heads/ ← Ramas locales +│ │ ├── remotes/ ← Ramas remotas (origin/main, origin/develop…) │ │ └── tags/ ← Etiquetas │ └── index ← Área de staging (índice) ├── src/ ├── tests/ +├── .gitignore ← Patrones de archivos excluidos del control de versiones └── README.md ``` +### El archivo .gitignore + +El archivo `.gitignore` define qué archivos y directorios debe ignorar Git. Es una práctica fundamental para excluir del repositorio lo que no debe versionarse: + +``` +# Dependencias externas +node_modules/ +target/ +build/ + +# Entornos y configuraciones locales +.env +*.env.local +application-local.properties + +# Compilados y ejecutables +*.class +*.jar +*.war + +# Carpetas de IDEs +.idea/ +.vscode/ +*.iml +``` + ## 2.4 Objetos internos de Git +Git es un **sistema de almacenamiento de contenido direccionable**: cada objeto se identifica de forma única por el **hash SHA-1** (40 caracteres hexadecimales) calculado sobre su contenido. Si el contenido cambia, el hash cambia, lo que garantiza la **integridad** del historial. + | Objeto | Descripción | |--------|-------------| -| **blob** | Contenido de un archivo | -| **tree** | Directorio (lista de blobs y otros trees) | -| **commit** | Instantánea + autor + mensaje + referencia al commit padre | -| **tag** | Referencia con nombre a un commit concreto | +| **blob** | Contenido bruto de un archivo (sin nombre ni ruta, solo contenido) | +| **tree** | Directorio: lista de blobs y otros trees con sus nombres y permisos de acceso | +| **commit** | Instantánea + autor + fecha + mensaje + referencia al commit padre (o padres en un merge) | +| **tag** | Referencia con nombre a un commit concreto; los tags anotados incluyen autor, fecha y mensaje propio | -Todos los objetos se identifican por su **hash SHA-1** (40 caracteres hexadecimales). +Git modela el historial como un **grafo acíclico dirigido (DAG)** de commits, donde cada commit apunta hacia atrás a su padre o padres. Esto garantiza que el historial sea inmutable e íntegro. Con el tiempo, los objetos sueltos se agrupan en **packfiles** comprimidos para ahorrar espacio en disco. --- @@ -99,77 +143,135 @@ Working Directory → Staging Area (index) → Repositorio local → Repositorio | **Working directory** | Archivos que ves y editas | | **Staging area** | Archivos preparados para el próximo commit | | **Repositorio local** | Historial de commits almacenado en `.git/` | -| **Repositorio remoto** | Copia en servidor (GitHub, GitLab…) | +| **Repositorio remoto** | Copia alojada en un servidor (GitHub, GitLab…) | + +El **staging area** es el elemento diferencial de Git: permite seleccionar qué cambios concretos incluir en cada commit, obteniendo un historial limpio y preciso sin necesidad de incluir todo lo modificado a la vez. ## 3.2 Comandos principales de Git ```bash # Configuración inicial -git config --global user.name "Nombre" +git config --global user.name "Nombre Apellido" git config --global user.email "email@ejemplo.com" +git config --global core.editor "code --wait" # editor por defecto # Iniciar repositorio -git init # nuevo repo local -git clone URL # clonar repo remoto +git init # nuevo repo local en el directorio actual +git clone URL # clonar repo remoto (crea directorio local) +git clone URL mi-carpeta # clonar en un directorio con nombre concreto # Ciclo básico git status # ver estado de los archivos -git add archivo.py # añadir al staging -git add . # añadir todo -git commit -m "mensaje" # crear commit -git log --oneline --graph # ver historial +git diff # cambios en working directory vs staging +git diff --staged # cambios en staging vs último commit +git add archivo.py # añadir un archivo concreto al staging +git add . # añadir todos los cambios al staging +git add -p # añadir de forma interactiva (por fragmentos) +git commit -m "mensaje" # crear commit con mensaje en línea +git commit --amend # modificar el último commit (mensaje o contenido) +git log --oneline --graph # historial compacto con grafo de ramas # Ramas -git branch # listar ramas -git branch nueva-rama # crear rama -git checkout nueva-rama # cambiar a rama -git checkout -b nueva-rama # crear y cambiar -git merge otra-rama # fusionar rama -git branch -d rama # eliminar rama +git branch # listar ramas locales +git branch -a # listar ramas locales y remotas +git branch nueva-rama # crear rama en el commit actual +git checkout nueva-rama # cambiar a una rama existente +git checkout -b nueva-rama # crear rama y cambiar a ella (shortcut) +git switch nueva-rama # cambiar de rama (comando moderno) +git switch -c nueva-rama # crear y cambiar (comando moderno) +git merge otra-rama # fusionar otra-rama en la rama activa +git branch -d rama # eliminar rama (solo si ya está mergeada) +git branch -D rama # eliminar rama forzosamente # Repositorio remoto -git remote add origin URL # vincular remoto -git push origin main # subir cambios -git pull origin main # bajar cambios -git fetch origin # descargar sin fusionar +git remote -v # ver remotos configurados +git remote add origin URL # vincular repositorio remoto como 'origin' +git push origin main # subir rama main al remoto +git push -u origin main # subir y establecer upstream (tracking) +git pull origin main # descargar y fusionar cambios del remoto +git fetch origin # descargar cambios sin fusionar # Etiquetas -git tag v1.0.0 # etiqueta ligera -git tag -a v1.0.0 -m "msg" # etiqueta anotada -git push origin --tags # subir etiquetas +git tag # listar etiquetas +git tag v1.0.0 # etiqueta ligera en el commit actual +git tag -a v1.0.0 -m "Versión estable 1.0.0" # etiqueta anotada +git push origin --tags # subir todas las etiquetas al remoto +git push origin v1.0.0 # subir una etiqueta concreta -# Deshacer -git revert HASH # crear commit que deshace otro -git reset --soft HEAD~1 # deshacer commit, mantener staging -git reset --hard HEAD~1 # deshacer commit y cambios (¡destructivo!) -git stash # guardar cambios sin commit -git stash pop # recuperar stash +# Deshacer y reescribir historial +git revert HASH # crear nuevo commit que deshace el commit indicado +git reset --soft HEAD~1 # deshacer último commit, mantener cambios en staging +git reset --mixed HEAD~1 # deshacer último commit, pasar cambios a working dir +git reset --hard HEAD~1 # deshacer último commit y descartar cambios (¡destructivo!) +git stash # guardar cambios no commiteados en una pila temporal +git stash list # listar todos los stashes guardados +git stash pop # recuperar y eliminar el último stash +git stash apply stash@{2} # aplicar un stash concreto sin eliminarlo ``` ## 3.3 Flujos de trabajo (workflows) con Git ### Gitflow -Workflow estructurado con ramas fijas: -- `main` – código en producción. -- `develop` – integración de features. -- `feature/*` – nuevas funcionalidades. -- `release/*` – preparación de versión. -- `hotfix/*` – correcciones urgentes en producción. +Workflow estructurado con ramas de larga duración para proyectos con ciclos de release bien definidos: +- `main` – código en producción, siempre estable y etiquetado. +- `develop` – rama de integración de features. +- `feature/*` – nuevas funcionalidades (se crean desde `develop`, se mergean a `develop`). +- `release/*` – preparación de versión (correcciones menores, bump de versión). +- `hotfix/*` – correcciones urgentes en producción (se crean desde `main`, se mergean a `main` y `develop`). -### GitHub Flow / Trunk-Based -- Solo `main` + ramas de feature. -- Pull Request → revisión → merge a main. -- Más sencillo, orientado a despliegue continuo. +### GitHub Flow / Trunk-Based Development +- Solo existe `main` como rama principal de larga duración. +- Las ramas de feature son de corta duración (horas o días). +- Pull Request → revisión de código → CI en verde → merge a main. +- Ideal para despliegue continuo: cada merge a main puede activar un despliegue a producción. ### Resolución de conflictos -Ocurre cuando dos ramas modifican las mismas líneas. Git marca el conflicto y el desarrollador debe resolverlo manualmente: +Un conflicto ocurre cuando dos ramas modifican las mismas líneas de un archivo. Git marca el conflicto y el desarrollador debe resolverlo manualmente: ``` <<<<<<< HEAD - código de la rama actual + código de la rama activa actualmente ======= - código de la rama a fusionar + código de la rama que se está fusionando >>>>>>> otra-rama ``` +Tras resolver, se eliminan los marcadores y se confirma un commit de resolución. + +## 3.4 Merge vs. Rebase + +| Operación | Resultado en el historial | Cuándo usarla | +|-----------|--------------------------|---------------| +| **merge** | Crea un commit de merge; conserva el historial tal como ocurrió | Para integrar ramas de larga duración; preserva el historial real | +| **rebase** | Reaplica los commits sobre una nueva base; historial lineal | Para limpiar el historial de una feature branch antes del merge | +| **merge --squash** | Comprime todos los commits de la rama en uno solo | Para mantener `main` con un historial muy limpio | + +> **Regla de oro del rebase:** nunca se deben rebasear commits que ya han sido publicados en un repositorio compartido, ya que reescribe el historial y puede romper el trabajo de otros desarrolladores. + +## 3.5 Comandos avanzados de Git + +```bash +# Rebase +git rebase main # reaplica los commits de la rama actual sobre main +git rebase -i HEAD~3 # rebase interactivo de los últimos 3 commits + # (permite squash, reorder, editar mensajes, drop) + +# Cherry-pick: aplica un commit concreto de otra rama a la rama activa +git cherry-pick HASH # aplica el commit indicado +git cherry-pick A..B # aplica el rango de commits de A a B + +# Bisect: búsqueda binaria para encontrar el commit que introdujo un bug +git bisect start +git bisect bad # el commit actual contiene el bug +git bisect good v1.0.0 # este commit funcionaba correctamente +# Git hace checkout de commits intermedios hasta localizar el culpable +git bisect reset # terminar la sesión de bisect + +# Blame: ver quién modificó cada línea de un archivo y en qué commit +git blame archivo.py + +# Reflog: historial local de movimientos de HEAD (para recuperar commits perdidos) +git reflog +git checkout HEAD@{5} # ir a un estado anterior del repositorio +``` --- @@ -180,18 +282,36 @@ Ocurre cuando dos ramas modifican las mismas líneas. Git marca el conflicto y e ### Herramientas de generación | Herramienta | Descripción | |-------------|-------------| -| **Scaffolding** | Genera estructura básica del proyecto (Rails, Angular CLI, Spring Initializr) | -| **ORM / generadores de mapeo** | Genera clases desde el esquema de BD (Hibernate, Entity Framework) | -| **Generadores de API** | Genera código desde especificación OpenAPI/Swagger | -| **Compiladores / transpiladores** | TypeScript → JavaScript, SASS → CSS | -| **Plantillas (templates)** | Freemarker, Thymeleaf, Mustache | +| **Scaffolding** | Genera estructura inicial del proyecto (Angular CLI, Spring Initializr, create-react-app) | +| **ORM / generadores de mapeo** | Genera clases desde el esquema de BD (Hibernate, Entity Framework, JPA) | +| **Generadores de API** | Genera código cliente y servidor desde especificación OpenAPI/Swagger | +| **Compiladores / transpiladores** | TypeScript → JavaScript, SASS/LESS → CSS, Kotlin → JVM bytecode | +| **Plantillas (templates)** | Freemarker, Thymeleaf, Mustache, Jinja2 | +| **Linters y formatters** | ESLint, Prettier, Checkstyle, Black; garantizan calidad y estilo homogéneo | ### Integración Continua (CI) y Entrega Continua (CD) -- **CI (Continuous Integration):** los cambios se integran y construyen automáticamente con cada push. -- **CD (Continuous Delivery):** el software puede desplegarse en cualquier momento. -- **CD (Continuous Deployment):** cada cambio validado se despliega automáticamente. +- **CI (Continuous Integration):** cada push activa automáticamente la compilación, análisis de código y ejecución de pruebas. Detecta errores de integración en minutos. +- **CD (Continuous Delivery):** el artefacto resultado está siempre listo para desplegar; el despliegue final puede requerir aprobación manual. +- **CD (Continuous Deployment):** cada cambio validado se despliega automáticamente en producción sin intervención humana. -Herramientas: **Jenkins**, **GitHub Actions**, **GitLab CI/CD**, Travis CI. +Herramientas: **Jenkins**, **GitHub Actions**, **GitLab CI/CD**, **Azure DevOps**, Travis CI, CircleCI. + +### Fases típicas de un pipeline CI/CD + +``` +Commit → Build → Static Analysis → Unit Tests → Integration Tests → Security Scan + → Package → Deploy Staging → Acceptance Tests → Deploy Production +``` + +| Fase | Herramientas habituales | +|------|------------------------| +| Build | Maven, Gradle, npm, Make | +| Static analysis | SonarQube, ESLint, Checkstyle | +| Unit tests | JUnit, pytest, Jest | +| Integration tests | TestContainers, Postman/Newman | +| Security scan | OWASP Dependency-Check, Snyk, Trivy | +| Package | Docker, JAR/WAR | +| Deploy | Kubernetes, Ansible, Terraform | ## 4.2 Documentación del código @@ -201,8 +321,10 @@ Herramientas: **Jenkins**, **GitHub Actions**, **GitLab CI/CD**, Travis CI. * Calcula el área de un círculo. * * @param radio El radio del círculo (debe ser positivo). - * @return El área calculada. + * @return El área calculada en unidades cuadradas. * @throws IllegalArgumentException si el radio es negativo. + * @since 1.0 + * @see Math#PI */ public double calcularArea(double radio) { if (radio < 0) throw new IllegalArgumentException("Radio negativo"); @@ -219,21 +341,44 @@ def calcular_area(radio: float) -> float: Args: radio: El radio del círculo (debe ser positivo). Returns: - El área calculada. + El área calculada en unidades cuadradas. Raises: ValueError: Si el radio es negativo. + Example: + >>> calcular_area(5.0) + 78.53981633974483 """ ``` ### Herramientas de documentación -| Herramienta | Lenguaje | -|-------------|---------| -| **Javadoc** | Java | -| **Sphinx / pdoc** | Python | -| **JSDoc** | JavaScript | -| **Doxygen** | C, C++, y otros | -| **Swagger / OpenAPI** | APIs REST | -| **ReadTheDocs** | Publicación online | +| Herramienta | Lenguaje / Ámbito | +|-------------|------------------| +| **Javadoc** | Java – genera HTML desde comentarios `/** */` | +| **Sphinx / pdoc** | Python – admite reStructuredText y Markdown | +| **JSDoc** | JavaScript / TypeScript | +| **Doxygen** | C, C++, y otros lenguajes | +| **Swagger / OpenAPI** | APIs REST – documentación interactiva | +| **ReadTheDocs** | Publicación de documentación técnica online | +| **MkDocs / AsciiDoc** | Documentación de proyectos en general | + +## 4.3 Versionado semántico (SemVer) + +El versionado semántico, definido en **semver.org**, establece un formato `MAJOR.MINOR.PATCH`: + +| Campo | Cuándo se incrementa | +|-------|---------------------| +| **MAJOR** | Cambio incompatible con la API anterior (*breaking change*) | +| **MINOR** | Nueva funcionalidad compatible hacia atrás | +| **PATCH** | Corrección de errores compatible hacia atrás | + +Ejemplos: +- `1.0.0` → primera versión estable. +- `1.1.0` → nueva funcionalidad sin romper nada. +- `1.1.1` → corrección de un bug. +- `2.0.0` → cambio de API incompatible con la versión 1.x. +- `1.0.0-beta.1` → pre-release (alpha, beta, rc). + +El **CHANGELOG.md** documenta qué cambia entre versiones. Su mantenimiento es una buena práctica fundamental en proyectos open source y corporativos. --- @@ -242,65 +387,98 @@ def calcular_area(radio: float) -> float: ## 5.1 Metodologías tradicionales (predictivas) ### Cascada (Waterfall) -Fases secuenciales, sin retroceso entre ellas: -1. Requisitos → 2. Diseño → 3. Implementación → 4. Pruebas → 5. Despliegue → 6. Mantenimiento +Fases secuenciales y sin solapamiento. Cada fase debe completarse antes de iniciar la siguiente: -**Ventajas:** simple, bien documentado, adecuado para proyectos estables. -**Inconvenientes:** inflexible ante cambios de requisitos; los errores se descubren tarde. +1. Requisitos → 2. Análisis → 3. Diseño → 4. Implementación → 5. Pruebas → 6. Despliegue → 7. Mantenimiento + +**Ventajas:** sencilla de gestionar, documentación exhaustiva, adecuada para proyectos con requisitos estables y bien conocidos desde el inicio. +**Inconvenientes:** extremadamente inflexible ante cambios; los errores de análisis se descubren en la fase de pruebas, lo que los hace muy costosos de corregir. ### Modelo en V -Extiende la cascada asociando cada fase de desarrollo con una fase de pruebas: -- Diseño de sistema ↔ Pruebas de sistema -- Diseño de componentes ↔ Pruebas de integración -- Codificación ↔ Pruebas unitarias +Extiende la cascada asociando simétricamente cada fase de desarrollo con su fase de pruebas correspondiente. Las pruebas se planifican en paralelo al diseño, no al final: -### Modelo en Espiral (Boehm) -Combina iteración con análisis de riesgos en cada ciclo. -Cada espiral: Planificación → Análisis de riesgos → Ingeniería → Evaluación. +``` +Requisitos del sistema ←→ Pruebas de aceptación (UAT) + Diseño del sistema ←→ Pruebas del sistema + Diseño de componentes ←→ Pruebas de integración + Codificación → Pruebas unitarias +``` + +**Ventaja clave frente a cascada:** las pruebas se diseñan desde el principio, no como una actividad de última hora. + +### Modelo en Espiral (Boehm, 1986) +Combina iteración con **análisis de riesgos** en cada ciclo. Cada vuelta de la espiral consta de cuatro cuadrantes: +1. **Planificación:** objetivos, restricciones, alternativas. +2. **Análisis de riesgos:** identificación y mitigación de riesgos técnicos. +3. **Ingeniería:** desarrollo y pruebas del incremento del ciclo. +4. **Evaluación del cliente:** revisión del incremento y planificación de la siguiente espiral. + +Adecuado para proyectos grandes con incertidumbre significativa. ### RUP (Rational Unified Process) -- Iterativo e incremental. -- 4 fases: Inicio, Elaboración, Construcción, Transición. -- Usa artefactos UML. +- Iterativo, incremental y orientado a la arquitectura. +- **4 fases:** Inicio (*Inception*), Elaboración (*Elaboration*), Construcción (*Construction*), Transición (*Transition*). +- Cada fase contiene varias iteraciones con entregables definidos. +- Usa **artefactos UML** (diagramas de clases, secuencia, casos de uso, etc.). +- Muy orientado a proyectos empresariales grandes y complejos. ## 5.2 Metodologías ágiles -El **Manifiesto Ágil (2001)** establece 4 valores: -- Individuos e interacciones > procesos y herramientas. -- Software funcionando > documentación exhaustiva. -- Colaboración con el cliente > negociación de contratos. -- Respuesta al cambio > seguir un plan. +El **Manifiesto Ágil (2001)** fue firmado por 17 expertos y establece **4 valores** y 12 principios: + +- Individuos e interacciones **por encima de** procesos y herramientas. +- Software funcionando **por encima de** documentación exhaustiva. +- Colaboración con el cliente **por encima de** negociación de contratos. +- Respuesta al cambio **por encima de** seguir un plan. + +> Importante: el Manifiesto no dice que los elementos de la derecha no tengan valor; dice que los de la izquierda se valoran **más**. ### Scrum | Elemento | Descripción | |----------|-------------| -| **Sprint** | Iteración de 1-4 semanas con entregable funcional | -| **Product Backlog** | Lista priorizada de funcionalidades | -| **Sprint Backlog** | Tareas del sprint actual | -| **Daily Scrum** | Reunión diaria de 15 min (¿qué hice? ¿qué haré? ¿impedimentos?) | -| **Sprint Review** | Demostración del producto al cliente al final del sprint | -| **Sprint Retrospective** | Mejora del proceso del equipo | -| **Product Owner** | Representa al cliente, prioriza el backlog | -| **Scrum Master** | Facilita el proceso, elimina impedimentos | -| **Development Team** | Equipo autogestionado que desarrolla el producto | +| **Sprint** | Iteración de 1-4 semanas con entregable potencialmente funcional | +| **Product Backlog** | Lista priorizada de todas las funcionalidades del producto | +| **Sprint Backlog** | Tareas del sprint actual seleccionadas del Product Backlog | +| **Incremento** | Resultado de cada sprint: software funcional que cumple la DoD | +| **Sprint Planning** | Reunión de inicio del sprint: selección y descomposición de tareas | +| **Daily Scrum** | Reunión diaria de 15 min: ¿qué hice ayer? ¿qué haré hoy? ¿impedimentos? | +| **Sprint Review** | Demostración del incremento al cliente al final del sprint | +| **Sprint Retrospective** | Reflexión del equipo sobre el proceso: qué mejorar en el siguiente sprint | +| **Product Owner (PO)** | Representa al cliente; gestiona y prioriza el Product Backlog | +| **Scrum Master (SM)** | Facilita el proceso, elimina impedimentos, protege al equipo | +| **Development Team** | Equipo autogestionado y multifuncional que desarrolla el producto | + +**Métricas de Scrum:** +- **Velocity:** story points completados por sprint; mide la capacidad del equipo y sirve para prever entregas. +- **Burn-down chart:** gráfica que muestra el trabajo restante en el sprint día a día; permite detectar desviaciones. +- **Definition of Done (DoD):** criterios acordados que debe cumplir un incremento para considerarse terminado. +- **Definition of Ready (DoR):** criterios que debe cumplir un ítem del backlog para poder entrar en un sprint. ### Kanban -- Visualización del trabajo en un tablero con columnas (Pendiente / En progreso / Hecho). -- Límite de trabajo en curso (WIP limits). -- Flujo continuo sin sprints fijos. +- Visualización del trabajo en un **tablero** con columnas que representan los estados: Pendiente / En progreso / Revisión / Hecho. +- **Límite WIP (Work In Progress):** número máximo de tareas simultáneas por columna; reduce el multitasking y mejora el flujo. +- Sin sprints fijos: el trabajo fluye de forma continua. +- Métricas clave: **lead time** (tiempo desde que se solicita hasta que se entrega) y **cycle time** (tiempo desde que se empieza hasta que se entrega). +- Muy adecuado para equipos de mantenimiento, soporte y operaciones. ### XP (Extreme Programming) -Prácticas técnicas intensas: **TDD** (Test-Driven Development), **pair programming**, integración continua, refactoring, releases frecuentes. +Conjunto de prácticas técnicas intensas orientadas a la calidad del código: +- **TDD** (Test-Driven Development): los tests se escriben antes que el código. +- **Pair programming:** dos desarrolladores comparten pantalla y teclado. +- **Integración continua:** los cambios se integran varias veces al día. +- **Refactoring continuo:** el código se mejora constantemente sin añadir funcionalidad. +- **Diseño simple y YAGNI** (You Ain't Gonna Need It): no implementar lo que no se necesita aún. -### Comparativa +### Comparativa de metodologías -| | Cascada | Scrum | Kanban | -|-|---------|-------|--------| -| Plan | Fijo | Iterativo (sprints) | Continuo | -| Cambios | Difíciles | Cada sprint | En cualquier momento | -| Documentación | Extensa | Mínima necesaria | Mínima | -| Adecuado para | Requisitos claros y estables | Proyectos medianos/grandes con cambios | Mantenimiento, flujo continuo | +| | Cascada | Modelo en V | Scrum | Kanban | XP | +|-|---------|-------------|-------|--------|----| +| Planificación | Fija al inicio | Fija al inicio | Por sprint | Continua | Por iteración | +| Cambios | Muy difíciles | Muy difíciles | Cada sprint | En cualquier momento | Bienvenidos | +| Documentación | Extensa | Extensa | Mínima necesaria | Mínima | Mínima | +| Pruebas | Al final | Paralelas al diseño | Continuas | Continuas | Antes del código (TDD) | +| Adecuado para | Requisitos estables | Sistemas críticos | Proyectos con cambios | Mantenimiento / flujo | Equipos pequeños, alta calidad técnica | --- @@ -308,70 +486,121 @@ Prácticas técnicas intensas: **TDD** (Test-Driven Development), **pair program ## 6.1 Objetivos de las pruebas -- Detectar defectos (*bugs*). -- Verificar que el software cumple los requisitos. -- Validar que el software satisface las necesidades del usuario. +- Detectar defectos (*bugs*) lo antes posible. +- **Verificar** que el software está construido correctamente según el diseño. +- **Validar** que el software satisface las necesidades reales del usuario. - Aumentar la confianza en la calidad del producto. +- Proporcionar información para la toma de decisiones de release. -> **Verificación:** ¿estamos construyendo el sistema correctamente? -> **Validación:** ¿estamos construyendo el sistema correcto? +> **Verificación:** ¿estamos construyendo el sistema correctamente? (conforme a la especificación) +> **Validación:** ¿estamos construyendo el sistema correcto? (conforme a la necesidad del usuario) ## 6.2 Niveles de prueba ### Pruebas unitarias (Unit Testing) -- Prueban la **unidad mínima de código** (función, método, clase) de forma aislada. -- Se usan mocks/stubs para sustituir dependencias externas. -- Herramientas: **JUnit** (Java), **pytest** (Python), **Jest** (JavaScript). +- Prueban la **unidad mínima de código** (función, método, clase) de forma **aislada**. +- Se usan **mocks** y **stubs** para simular dependencias externas (bases de datos, servicios, APIs). +- Son las más rápidas de ejecutar y deben ser las más numerosas (base de la pirámide de pruebas). +- Herramientas: **JUnit 5** (Java), **Mockito** (mocks Java), **pytest** (Python), **Jest** (JavaScript). ### Pruebas de integración - Verifican que varios módulos o componentes funcionan correctamente **juntos**. -- Detectan problemas de interfaz entre módulos. +- Detectan problemas de interfaz entre módulos (formato de datos incorrecto, errores de comunicación). +- Herramientas: **TestContainers**, **Spring Boot Test**, **Postman/Newman**. ### Pruebas de sistema -- Prueban el sistema completo como un todo. -- Verifican el comportamiento frente a los requisitos funcionales y no funcionales. +- Prueban el **sistema completo integrado** en un entorno similar a producción. +- Verifican el comportamiento frente a los requisitos funcionales y no funcionales (rendimiento, seguridad, usabilidad). -### Pruebas de aceptación (UAT) -- Realizadas por el usuario final o cliente. -- Confirman que el sistema cumple los requisitos del negocio. -- Criterio de **DoD** (Definition of Done). +### Pruebas de aceptación (UAT – User Acceptance Testing) +- Realizadas por el **usuario final o cliente**. +- Confirman que el sistema cumple los requisitos del negocio y está listo para producción. +- Criterio de finalización: **DoD** (Definition of Done). +- En metodologías ágiles pueden automatizarse mediante **BDD** (Behavior-Driven Development). ## 6.3 Técnicas de prueba -### Caja negra (Black-box) +### Caja negra (Black-box Testing) - No se conoce (o no importa) la implementación interna. - Se prueba la **funcionalidad**: entradas → salidas esperadas. -- Técnicas: particiones de equivalencia, valores límite, tablas de decisión. +- Técnicas: particiones de equivalencia, valores límite, tablas de decisión, pruebas basadas en estado. -### Caja blanca (White-box / Glass-box) -- Se conoce y analiza el código fuente interno. -- Se persigue cubrir el máximo de rutas del código. -- Métricas: **cobertura de líneas**, **cobertura de ramas**, **cobertura de caminos**. -- Técnicas: recorrido de código, análisis de flujo de control. +### Caja blanca (White-box / Glass-box Testing) +- Se conoce y analiza el **código fuente interno**. +- Se persigue cubrir el máximo de rutas de ejecución del código. +- Métricas de cobertura: + - **Cobertura de líneas** (*line coverage*): % de líneas ejecutadas por los tests. + - **Cobertura de ramas** (*branch coverage*): % de ramas condicionales (if/else) cubiertas. + - **Cobertura de caminos** (*path coverage*): % de caminos posibles de ejecución (la más completa y costosa). +- Herramientas de cobertura: **JaCoCo** (Java), **Istanbul/nyc** (JavaScript), **coverage.py** (Python). -### Caja gris (Grey-box) -- Combinación de las dos anteriores. +### Caja gris (Grey-box Testing) +- Combinación de caja negra y caja blanca. +- Se conoce la estructura interna pero las pruebas se diseñan desde la perspectiva del usuario. ## 6.4 Tipos de pruebas por objetivo | Tipo | Qué verifica | |------|-------------| -| **Pruebas de regresión** | Que los cambios nuevos no rompen funcionalidad existente | -| **Pruebas de rendimiento / carga** | Comportamiento bajo condiciones de estrés | -| **Pruebas de seguridad (Pen Testing)** | Vulnerabilidades explotables | -| **Pruebas de usabilidad** | Facilidad de uso para el usuario | -| **Pruebas de accesibilidad** | Cumplimiento de estándares WCAG | -| **Smoke testing** | Verificación rápida de las funciones básicas | -| **Pruebas de humo / regresión automatizadas** | CI/CD pipeline | +| **Pruebas de regresión** | Que los cambios nuevos no rompen funcionalidad existente; se automatizan en CI | +| **Pruebas de rendimiento / carga** | Comportamiento bajo alta demanda (JMeter, Gatling, k6) | +| **Pruebas de estrés** | Comportamiento al superar la capacidad máxima del sistema | +| **Pruebas de seguridad (Pen Testing)** | Vulnerabilidades explotables (OWASP ZAP, Burp Suite) | +| **Pruebas de usabilidad** | Facilidad de uso para el usuario final | +| **Pruebas de accesibilidad** | Cumplimiento de estándares WCAG 2.1 | +| **Smoke testing** | Verificación rápida de que las funciones básicas del sistema arrancan correctamente | +| **Pruebas E2E (End-to-End)** | Flujo completo de usuario simulando el navegador (Selenium, Cypress, Playwright) | +| **Pruebas de mutación** | Modifican el código para verificar que los tests detectan los cambios (PIT, Stryker) | ## 6.5 TDD – Test Driven Development Ciclo **Red → Green → Refactor**: -1. **Red:** escribir un test que falle (la funcionalidad no existe aún). -2. **Green:** escribir el código mínimo para que el test pase. -3. **Refactor:** mejorar el código sin romper los tests. +1. **Red:** escribir un test que falle porque la funcionalidad no existe aún. Debe fallar por el motivo correcto. +2. **Green:** escribir el código **mínimo** para que el test pase. No importa que sea provisional. +3. **Refactor:** mejorar el diseño y la legibilidad del código sin que fallen los tests existentes. -**Ventajas:** código más simple, mejor diseño, alta cobertura de tests, documentación viva. +**Ventajas:** código más simple y desacoplado, alto nivel de cobertura desde el inicio, los tests actúan como documentación viva del comportamiento esperado. + +## 6.6 BDD – Behavior Driven Development + +Extensión del TDD que describe el comportamiento del sistema en **lenguaje natural** comprensible por el cliente, usando la sintaxis **Given-When-Then**: + +```gherkin +Feature: Autenticación de usuario + + Scenario: Login correcto + Given el usuario "ana" existe en el sistema + When intenta iniciar sesión con la contraseña correcta + Then debe acceder al panel de control + And ver el mensaje "Bienvenida, Ana" + + Scenario: Login con contraseña incorrecta + Given el usuario "ana" existe en el sistema + When intenta iniciar sesión con contraseña incorrecta + Then debe ver el mensaje "Credenciales incorrectas" +``` + +Herramientas: **Cucumber** (Java/Ruby/JavaScript), **Behave** (Python), **SpecFlow** (.NET). + +## 6.7 Pirámide de pruebas + +La pirámide de pruebas (Mike Cohn) define la proporción ideal de cada tipo de prueba: + +``` + /\ + / \ ← E2E / UI Tests (pocas, lentas, más frágiles) + /----\ + / \ ← Integration Tests (algunas, velocidad media) + /--------\ + / \ ← Unit Tests (muchas, rápidas, económicas) + /____________\ +``` + +- **Base (Unit):** mayor número, ejecución en milisegundos, coste bajo, aisladas de infraestructura. +- **Medio (Integration):** número moderado, requieren infraestructura, ejecución en segundos. +- **Cima (E2E / UI):** pocas, ejecución en minutos, más frágiles y caras de mantener. + +El antipatrón contrario se llama **pirámide invertida** o **cono de helado**: muchas pruebas de UI y pocas unitarias → suite lenta, frágil y cara. --- @@ -379,50 +608,60 @@ Ciclo **Red → Green → Refactor**: ## 7.1 GitHub -- Mayor plataforma de alojamiento de código Git basada en la web. -- **Pull Request (PR):** propuesta de cambios para revisión antes de mergear. -- **Issues:** gestión de tareas, bugs y mejoras. -- **GitHub Actions:** CI/CD integrado. -- **GitHub Pages:** alojamiento de sitios estáticos. -- **GitHub Copilot:** asistente de código basado en IA. -- Propiedad de Microsoft (desde 2018). +- Mayor plataforma mundial de alojamiento de código Git. +- Propiedad de **Microsoft** (adquirida en 2018). +- **Pull Request (PR):** mecanismo principal de colaboración; propuesta de cambios para revisión y discusión antes de mergear. +- **Issues:** gestión de tareas, bugs, mejoras y discusiones del proyecto. +- **GitHub Actions:** CI/CD integrado mediante ficheros YAML en `.github/workflows/`. +- **GitHub Pages:** alojamiento gratuito de sitios estáticos directamente desde el repositorio. +- **GitHub Copilot:** asistente de código basado en IA (Large Language Model). +- **GitHub Codespaces:** entorno de desarrollo completo en la nube, accesible desde el navegador. +- **GitHub Packages:** registro de artefactos (npm, Maven, Docker, etc.) integrado. +- **Dependabot:** bot que detecta dependencias vulnerables y propone actualizaciones automáticas. +- **CodeQL y Secret Scanning:** análisis de seguridad integrado en el repositorio. ## 7.2 GitLab -- Alternativa a GitHub, disponible también como instalación **on-premise**. -- Incluye CI/CD integrado muy completo. -- **GitLab CI/CD Pipelines** con fichero `.gitlab-ci.yml`. -- Gestión de proyectos, wikis, registros de contenedores Docker. -- Muy usado en la Administración Pública y entornos corporativos. +- Disponible como **SaaS** (gitlab.com) y como instalación **on-premise** en servidores propios. +- **CI/CD nativo** muy completo, configurado mediante el fichero `.gitlab-ci.yml`. +- Pipeline con stages (build, test, deploy) y environments (staging, production). +- **Container Registry** integrado para imágenes Docker. +- **GitLab Pages** para publicar documentación o sitios estáticos. +- Gestión de proyectos completa: wikis, tableros Kanban, milestones y epics. +- **Muy usado en la Administración Pública y entornos corporativos** por ofrecer control total del código mediante despliegue on-premise. ## 7.3 Bitbucket - Propiedad de **Atlassian** (misma empresa que Jira y Confluence). -- Integración nativa con Jira para gestión de proyectos. -- Compatible con Git y Mercurial (Mercurial fue descontinuado en 2020). -- Muy usado en entornos empresariales con ecosistema Atlassian. +- Integración nativa con **Jira** para vincular commits y Pull Requests a tareas del proyecto. +- **Bitbucket Pipelines:** CI/CD integrado, configurado con `bitbucket-pipelines.yml`. +- Compatible originalmente con Git y Mercurial (Mercurial fue descontinuado en 2020). +- Muy usado en entornos empresariales con el ecosistema Atlassian completo (Jira + Confluence + Bitbucket). -## 7.4 Otras herramientas +## 7.4 Otras herramientas del ciclo de vida | Herramienta | Tipo | Descripción | |-------------|------|-------------| -| **Jira** | Gestión de proyectos | Seguimiento de tareas, sprints, backlog | -| **Confluence** | Documentación | Wiki corporativa | -| **SonarQube** | Calidad de código | Análisis estático, detección de code smells | -| **Jenkins** | CI/CD | Servidor de automatización open-source | -| **Docker Hub** | Registro de contenedores | Imágenes Docker públicas y privadas | -| **Nexus / Artifactory** | Repositorios de artefactos | Maven, npm, Docker | +| **Jira** | Gestión de proyectos | Seguimiento de tareas, sprints, backlog, tableros Kanban/Scrum | +| **Confluence** | Documentación | Wiki corporativa integrada con Jira | +| **SonarQube** | Calidad de código | Análisis estático: code smells, cobertura, vulnerabilidades, duplicaciones | +| **Jenkins** | CI/CD | Servidor de automatización open-source; altamente extensible con plugins | +| **Docker Hub** | Registro de contenedores | Repositorio de imágenes Docker públicas y privadas | +| **Nexus / Artifactory** | Repositorios de artefactos | Maven, npm, Docker, Helm charts; proxy de dependencias externas | +| **Azure DevOps** | Suite DevOps completa | Repos, Boards, Pipelines, Artifacts, Test Plans; integrado con Azure | ## 7.5 Funcionalidades colaborativas clave | Función | Descripción | |---------|-------------| -| **Fork** | Copia independiente de un repositorio en tu cuenta | -| **Pull Request / Merge Request** | Solicitud para integrar cambios tras revisión | -| **Code review** | Revisión del código por otro desarrollador antes de mergear | -| **Branch protection** | Impide push directo a ramas protegidas (ej. main) | -| **Webhooks** | Notificaciones automáticas a servicios externos en cada evento | +| **Fork** | Copia independiente de un repositorio en tu cuenta; base del modelo open source | +| **Pull Request / Merge Request** | Solicitud para integrar cambios tras revisión y aprobación | +| **Code review** | Revisión del código por otro/s desarrolladores antes de mergear | +| **Branch protection** | Impide push directo a ramas protegidas (main, develop); obliga a PR y CI en verde | +| **Webhooks** | Notificaciones HTTP automáticas a servicios externos ante cada evento (push, PR…) | | **Wiki** | Documentación del proyecto integrada en la plataforma | +| **Milestones** | Agrupación de issues y PRs para seguimiento de versiones o fechas de entrega | +| **Labels / etiquetas** | Clasificación de issues y PRs: bug, enhancement, documentation… | --- @@ -430,22 +669,32 @@ Ciclo **Red → Green → Refactor**: | Concepto | Dato clave | |----------|-----------| -| DVCS | Sistema de control de versiones distribuido; cada clon tiene el historial completo | -| Git | DVCS más usado; crea repositorios con `.git/` | -| Commit | Instantánea del proyecto identificada por hash SHA-1 | -| Branch | Línea de desarrollo paralela; `main` es la rama principal | -| Merge | Fusión de dos ramas | -| Gitflow | Rama main + develop + feature/* + release/* + hotfix/* | -| CI/CD | Integración y entrega/despliegue continuo (Jenkins, GitHub Actions…) | -| Cascada | Fases secuenciales, sin retroceso | -| Scrum | Sprints, Product Owner, Scrum Master, Daily, Review, Retrospective | -| Kanban | Tablero visual, límites WIP, flujo continuo | -| TDD | Test → Código → Refactor (Red → Green → Refactor) | -| Prueba unitaria | Prueba la unidad mínima de forma aislada | -| Prueba de integración | Prueba varios módulos juntos | -| Prueba de aceptación (UAT) | La realiza el usuario final | -| Caja negra | Prueba funcionalidad sin ver el código | -| Caja blanca | Prueba conociendo la implementación interna | +| DVCS | Control de versiones distribuido; cada clon tiene el historial completo | +| Git | DVCS más usado; objetos SHA-1; historial en forma de DAG | +| Commit | Instantánea identificada por hash SHA-1; apunta a su(s) padre(s) | +| Branch | Línea de desarrollo paralela; `main` es la rama principal por convención | +| Merge vs Rebase | Merge preserva el historial real; Rebase lo lineariza (no rebasear commits publicados) | +| Gitflow | main + develop + feature/* + release/* + hotfix/* | +| .gitignore | Archivo que define qué ficheros excluir del control de versiones | +| CI/CD | CI: integración continua; CD: entrega/despliegue continuo (Jenkins, Actions, GitLab CI) | +| SemVer | MAJOR.MINOR.PATCH; MAJOR = breaking change, MINOR = nueva feature, PATCH = bugfix | +| Cascada | Fases secuenciales sin retroceso; errores se detectan tarde | +| Modelo en V | Cascada + pruebas planificadas simétricamente desde el diseño | +| Manifiesto Ágil | 2001; 4 valores: individuos, software funcionando, colaboración, respuesta al cambio | +| Scrum | Sprints 1-4 semanas; PO, SM, Dev Team; Planning, Daily, Review, Retrospective | +| Velocity | Story points completados por sprint; mide capacidad del equipo | +| DoD | Definition of Done: criterios de terminado de un incremento en Scrum | +| Kanban | Tablero visual, límites WIP; métricas: lead time y cycle time | +| TDD | Red → Green → Refactor; el test se escribe antes que el código | +| BDD | Given-When-Then; comportamiento en lenguaje natural; Cucumber, Behave | +| Prueba unitaria | Unidad mínima de forma aislada; mocks/stubs para dependencias | +| Prueba de integración | Varios módulos juntos; detecta problemas de interfaz | +| Prueba de aceptación (UAT) | La realiza el usuario final; criterio: DoD | +| Caja negra | Funcionalidad sin ver el código; particiones de equivalencia, valores límite | +| Caja blanca | Conociendo el código; cobertura de líneas, ramas y caminos | +| Pirámide de pruebas | Base: unitarias (muchas); medio: integración; cima: E2E (pocas) | | Pull Request | Propuesta de cambios para revisión antes de mergear | -| GitHub / GitLab / Bitbucket | Principales plataformas de desarrollo colaborativo | -| SonarQube | Análisis estático de calidad del código | +| GitHub | Plataforma más popular; Microsoft (2018); Actions para CI/CD; Copilot IA | +| GitLab | On-premise; muy usada en Administración Pública; CI/CD con .gitlab-ci.yml | +| Bitbucket | Atlassian; integración nativa con Jira | +| SonarQube | Análisis estático de calidad del código: code smells, cobertura, vulnerabilidades | diff --git a/src/main/resources/temas/bloque3/B3T9_audio.md b/src/main/resources/temas/bloque3/B3T9_audio.md index 31f4997..748cc0a 100644 --- a/src/main/resources/temas/bloque3/B3T9_audio.md +++ b/src/main/resources/temas/bloque3/B3T9_audio.md @@ -1,73 +1,462 @@ -## Bloque 3 Tema 9. Repositorios y control de versiones. Generación de código. Metodologías de desarrollo software. Pruebas del software. Plataformas de gestión del ciclo de vida software. +## Bloque 3 Tema 9. 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. -Este tema estudia las herramientas y metodologías que estructuran el ciclo de vida completo del desarrollo de software. +Este tema estudia las herramientas y metodologías que estructuran el ciclo de vida completo del desarrollo de software, desde el control de versiones hasta la entrega en producción. --- -## 1. Repositorios y control de versiones +## Apartado 1. Esquema introductorio -Un repositorio es el almacén centralizado que guarda el código fuente de un proyecto junto con el historial completo de todos los cambios realizados. Permite colaborar en equipo, revertir cambios, gestionar versiones paralelas mediante ramas y auditar quién modificó qué y cuándo. +Al inicio del documento encontraréis el esquema introductorio, que resume en pocas líneas todos los conceptos del tema. -Los tipos de repositorios son tres. El repositorio local existe únicamente en la máquina del desarrollador. El repositorio centralizado, como SVN o Subversion, tiene un único servidor central con todo el historial; su principal inconveniente es que si el servidor falla nadie puede trabajar. El repositorio distribuido, como Git y Mercurial, hace que cada desarrollador tenga una copia completa del repositorio con todo el historial; esto elimina el punto único de fallo y permite trabajar sin conexión. +El esquema agrupa los contenidos en cinco bloques. -Git es el sistema de control de versiones distribuido más utilizado. Su estructura interna se basa en objetos identificados por un hash SHA-1. Los tipos de objetos son el blob, que almacena el contenido de un fichero; el tree, que representa un directorio; el commit, que es una instantánea del proyecto con autor, mensaje y referencia al commit anterior; y el tag, que es una referencia nombrada a un commit concreto. +El primero trata el control de versiones, que es el sistema que registra los cambios en el código a lo largo del tiempo. -Las tres áreas de trabajo en Git son el directorio de trabajo donde se editan los ficheros, el área de staging o índice donde se preparan los cambios con el comando git add, y el repositorio local donde se guardan los commits con el comando git commit. El repositorio remoto es el cuarto nivel, al que se envían los commits con git push. +El segundo enumera los tipos de repositorios: locales, centralizados como SVN, y distribuidos como Git. -Los flujos de trabajo con Git más conocidos son Gitflow, que usa las ramas main, develop, feature, release y hotfix; y GitHub Flow o Trunk-Based Development, que es más sencillo y usa solo la rama principal con ramas de feature de corta duración y Pull Requests. +El tercero recoge las metodologías de desarrollo: las tradicionales, como cascada, modelo en V, espiral y RUP; y las ágiles, como Scrum, Kanban y XP. + +El cuarto bloque resume las pruebas de software: unitarias, de integración, de sistema y de aceptación; las técnicas de caja blanca, caja negra y caja gris; la pirámide de pruebas; y los enfoques TDD y BDD. + +El quinto bloque indica las plataformas colaborativas: GitHub, propiedad de Microsoft desde 2018; GitLab, que se puede instalar de forma privada en servidores propios; y Bitbucket, de la empresa Atlassian. + +El esquema también menciona tres conceptos transversales que aparecerán a lo largo de todo el tema: CI/CD para la integración y entrega continua, SemVer para el versionado semántico, y el archivo punto gitignore con los mecanismos de protección de ramas y Pull Requests. --- -## 2. Generación de código +## Apartado 2. Repositorios: concepto y estructura -El scaffolding o andamiaje es la generación automática de la estructura inicial de un proyecto mediante herramientas de línea de comandos. Los generadores ORM crean automáticamente el código de acceso a la base de datos a partir del modelo de datos. OpenAPI permite generar código cliente y servidor a partir de la especificación de una API REST. +### Apartado 2.1. Qué es un repositorio -La integración continua y el despliegue continuo, conocidos como CI/CD, automatizan el proceso de compilación, pruebas y despliegue. Las herramientas más conocidas son Jenkins, GitHub Actions y GitLab CI/CD. +Un repositorio, también llamado repo, es un almacén centralizado o distribuido donde se guarda el código fuente de un proyecto junto con el historial completo de todos los cambios realizados sobre él. -La documentación del código se genera automáticamente a partir de los comentarios del código fuente. Las herramientas principales son Javadoc para Java, JSDoc para JavaScript, Sphinx para Python y Swagger u OpenAPI para APIs REST. +Un repositorio no es simplemente una carpeta de archivos. Actúa como una base de datos de cambios que permite saber quién modificó qué, cuándo y por qué. Esto hace posible colaborar en equipo, revertir errores y gestionar versiones paralelas del mismo proyecto. + +Los elementos que contiene un repositorio son los siguientes. El árbol de trabajo, que son los archivos actuales del proyecto. El historial de commits, que son las instantáneas del proyecto a lo largo del tiempo. Las ramas, que son líneas de desarrollo paralelas e independientes. Las etiquetas, que son marcas inmutables en commits concretos para señalar versiones de release. Y los metadatos del sistema de control de versiones. --- -## 3. Metodologías de desarrollo software +### Apartado 2.2. Tipos de repositorios -Las metodologías de desarrollo son los marcos de trabajo que guían cómo se planifica, desarrolla y entrega el software. +Hay tres tipos de repositorios. -Las metodologías tradicionales o predictivas siguen un plan detallado desde el principio. La metodología en cascada o waterfall divide el proyecto en fases secuenciales: requisitos, análisis, diseño, implementación, pruebas y mantenimiento. Su principal inconveniente es la rigidez ante cambios. El modelo en V extiende la cascada asociando a cada fase de desarrollo una fase de pruebas correspondiente. El modelo espiral de Boehm es iterativo e incorpora el análisis de riesgos en cada iteración. La metodología RUP o Rational Unified Process divide el proyecto en cuatro fases: Inicio, Elaboración, Construcción y Transición, y usa UML para el modelado. +El primero es el repositorio local. Existe únicamente en el equipo del desarrollador, sin historial compartido ni colaboración posible. Solo es adecuado para proyectos personales sin colaboradores. -Las metodologías ágiles nacen del Manifiesto Ágil publicado en 2001. Sus cuatro valores son: los individuos y las interacciones sobre los procesos y las herramientas; el software funcionando sobre la documentación exhaustiva; la colaboración con el cliente sobre la negociación de contratos; y la respuesta ante el cambio sobre seguir un plan. +El segundo es el repositorio centralizado, que corresponde a los sistemas de control de versiones centralizados. En este modelo un único servidor central almacena todo el historial. Los desarrolladores hacen checkout del servidor para obtener los archivos, pero solo guardan localmente los ficheros del proyecto, no el historial. Los ejemplos más conocidos son SVN, que son las siglas de Subversion, y CVS, que son las siglas de Concurrent Versions System. La desventaja principal de este modelo es que representa un punto único de fallo: si el servidor no está disponible, nadie puede consultar el historial ni confirmar cambios. -Scrum es el framework ágil más usado. Se organiza en iteraciones llamadas Sprints de una a cuatro semanas. Los roles son el Product Owner, que gestiona el Product Backlog y prioriza los requisitos; el Scrum Master, que facilita el proceso y elimina impedimentos; y el Development Team, que desarrolla el producto. Los eventos son la Sprint Planning para planificar el Sprint, el Daily Scrum de quince minutos para sincronización diaria, la Sprint Review para demostrar el trabajo completado y la Retrospectiva para mejorar el proceso. - -Kanban es un sistema de gestión visual del trabajo basado en un tablero con columnas que representan los estados del trabajo, habitualmente Pendiente, En progreso y Hecho. El principio fundamental es limitar el trabajo en curso mediante los límites WIP o Work In Progress para evitar la acumulación de tareas y mejorar el flujo. - -XP o Extreme Programming aplica prácticas técnicas como el desarrollo guiado por pruebas o TDD, la programación en parejas, la integración continua y el refactoring constante. +El tercer tipo es el repositorio distribuido, que corresponde a los sistemas DVCS, siglas de Distributed Version Control System. En este modelo cada desarrollador tiene una copia completa del repositorio, incluyendo todo el historial. Se puede trabajar sin conexión al servidor remoto. Los ejemplos más conocidos son Git y Mercurial. Las ventajas son la ausencia de punto único de fallo, la velocidad de las operaciones locales y la gran flexibilidad en los flujos de trabajo. --- -## 4. Pruebas del software +### Apartado 2.3. Estructura de un repositorio Git -Las pruebas del software son el proceso de verificar que el sistema hace lo que debe hacer y detectar los defectos antes de que lleguen al usuario. +En el documento veréis el árbol de directorios que muestra la estructura de un repositorio Git. El elemento central es el directorio oculto punto git, que es el núcleo del repositorio y contiene toda la información del sistema de control de versiones. -Los niveles de pruebas son los siguientes. Las pruebas unitarias comprueban el funcionamiento de unidades mínimas de código como funciones o métodos de forma aislada usando objetos simulados llamados mocks o stubs. Las herramientas son JUnit para Java, pytest para Python y Jest para JavaScript. Las pruebas de integración verifican que varios módulos o componentes funcionan correctamente al trabajar juntos. Las pruebas de sistema comprueban el sistema completo integrado. Las pruebas de aceptación o UAT son realizadas por el usuario final para verificar que el sistema cumple los requisitos; su criterio de aprobación se define en el DoD o Definition of Done. +Dentro de ese directorio hay varios elementos importantes. El archivo HEAD contiene la referencia a la rama activa actualmente. El archivo config guarda la configuración local del repositorio. La carpeta hooks contiene scripts que se ejecutan automáticamente en determinados eventos como el pre-commit o el post-merge. La carpeta objects es el almacén de todos los objetos del repositorio: blobs, trees, commits y tags. Dentro de objects existe una subcarpeta pack con los objetos empaquetados para mayor eficiencia. La carpeta refs contiene las referencias: dentro de heads están las ramas locales, dentro de remotes están las ramas remotas como origin barra main, y dentro de tags están las etiquetas. El archivo index es el área de staging. -Los enfoques de prueba son los siguientes. La caja negra prueba la funcionalidad sin conocer la implementación interna, analizando las entradas y salidas. Las técnicas incluyen las particiones de equivalencia y los valores límite. La caja blanca prueba conociendo el código interno y busca maximizar la cobertura de líneas, ramas y caminos posibles. La caja gris combina ambos enfoques. +Fuera del directorio punto git, en la raíz del proyecto, también es fundamental el archivo punto gitignore. -Otros tipos de pruebas son las de regresión, que comprueban que los cambios no han roto funcionalidades existentes; las de rendimiento o carga, que verifican el comportamiento bajo alta demanda; las de seguridad o pen testing; las de usabilidad; las de accesibilidad; y el smoke testing, que son pruebas rápidas para verificar que el sistema arranca y funciona básicamente. - -El desarrollo guiado por pruebas o TDD sigue el ciclo Red, Green, Refactor: primero se escribe una prueba que falla, luego se escribe el código mínimo para que pase y finalmente se refactoriza el código manteniendo las pruebas en verde. +El archivo punto gitignore define los patrones de archivos y directorios que Git debe ignorar y no incluir en el control de versiones. En el bloque de código del documento podéis ver ejemplos habituales: la carpeta node_modules y las carpetas target y build con los compilados, los archivos de configuración local como punto env y application guion local punto properties, los ficheros compilados como los punto class, los jar y los war, y las carpetas de los IDEs como punto idea y punto vscode. --- -## 5. Plataformas de gestión del ciclo de vida +### Apartado 2.4. Objetos internos de Git -Las plataformas de alojamiento de repositorios más importantes son las siguientes. GitHub es la plataforma más popular a nivel mundial. Fue adquirida por Microsoft en 2018. Sus funcionalidades principales son los Pull Requests para revisar y fusionar código, los Issues para gestionar tareas y errores, GitHub Actions para CI/CD, GitHub Pages para publicar sitios web y GitHub Copilot para asistencia con inteligencia artificial. GitLab permite instalación en servidores propios llamada on-premise, tiene CI/CD nativo mediante ficheros .gitlab-ci.yml y es muy utilizada en las Administraciones Públicas por razones de soberanía y control. Bitbucket es la plataforma de Atlassian, integrada con Jira y Confluence. +Git es un sistema de almacenamiento de contenido direccionable. Esto significa que cada objeto se identifica de forma única mediante el hash SHA-1 de su contenido, que son cuarenta caracteres hexadecimales. Si el contenido cambia, el hash cambia, lo que garantiza la integridad del historial. -Otras herramientas del ciclo de vida son Jira para la gestión de proyectos y seguimiento de incidencias, Confluence para la documentación colaborativa, SonarQube para el análisis estático de calidad del código, Jenkins para la automatización de CI/CD y Docker Hub para el alojamiento de imágenes de contenedores. +La tabla que aparece en este apartado describe los cuatro tipos de objetos. El blob almacena el contenido bruto de un archivo, sin nombre ni ruta, solo el contenido. El tree representa un directorio y contiene una lista de blobs y otros trees con sus nombres y permisos de acceso. El commit es una instantánea del proyecto en un momento concreto, e incluye el autor, la fecha, el mensaje y la referencia al commit o commits padre. El tag es una referencia con nombre a un commit concreto, y en su versión anotada también incluye autor, fecha y mensaje propio. -Las funcionalidades colaborativas comunes a estas plataformas son el fork o copia del repositorio, el Pull Request o Merge Request para proponer cambios y revisarlos, el code review o revisión de código, la protección de ramas, los webhooks para integraciones y la wiki para documentación. +Git modela el historial como un grafo acíclico dirigido, abreviado como DAG, de commits, donde cada commit apunta hacia atrás a su padre o padres. Esto garantiza que el historial sea inmutable e íntegro. Con el tiempo, los objetos sueltos se agrupan en packfiles comprimidos para ahorrar espacio en disco. --- -## Miniresumen final del tema +## Apartado 3. Control de versiones con Git + +### Apartado 3.1. Áreas de trabajo en Git + +Mirad el esquema de las cuatro áreas de trabajo que aparece en el documento. Git divide el trabajo en cuatro zonas bien diferenciadas que forman un flujo secuencial. + +La primera zona es el directorio de trabajo, que son los archivos que veis, editáis y ejecutáis en vuestra máquina. + +La segunda zona es el área de staging, también llamada índice. Los archivos marcados para el próximo commit se preparan aquí mediante el comando git add. + +La tercera zona es el repositorio local, que es el historial de commits almacenado dentro del directorio punto git de vuestra máquina. Los commits se crean aquí mediante el comando git commit. + +La cuarta zona es el repositorio remoto, que es la copia alojada en un servidor como GitHub o GitLab. Los cambios se envían allí con git push. + +El staging area es el elemento diferencial de Git frente a otros sistemas: permite seleccionar qué cambios concretos incluir en cada commit, obteniendo un historial limpio y preciso sin necesidad de incluir todo lo modificado a la vez. + +La tabla del documento muestra estas cuatro áreas con su descripción resumida. + +--- + +### Apartado 3.2. Comandos principales de Git + +El bloque de código de este apartado contiene los comandos más importantes de Git, agrupados por categorías. Vamos a repasar las más importantes. + +El primer grupo es la configuración inicial. Los comandos git config con la opción global permiten establecer el nombre, el correo electrónico y el editor que Git usará por defecto en todos los repositorios de la máquina. + +El segundo grupo es el de inicio del repositorio. El comando git init crea un nuevo repositorio local en el directorio actual. El comando git clone seguido de una URL descarga un repositorio remoto completo, con todo su historial, en la máquina local. + +El tercer grupo es el ciclo básico. Git status muestra el estado actual de los archivos. Git diff muestra los cambios en el directorio de trabajo respecto al staging. Git diff con la opción staged muestra los cambios en staging respecto al último commit. Git add añade archivos al área de staging. Git add con punto añade todos los cambios a la vez. Git add con la opción p permite añadir cambios de forma interactiva fragmento a fragmento. Git commit con la opción m crea el commit con el mensaje indicado. Git commit con la opción amend permite modificar el último commit. Git log con las opciones oneline y graph muestra el historial de forma compacta con el grafo de ramas. + +El cuarto grupo es el de ramas. Git branch lista las ramas locales y con la opción a también las remotas. Git branch seguido de un nombre crea una nueva rama. Git checkout y el comando moderno git switch permiten cambiar entre ramas. Con la opción b o c respectivamente se crea la rama y se cambia a ella en un solo paso. Git merge fusiona una rama en la rama activa. Git branch con la opción d elimina una rama si ya ha sido mergeada. + +El quinto grupo es el de repositorio remoto. Git remote con la opción v muestra los remotos configurados. Git remote add origin seguido de la URL vincula el repositorio remoto. Git push envía cambios al remoto. Git pull los descarga y fusiona. Git fetch los descarga sin fusionar, permitiendo revisar los cambios antes de integrarlos. + +El sexto grupo es el de etiquetas. Git tag lista las etiquetas. Git tag seguido de la versión crea una etiqueta ligera. Git tag con la opción a crea una etiqueta anotada con mensaje. Git push origin con la opción tags sube todas las etiquetas al remoto. + +El séptimo grupo es el de deshacer. Git revert crea un nuevo commit que deshace el commit indicado, sin modificar el historial. Git reset con soft deshace el último commit pero mantiene los cambios en staging. Git reset con mixed los pasa al directorio de trabajo. Git reset con hard los descarta completamente, por lo que es un comando destructivo que debe usarse con precaución. Git stash guarda los cambios no commiteados en una pila temporal para recuperarlos después con git stash pop. + +--- + +### Apartado 3.3. Flujos de trabajo con Git + +El primero es Gitflow, que es un workflow estructurado con ramas de larga duración, diseñado para proyectos con ciclos de release bien definidos. Usa cinco tipos de ramas: main para el código en producción, siempre estable y etiquetado; develop para la integración de features; las ramas feature barra asterisco para las nuevas funcionalidades, que se crean desde develop y se mergean a develop; las ramas release barra asterisco para la preparación de versiones; y las ramas hotfix barra asterisco para las correcciones urgentes en producción, que se crean desde main y se mergean tanto a main como a develop. + +El segundo flujo es GitHub Flow o Trunk-Based Development. Es más sencillo: solo existe main como rama principal de larga duración, las ramas de feature son de corta duración, y el proceso es Pull Request, revisión de código, CI en verde, y merge a main. Es ideal para despliegue continuo porque cada merge a main puede activar automáticamente un despliegue a producción. + +En cuanto a la resolución de conflictos, un conflicto ocurre cuando dos ramas modifican las mismas líneas de un archivo. En el bloque de código del documento veréis los marcadores que Git inserta para señalar el conflicto: los signos de menor con HEAD marcan el inicio del código de la rama activa, los signos de igual separan las dos versiones, y los signos de mayor con el nombre de la otra rama cierran el bloque. El desarrollador debe editar el archivo para quedarse con la versión correcta, eliminar los marcadores y confirmar un commit de resolución. + +--- + +### Apartado 3.4. Merge versus Rebase + +La tabla de este apartado compara las tres formas principales de integrar cambios entre ramas. + +El merge crea un commit de merge que une las dos ramas y conserva el historial exactamente como ocurrió. Se usa para integrar ramas de larga duración o cuando se quiere preservar el historial real. + +El rebase mueve o reaplica los commits sobre una nueva base, obteniendo un historial lineal. Se usa para limpiar el historial de una feature branch antes del merge. + +El merge con la opción squash comprime todos los commits de la rama en uno solo al fusionar, lo que es muy útil para mantener main con un historial muy limpio. + +Hay una regla de oro que nunca debe olvidarse: nunca se deben rebasear commits que ya han sido publicados en un repositorio compartido, porque el rebase reescribe el historial y puede romper el trabajo de otros desarrolladores. + +--- + +### Apartado 3.5. Comandos avanzados de Git + +El bloque de código de este apartado muestra cuatro grupos de comandos avanzados. + +El primero es el rebase. El comando git rebase main reaplica los commits de la rama actual sobre la punta de main. El comando git rebase con la opción i permite un rebase interactivo que abre un editor para reorganizar, fusionar, editar o eliminar commits de los últimos N commits indicados. + +El segundo es cherry-pick, que aplica un commit concreto de otra rama a la rama activa sin necesidad de fusionar ramas completas. + +El tercero es bisect, que realiza una búsqueda binaria en el historial para encontrar el commit exacto que introdujo un bug. Se marca el commit actual como malo y un commit anterior conocido como bueno, y Git va haciendo checkout de commits intermedios hasta localizar el culpable. + +El cuarto es blame, que muestra línea a línea quién modificó cada parte de un archivo y en qué commit. + +También se menciona reflog, que es el historial local de todos los movimientos de HEAD, muy útil para recuperar commits o ramas que parecían perdidas. + +--- + +## Apartado 4. Generación de código y documentación + +### Apartado 4.1. Generación de código + +La primera tabla de este apartado recoge las principales herramientas de generación de código. + +El scaffolding o andamiaje genera automáticamente la estructura inicial de un proyecto. Ejemplos son Angular CLI, Spring Initializr y create-react-app. + +Los generadores ORM crean el código de acceso a la base de datos a partir del modelo de datos. Ejemplos son Hibernate, Entity Framework y JPA. + +Los generadores de API crean código cliente y servidor a partir de la especificación OpenAPI o Swagger. + +Los compiladores y transpiladores transforman código de un lenguaje a otro. Los más comunes son TypeScript a JavaScript, SASS y LESS a CSS, y Kotlin a bytecode de la JVM. + +Las plantillas o templates como Freemarker, Thymeleaf, Mustache y Jinja2 generan HTML u otros formatos a partir de datos dinámicos. + +Los linters y formatters como ESLint, Prettier, Checkstyle y Black garantizan calidad y estilo homogéneo en el código de todo el equipo. + +Respecto a CI/CD, hay que distinguir tres conceptos. La integración continua o CI consiste en que cada push activa automáticamente la compilación, el análisis de código y la ejecución de pruebas, detectando errores de integración en minutos. La entrega continua o Continuous Delivery implica que el artefacto resultante está siempre listo para desplegar, pero el despliegue final puede requerir aprobación manual. El despliegue continuo o Continuous Deployment va un paso más allá: cada cambio validado se despliega automáticamente en producción sin ninguna intervención humana. + +Las herramientas más conocidas son Jenkins, GitHub Actions, GitLab CI/CD, Azure DevOps, Travis CI y CircleCI. + +La segunda tabla y el bloque de diagrama que aparecen en el documento muestran las fases típicas de un pipeline CI/CD. El flujo va desde el commit inicial hasta el despliegue en producción, pasando por la compilación, el análisis estático, las pruebas unitarias, las pruebas de integración, el análisis de seguridad, el empaquetado del artefacto, el despliegue en staging, las pruebas de aceptación y finalmente el despliegue en producción. La tabla asociada muestra las herramientas habituales en cada fase: Maven o Gradle para la compilación, SonarQube o ESLint para el análisis estático, JUnit o Jest para las pruebas unitarias, TestContainers o Newman para las pruebas de integración, OWASP Dependency-Check o Snyk para el análisis de seguridad, Docker o JAR y WAR para el empaquetado, y Kubernetes, Ansible o Terraform para el despliegue. + +--- + +### Apartado 4.2. Documentación del código + +En el apartado de documentación del código aparecen dos bloques de código como ejemplo. + +El primer ejemplo muestra la sintaxis de Javadoc en Java. Los comentarios de documentación se escriben entre barra asterisco asterisco y asterisco barra. Las etiquetas más usadas son arroba param para documentar los parámetros de entrada, arroba return para el valor de retorno, arroba throws para las excepciones que puede lanzar, arroba since para la versión desde la que existe el método, y arroba see para referencias cruzadas. + +El segundo ejemplo muestra la sintaxis de docstrings en Python. La cadena de documentación se escribe entre comillas triples. Las secciones habituales son Args para los parámetros, Returns para el valor de retorno, Raises para las excepciones, y Example para mostrar un ejemplo de uso. + +La tabla de herramientas de documentación recoge las principales opciones. Javadoc genera HTML desde los comentarios de Java. Sphinx y pdoc son las herramientas para Python. JSDoc cubre JavaScript y TypeScript. Doxygen soporta C, C++ y otros lenguajes. Swagger y OpenAPI generan documentación interactiva para APIs REST. ReadTheDocs permite publicar la documentación técnica de forma online. MkDocs y AsciiDoc se usan para la documentación general de proyectos. + +--- + +### Apartado 4.3. Versionado semántico + +El versionado semántico, definido en la web semver punto org, establece un formato con tres números separados por puntos: MAJOR punto MINOR punto PATCH. + +La tabla de este apartado explica cuándo se incrementa cada campo. El campo MAJOR se incrementa cuando se introduce un cambio incompatible con la API anterior, lo que se llama un breaking change. El campo MINOR se incrementa cuando se añade nueva funcionalidad de forma compatible hacia atrás. El campo PATCH se incrementa cuando se corrige un error de forma compatible hacia atrás. + +Los ejemplos que aparecen a continuación ilustran esto. La versión 1.0.0 es la primera versión estable. La versión 1.1.0 añade nueva funcionalidad sin romper nada. La versión 1.1.1 corrige un bug. La versión 2.0.0 representa un cambio de API incompatible con la versión 1.x. Los pre-releases se indican con un guion: 1.0.0-alpha, 1.0.0-beta.1, 1.0.0-rc.1. + +El archivo CHANGELOG.md documenta qué cambia entre versiones. Su mantenimiento es una buena práctica fundamental en proyectos tanto open source como corporativos. + +--- + +## Apartado 5. Metodologías de desarrollo de software + +### Apartado 5.1. Metodologías tradicionales + +Las metodologías tradicionales o predictivas siguen un plan detallado desde el principio del proyecto. + +La metodología en cascada o waterfall divide el proyecto en fases secuenciales y sin solapamiento. En el documento las veréis numeradas: requisitos, análisis, diseño, implementación, pruebas, despliegue y mantenimiento. Cada fase debe completarse antes de iniciar la siguiente. Su principal ventaja es que es sencilla de gestionar y genera documentación exhaustiva. Su principal inconveniente es que es extremadamente inflexible ante cambios: los errores de análisis se descubren en la fase de pruebas, cuando son muy costosos de corregir. + +El modelo en V extiende la cascada asociando simétricamente cada fase de desarrollo con su fase de pruebas correspondiente. En el diagrama del documento veréis las correspondencias: los requisitos del sistema se corresponden con las pruebas de aceptación o UAT, el diseño del sistema con las pruebas del sistema, el diseño de componentes con las pruebas de integración, y la codificación con las pruebas unitarias. La ventaja clave frente a la cascada es que las pruebas se diseñan desde el principio, no como una actividad de última hora. + +El modelo en espiral de Boehm, publicado en 1986, combina la iteración con el análisis de riesgos en cada ciclo. Cada vuelta de la espiral recorre cuatro cuadrantes: planificación de objetivos y restricciones, análisis e identificación de riesgos técnicos, ingeniería del incremento del ciclo, y evaluación por parte del cliente con planificación de la siguiente espiral. Es adecuado para proyectos grandes con incertidumbre significativa. + +La metodología RUP, siglas de Rational Unified Process, es iterativa, incremental y orientada a la arquitectura. Se divide en cuatro fases: Inicio, Elaboración, Construcción y Transición. Cada fase contiene varias iteraciones con entregables definidos. Usa artefactos UML como diagramas de clases, de secuencia y de casos de uso. Está orientada a proyectos empresariales grandes y complejos. + +--- + +### Apartado 5.2. Metodologías ágiles + +El Manifiesto Ágil fue publicado en 2001 por diecisiete expertos en desarrollo de software. Establece cuatro valores y doce principios. + +Los cuatro valores son los siguientes. Los individuos y las interacciones por encima de los procesos y las herramientas. El software funcionando por encima de la documentación exhaustiva. La colaboración con el cliente por encima de la negociación de contratos. La respuesta al cambio por encima de seguir un plan. + +Es importante recordar que el Manifiesto no dice que los elementos de la derecha no tengan valor. Lo que dice es que los elementos de la izquierda se valoran más. + +--- + +En cuanto a Scrum, es el framework ágil más utilizado. Consultad la tabla de este apartado, que recoge todos los elementos del framework. + +Los artefactos son tres. El Product Backlog es la lista priorizada de todas las funcionalidades del producto. El Sprint Backlog contiene las tareas seleccionadas para el sprint actual. El Incremento es el resultado de cada sprint: software funcional que cumple la Definition of Done. + +Los eventos son cinco. La Sprint Planning es la reunión de inicio del sprint donde se seleccionan y descomponen las tareas. El Daily Scrum es la reunión diaria de quince minutos donde cada miembro responde a tres preguntas: qué hice ayer, qué haré hoy y qué impedimentos tengo. La Sprint Review es la demostración del incremento al cliente al final del sprint. La Sprint Retrospective es la reflexión del equipo sobre qué funcionó y qué mejorar en el siguiente sprint. Y el Sprint en sí mismo es una iteración de una a cuatro semanas con un entregable potencialmente funcional al final. + +Los roles son tres. El Product Owner representa al cliente, gestiona el Product Backlog y decide la prioridad de los requisitos. El Scrum Master facilita el proceso, elimina los impedimentos y protege al equipo de interferencias externas. El Development Team es el equipo autogestionado y multifuncional que desarrolla el producto. + +Las métricas de Scrum más importantes son las siguientes. La velocity mide los story points completados por sprint y sirve para prever la capacidad del equipo y estimar entregas futuras. El burn-down chart es una gráfica que muestra el trabajo restante en el sprint día a día, permitiendo detectar desviaciones a tiempo. La Definition of Done, abreviada DoD, son los criterios acordados que debe cumplir un incremento para considerarse terminado. La Definition of Ready, abreviada DoR, son los criterios que debe cumplir un ítem del backlog para poder entrar en un sprint. + +--- + +Kanban es un sistema de gestión visual del trabajo basado en un tablero con columnas que representan los estados del trabajo, habitualmente Pendiente, En progreso, Revisión y Hecho. + +El principio fundamental de Kanban es limitar el trabajo en curso mediante los límites WIP, que son las siglas de Work In Progress. Estos límites establecen el número máximo de tareas simultáneas por columna, reduciendo el multitasking y mejorando el flujo. + +A diferencia de Scrum, Kanban no tiene sprints fijos: el trabajo fluye de forma continua. + +Las métricas clave son el lead time, que mide el tiempo total desde que se solicita una tarea hasta que se entrega, y el cycle time, que mide el tiempo desde que se empieza a trabajar en una tarea hasta que se entrega. + +Kanban es muy adecuado para equipos de mantenimiento, soporte y operaciones. + +--- + +XP, que son las siglas de Extreme Programming, es una metodología ágil basada en un conjunto de prácticas técnicas intensas orientadas a la calidad del código. + +Las prácticas más importantes son el TDD o Test-Driven Development, en el que los tests se escriben antes que el código; el pair programming o programación en pareja, en la que dos desarrolladores comparten pantalla y teclado; la integración continua, que implica integrar los cambios varias veces al día; el refactoring continuo para mejorar el código sin añadir funcionalidad; y el principio YAGNI, que son las siglas de You Ain't Gonna Need It, es decir, no implementar lo que no se necesita aún. + +--- + +La tabla comparativa al final del apartado cinco resume las diferencias entre metodologías. Las columnas son cascada, modelo en V, Scrum, Kanban y XP. Las filas comparan la planificación, la respuesta a cambios, la documentación, el enfoque de pruebas y el tipo de proyecto para el que es más adecuada cada metodología. + +--- + +## Apartado 6. Pruebas de software + +### Apartado 6.1. Objetivos de las pruebas + +Las pruebas del software tienen cinco objetivos fundamentales. + +El primero es detectar defectos lo antes posible. + +El segundo es verificar que el software está construido correctamente según el diseño, respondiendo a la pregunta ¿estamos construyendo el sistema correctamente? + +El tercero es validar que el software satisface las necesidades reales del usuario, respondiendo a la pregunta ¿estamos construyendo el sistema correcto? + +El cuarto es aumentar la confianza en la calidad del producto. + +El quinto es proporcionar información para la toma de decisiones de release. + +Es importante recordar esta distinción entre verificación y validación, que suele aparecer en preguntas de examen. + +--- + +### Apartado 6.2. Niveles de prueba + +Hay cuatro niveles de prueba. + +Las pruebas unitarias comprueban el funcionamiento de la unidad mínima de código, que puede ser una función, un método o una clase, de forma completamente aislada del resto del sistema. Para aislarlas se usan mocks y stubs, que son objetos que simulan el comportamiento de las dependencias externas como bases de datos, servicios o APIs. Son las pruebas más rápidas de ejecutar y deben ser las más numerosas del proyecto, formando la base de la pirámide de pruebas. Las herramientas más conocidas son JUnit 5 y Mockito para Java, pytest para Python, y Jest para JavaScript. + +Las pruebas de integración verifican que varios módulos o componentes funcionan correctamente al trabajar juntos. Detectan problemas de interfaz entre módulos, como formatos de datos incorrectos o errores de comunicación. Las herramientas habituales son TestContainers, Spring Boot Test y Postman con Newman. + +Las pruebas de sistema comprueban el sistema completo integrado en un entorno similar a producción, verificando el comportamiento frente a los requisitos tanto funcionales como no funcionales, incluyendo rendimiento, seguridad y usabilidad. + +Las pruebas de aceptación, conocidas en inglés como UAT o User Acceptance Testing, son realizadas por el usuario final o cliente para confirmar que el sistema cumple los requisitos del negocio y está listo para producción. Su criterio de aprobación se define en la Definition of Done. En metodologías ágiles pueden automatizarse mediante BDD. + +--- + +### Apartado 6.3. Técnicas de prueba + +Hay tres técnicas principales. + +La caja negra o Black-box Testing prueba la funcionalidad sin conocer la implementación interna. Se analizan las entradas y las salidas esperadas. Las técnicas dentro de la caja negra son las particiones de equivalencia, que dividen los valores de entrada en clases equivalentes para reducir el número de casos de prueba; el análisis de valores límite, que prueba los extremos de cada partición; las tablas de decisión, que cubren todas las combinaciones de condiciones; y las pruebas basadas en estado, que verifican las transiciones entre estados del sistema. + +La caja blanca o White-box Testing prueba conociendo y analizando el código fuente interno. El objetivo es cubrir el máximo de rutas de ejecución. Las métricas de cobertura son tres: la cobertura de líneas, que mide el porcentaje de líneas ejecutadas por los tests; la cobertura de ramas, que mide el porcentaje de ramas condicionales como los if y los else cubiertas; y la cobertura de caminos, que mide el porcentaje de caminos posibles de ejecución y es la más completa pero también la más costosa. Las herramientas de cobertura son JaCoCo para Java, Istanbul y nyc para JavaScript, y coverage punto py para Python. + +La caja gris o Grey-box Testing combina ambos enfoques: se conoce la estructura interna pero las pruebas se diseñan desde la perspectiva del usuario. + +--- + +### Apartado 6.4. Tipos de pruebas por objetivo + +La tabla de este apartado recoge los principales tipos de pruebas clasificados por su objetivo. + +Las pruebas de regresión verifican que los cambios nuevos no han roto funcionalidades existentes. Se automatizan en el pipeline de CI. + +Las pruebas de rendimiento o carga verifican el comportamiento bajo alta demanda. Las herramientas habituales son JMeter, Gatling y k6. + +Las pruebas de estrés verifican el comportamiento cuando el sistema supera su capacidad máxima. + +Las pruebas de seguridad o Pen Testing buscan vulnerabilidades explotables. Las herramientas habituales son OWASP ZAP y Burp Suite. + +Las pruebas de usabilidad verifican la facilidad de uso para el usuario final. + +Las pruebas de accesibilidad verifican el cumplimiento de los estándares WCAG 2.1. + +El smoke testing son pruebas rápidas para verificar que las funciones básicas del sistema arrancan y responden correctamente. + +Las pruebas End-to-End o E2E simulan el flujo completo de un usuario a través del navegador. Las herramientas más usadas son Selenium, Cypress y Playwright. + +Las pruebas de mutación modifican el código fuente de forma deliberada para verificar que los tests existentes detectan esos cambios. Las herramientas son PIT para Java y Stryker para JavaScript. + +--- + +### Apartado 6.5. TDD: Test Driven Development + +TDD sigue el ciclo Red, Green, Refactor. + +En la fase Red se escribe un test que falla, porque la funcionalidad que prueba todavía no existe. El test debe fallar por el motivo correcto, no por un error de sintaxis. + +En la fase Green se escribe el código mínimo necesario para que ese test pase. No importa que el código sea provisional o poco elegante en este momento. + +En la fase Refactor se mejora el diseño y la legibilidad del código sin que fallen los tests existentes. + +Las ventajas de TDD son un código más simple y desacoplado, un alto nivel de cobertura de pruebas desde el inicio, y que los propios tests actúan como documentación viva del comportamiento esperado del sistema. + +--- + +### Apartado 6.6. BDD: Behavior Driven Development + +BDD es una extensión del TDD que describe el comportamiento del sistema en lenguaje natural comprensible por el cliente, usando la sintaxis Given, When, Then, que en español sería Dado que, Cuando, Entonces. + +En el bloque de código del documento veréis dos escenarios escritos en formato Gherkin. El primer escenario describe el login correcto: dado que el usuario ana existe en el sistema, cuando intenta iniciar sesión con la contraseña correcta, entonces debe acceder al panel de control y ver el mensaje de bienvenida. El segundo escenario describe el login fallido: dado el mismo usuario, cuando intenta iniciar sesión con contraseña incorrecta, entonces debe ver el mensaje de credenciales incorrectas. + +Las herramientas que implementan BDD son Cucumber para Java, Ruby y JavaScript; Behave para Python; y SpecFlow para el ecosistema punto NET. + +--- + +### Apartado 6.7. Pirámide de pruebas + +El diagrama de este apartado muestra la pirámide de pruebas definida por Mike Cohn, que establece la proporción ideal de cada tipo de prueba en un proyecto. + +La base de la pirámide está formada por las pruebas unitarias. Deben ser las más numerosas, se ejecutan en milisegundos y tienen un coste bajo porque no requieren infraestructura externa. + +El nivel intermedio está formado por las pruebas de integración. Son más reducidas en número, requieren infraestructura como bases de datos o contenedores, y se ejecutan en segundos. + +La cima de la pirámide está formada por las pruebas End-to-End o de interfaz de usuario. Deben ser pocas, se ejecutan en minutos y son las más frágiles y caras de mantener porque dependen del estado completo del sistema. + +El antipatrón contrario se llama pirámide invertida o cono de helado: pocas pruebas unitarias y muchas pruebas de UI. El resultado es un conjunto de pruebas lento, frágil y muy caro de mantener. Este es el patrón que se debe evitar. + +--- + +## Apartado 7. Plataformas de desarrollo colaborativo + +### Apartado 7.1. GitHub + +GitHub es la mayor plataforma mundial de alojamiento de código Git. Fue adquirida por Microsoft en 2018. + +Las funcionalidades principales son las siguientes. Los Pull Requests son el mecanismo principal de colaboración: una propuesta de cambios para su revisión y discusión antes de fusionarlos con la rama principal. Los Issues permiten gestionar tareas, bugs, mejoras y discusiones del proyecto. GitHub Actions proporciona CI/CD integrado, configurado mediante ficheros YAML en la carpeta punto github barra workflows. GitHub Pages permite alojar sitios estáticos gratuitamente directamente desde el repositorio. GitHub Copilot es el asistente de código basado en inteligencia artificial. GitHub Codespaces proporciona un entorno de desarrollo completo en la nube, accesible desde el navegador. GitHub Packages es el registro integrado de artefactos para npm, Maven, Docker y otros formatos. Dependabot es el bot que detecta dependencias vulnerables y propone actualizaciones automáticas. CodeQL y Secret Scanning proporcionan análisis de seguridad integrado en el repositorio. + +--- + +### Apartado 7.2. GitLab + +GitLab está disponible como servicio en la nube en gitlab punto com y también como instalación on-premise en servidores propios, lo que significa que la organización controla completamente el código y los datos. + +Su CI/CD nativo es muy completo y se configura mediante el fichero punto gitlab guion ci punto yml. El pipeline se organiza en stages como build, test y deploy, y permite definir environments para staging y producción. + +Incluye un Container Registry integrado para imágenes Docker, GitLab Pages para documentación y sitios estáticos, y herramientas completas de gestión de proyectos con wikis, tableros Kanban, milestones y epics. + +GitLab es muy utilizada en las Administraciones Públicas y entornos corporativos precisamente por ofrecer la opción on-premise, que permite mantener el control total del código sin depender de servicios externos. + +--- + +### Apartado 7.3. Bitbucket + +Bitbucket es la plataforma de control de versiones de Atlassian, la misma empresa que desarrolla Jira y Confluence. + +Su principal característica diferencial es la integración nativa con Jira, que permite vincular commits y Pull Requests directamente a las tareas del proyecto de Jira. + +Su servicio de CI/CD integrado se llama Bitbucket Pipelines y se configura mediante el fichero bitbucket guion pipelines punto yml. + +Originalmente era compatible con Git y Mercurial, aunque el soporte a Mercurial se descontinuó en 2020. + +Es la plataforma más habitual en entornos empresariales que utilizan el ecosistema Atlassian completo, es decir, Jira más Confluence más Bitbucket. + +--- + +### Apartado 7.4. Otras herramientas del ciclo de vida + +La tabla de este apartado recoge las herramientas complementarias más importantes del ciclo de vida del software. + +Jira es la herramienta de gestión de proyectos de Atlassian, con seguimiento de tareas, sprints, backlog y tableros Kanban y Scrum. + +Confluence es la wiki corporativa de Atlassian, integrada de forma nativa con Jira. + +SonarQube realiza análisis estático de calidad del código, detectando code smells, midiendo la cobertura de pruebas, identificando vulnerabilidades de seguridad y señalando duplicaciones de código. + +Jenkins es el servidor de automatización de CI/CD open-source más extenso, altamente extensible mediante plugins. + +Docker Hub es el repositorio de imágenes Docker públicas y privadas más utilizado. + +Nexus y Artifactory son repositorios de artefactos para almacenar y gestionar dependencias de Maven, npm, Docker y Helm charts, y también actúan como proxy de repositorios externos. + +Azure DevOps es la suite DevOps completa de Microsoft, que integra en una sola plataforma los repos, los tableros de trabajo, los pipelines de CI/CD, el registro de artefactos y los planes de prueba. + +--- + +### Apartado 7.5. Funcionalidades colaborativas clave + +La tabla final de este apartado recoge las funcionalidades que son comunes a las principales plataformas colaborativas. + +El fork es una copia independiente de un repositorio en la cuenta del desarrollador. Es la base del modelo open source, ya que permite contribuir a proyectos sin tener permiso de escritura directo en el repositorio original. + +El Pull Request o Merge Request es la solicitud formal para integrar los cambios de una rama en otra, incluyendo el proceso de revisión y aprobación. + +El code review o revisión de código es el proceso por el cual otro u otros desarrolladores examinan los cambios propuestos antes de que sean mergeados. + +La protección de ramas impide el push directo a las ramas protegidas como main o develop, obligando a que todos los cambios pasen por un Pull Request y tengan el CI en verde. + +Los webhooks son notificaciones HTTP automáticas que la plataforma envía a servicios externos cada vez que se produce un evento, como un push o un Pull Request. + +La wiki es la documentación del proyecto integrada en la propia plataforma. + +Los milestones agrupan issues y Pull Requests para el seguimiento de versiones concretas o fechas de entrega. + +Las labels o etiquetas clasifican los issues y Pull Requests por tipo: bug, enhancement, documentation, y otros. + +--- + +## Apartado 8. Resumen: conceptos clave para el examen + +El documento finaliza con la tabla de conceptos clave para el examen. Vamos a repasar los más importantes en grupos temáticos. + +Sobre control de versiones: DVCS es el sistema de control de versiones distribuido en el que cada clon tiene el historial completo. Git es el DVCS más usado, basa su almacenamiento en objetos SHA-1 y modela el historial como un grafo acíclico dirigido. Un commit es una instantánea identificada por su hash SHA-1 que apunta a su commit padre. Una branch es una línea de desarrollo paralela; main es la rama principal por convención. El merge preserva el historial real; el rebase lo lineariza, y nunca debe aplicarse a commits ya publicados. Gitflow usa las ramas main, develop, feature, release y hotfix. El archivo punto gitignore define qué ficheros excluir del control de versiones. + +Sobre CI/CD y versionado: CI es la integración continua; CD es la entrega o el despliegue continuo. Las herramientas principales son Jenkins, GitHub Actions y GitLab CI. SemVer usa el formato MAJOR punto MINOR punto PATCH: MAJOR para breaking changes, MINOR para nuevas features y PATCH para correcciones de bugs. + +Sobre metodologías: la cascada tiene fases secuenciales sin retroceso y los errores se detectan tarde. El modelo en V añade pruebas planificadas simétricamente desde el diseño. El Manifiesto Ágil es de 2001 y tiene cuatro valores centrados en individuos, software funcionando, colaboración y respuesta al cambio. Scrum usa sprints de una a cuatro semanas con los roles Product Owner, Scrum Master y Development Team y los eventos Planning, Daily, Review y Retrospective. La velocity mide los story points completados por sprint. La DoD son los criterios de terminado de un incremento. Kanban usa tablero visual con límites WIP y mide lead time y cycle time. + +Sobre pruebas: TDD sigue el ciclo Red, Green, Refactor y el test se escribe antes que el código. BDD usa la sintaxis Given, When, Then con herramientas como Cucumber y Behave. La prueba unitaria prueba la unidad mínima de forma aislada con mocks y stubs. La prueba de integración prueba varios módulos juntos. La prueba de aceptación o UAT la realiza el usuario final. La caja negra prueba la funcionalidad sin ver el código. La caja blanca prueba conociendo el código y mide cobertura de líneas, ramas y caminos. La pirámide de pruebas tiene muchas pruebas unitarias en la base, pruebas de integración en el nivel intermedio y pocas pruebas E2E en la cima. + +Sobre plataformas: GitHub es la plataforma más popular, fue adquirida por Microsoft en 2018 y usa GitHub Actions para CI/CD y GitHub Copilot para asistencia con IA. GitLab permite instalación on-premise y es muy usada en las Administraciones Públicas; su CI/CD se configura con el fichero punto gitlab guion ci punto yml. Bitbucket pertenece a Atlassian y tiene integración nativa con Jira. SonarQube realiza análisis estático de calidad del código detectando code smells, midiendo cobertura e identificando vulnerabilidades. -Git es el sistema de control de versiones distribuido más usado, con áreas working, staging, repositorio local y remoto. Las metodologías ágiles nacen del Manifiesto de 2001; Scrum usa Sprints, Product Owner, Scrum Master y Daily; Kanban usa tablero con límites WIP. Las pruebas se dividen en unitarias, integración, sistema y aceptación; caja negra sin ver código, caja blanca con código. TDD sigue el ciclo Red Green Refactor. GitHub fue adquirida por Microsoft en 2018; GitLab es la opción on-premise preferida en las Administraciones Públicas; SonarQube analiza la calidad del código.