Tema 9: Repositorios, control de versiones y metodologías

Metodologías de desarrollo de software

Una metodología de desarrollo es un marco de trabajo estructurado que ordena las actividades de análisis, diseño, construcción, pruebas y mantenimiento de un sistema de información, definiendo roles, productos y técnicas. En el contexto de la Administración pública española conviven metodologías clásicas (predictivas, como Métrica v3), marcos ágiles (como Scrum) y marcos de gestión de servicios (como ITIL). No conviene confundirlas: describen fases distintas del ciclo de vida y persiguen objetivos diferentes.

Enfoque predictivo frente a enfoque ágil

Las metodologías predictivas o "en cascada" planifican por adelantado la totalidad del alcance y avanzan por fases secuenciales. Las metodologías ágiles —basadas en el Manifiesto Ágil (2001)— trabajan de forma iterativa e incremental, entregando producto funcional de forma frecuente, adaptándose al cambio y favoreciendo la colaboración con el cliente. Scrum, Kanban o Extreme Programming (XP) son ejemplos de marcos ágiles.

Scrum

Scrum es una metodología (marco de trabajo) ágil para desarrollar, entregar y mantener productos complejos. Es un marco ligero ("lightweight") que ayuda a las personas y equipos a generar valor mediante soluciones adaptativas. Se apoya en el empirismo (las decisiones se basan en lo observado) y en el pensamiento lean, con tres pilares: transparencia, inspección y adaptación.

Scrum define un pequeño número de elementos:

• Roles / responsabilidades (Scrum Team): Product Owner (maximiza el valor del producto y gestiona el Product Backlog), Scrum Master (facilita el proceso y elimina impedimentos) y Developers (construyen el Incremento).

• Eventos: el Sprint (contenedor de los demás) y, dentro de él, Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective.

• Artefactos: Product Backlog, Sprint Backlog e Incremento.

El Sprint

El Sprint es el corazón de Scrum: es un ciclo de trabajo de corta duración, de longitud fija de un mes o menos, en el que se produce un Incremento de producto utilizable y potencialmente entregable. En otras palabras, los sprints son los ciclos de trabajo de corta duración en los que se realiza el incremento de producto. Al tener una duración fija (time-box) crean consistencia y ritmo; cuando termina un Sprint, comienza inmediatamente el siguiente. El Incremento es un peldaño concreto hacia el objetivo del producto; cada Incremento se suma a los anteriores y debe cumplir la Definición de Terminado (Definition of Done) para considerarse completado. Todo el equipo Scrum es responsable de crear un Incremento valioso y útil en cada Sprint.

Puntos clave que se preguntan en examen:

• Scrum es un marco/metodología ágil (no es un lenguaje, ni una herramienta de control de versiones, ni una base de datos).

• Un sprint es un ciclo de trabajo de corta duración en el que se realiza un incremento de producto; su duración es fija y de un mes o menos.

ITIL

ITIL (Information Technology Infrastructure Library, Biblioteca de Infraestructura de Tecnologías de la Información) es una colección de mejores prácticas para la gestión de servicios de tecnologías de la información (ITSM, IT Service Management). No es una metodología de desarrollo de software ni un estándar de obligado cumplimiento, sino un conjunto de recomendaciones y buenas prácticas para planificar, entregar, operar y mejorar los servicios TI de forma alineada con las necesidades del negocio.

Características relevantes:

• Fue desarrollada originalmente en los años 80 por la británica CCTA (Central Computer and Telecommunications Agency); actualmente su propiedad y gobierno recaen en AXELOS/PeopleCert.

• ITIL v3 organizaba el ciclo de vida del servicio en cinco fases (Estrategia, Diseño, Transición, Operación y Mejora Continua del Servicio).

• ITIL 4 (2019) reorienta el marco hacia el Sistema de Valor del Servicio (SVS), la cadena de valor del servicio y sus principios guía.

• ITIL se relaciona con la norma ISO/IEC 20000 de gestión de servicios TI.

Idea clave para test: ITIL es una colección de mejores prácticas de gestión de servicios de TI, no un método de codificación ni una metodología ágil.

Métrica v3

Métrica versión 3 es la metodología de planificación, desarrollo y mantenimiento de sistemas de información promovida por el Consejo Superior de Administración Electrónica para las Administraciones públicas españolas. Estructura el trabajo en procesos principales —PSI (Planificación de Sistemas de Información), EVS (Estudio de Viabilidad del Sistema), ASI (Análisis del Sistema de Información), DSI (Diseño del Sistema de Información), CSI (Construcción del Sistema de Información), IAS (Implantación y Aceptación del Sistema) y MSI (Mantenimiento del Sistema de Información)— y define cuatro interfaces transversales que cubren todo el ciclo de vida:

El Plan de Gestión de Riesgos en Métrica v3

Dentro de la Interfaz de Gestión de Proyectos, Métrica v3 contempla la gestión de riesgos, cuyo primer objetivo es identificar los riesgos potenciales del proyecto para poder analizarlos, planificar respuestas y hacerles seguimiento. El Plan de Gestión de Riesgos es el producto que recoge esos riesgos identificados junto con su valoración y las estrategias de mitigación previstas.

En síntesis, el propósito del Plan de Gestión de Riesgos en Métrica v3 es identificar los riesgos potenciales del proyecto (y establecer cómo se van a analizar, tratar y controlar), no gestionar el presupuesto, el código fuente ni las versiones del software.

Fuentes

• The 2020 Scrum Guide — Ken Schwaber & Jeff Sutherland (versión en español europeo): https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-European.pdf

• The 2020 Scrum Guide (inglés): https://scrumguides.org/scrum-guide.html

• PAe — Metodología Métrica v3, Consejo Superior de Administración Electrónica (administracionelectronica.gob.es): https://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_METRICA_v3.html

• Referencia estructurada de Métrica v3 (interfaces y procesos): https://manuel.cillero.es/doc/metodologia/metrica-3/

• AXELOS / ITIL 4 — IT Service Management best practice: https://www.axelos.com/certifications/itil-service-management

• ISO/IEC 20000 — IT Service Management: https://www.iso.org/standard/70636.html

Control de versiones

Un sistema de control de versiones (VCS, Version Control System) es una herramienta que registra los cambios realizados sobre uno o varios ficheros a lo largo del tiempo, de modo que pueda recuperarse cualquier estado anterior, compararse revisiones y coordinarse el trabajo de varios desarrolladores sobre la misma base de código. Son herramientas específicas de control de versiones de software: Git, Mercurial y Apache Subversion (SVN), a las que se suman los sistemas históricos CVS (Concurrent Versions System) y Microsoft Visual SourceSafe (VSS).

Conviene no confundir el sistema de control de versiones con la plataforma de alojamiento colaborativo que lo aloja. GitHub, GitLab, Bitbucket o Azure DevOps Server son servicios/plataformas construidos sobre un VCS (normalmente Git), pero Bitbucket no es en sí mismo un sistema de control de versiones, sino una plataforma de Atlassian que aloja repositorios Git y que permite la integración con la herramienta JIRA. Tampoco es un VCS JMeter, que es una herramienta de pruebas de carga y rendimiento de Apache.

Modelos: centralizado frente a distribuido

• Centralizado (CVS, Subversion, VSS): existe un único repositorio central con el que cada desarrollador trabaja directamente; el historial reside en el servidor y suele necesitarse conexión para operar.

• Distribuido (Git, Mercurial): cada desarrollador dispone de una copia local completa del repositorio, con todo el historial. Por ello, es INCORRECTO afirmar que "en el modelo distribuido cada desarrollador trabaja directamente con el repositorio central": precisamente lo característico del modelo distribuido es que el trabajo se realiza contra el repositorio local, y solo se sincroniza con el remoto cuando se desea.

Git

Git es un sistema de control de versiones de código libre y arquitectura distribuida, creado por Linus Torvalds. Al ser distribuido, no es necesario tener conexión a internet para realizar confirmaciones (commits): los commits se registran en el repositorio local. En Git, hacer un commit es la acción de almacenar una nueva instantánea (snapshot) del estado del proyecto en el historial de Git.

Comandos esenciales de Git

El fichero .gitignore especifica qué archivos NO deben ser rastreados (ignorados) por el control de versiones. No es un comando, sino un fichero de configuración por directorio.

Apache Subversion (SVN)

Subversion es un sistema de control de versiones centralizado. Para indicar los ficheros que NO deben ser tenidos en cuenta por el control de versiones se emplea la propiedad svn:ignore, establecida con svn propset sobre un directorio versionado; para consultarla se usa svn propget svn:ignore. La propiedad contiene patrones de nombre de fichero separados por saltos de línea y aplica solo al directorio en el que se define, no a sus subdirectorios.

CVS (Concurrent Versions System)

CVS es un VCS centralizado clásico. Comandos relevantes:

• annotate: si se necesita verificar la revisión en que fue modificada cada línea de un archivo, se utiliza el comando annotate (muestra, línea a línea, la última revisión que la modificó y su autor).

• cvs add -kb miFichero: la opción de expansión de palabras clave -kb marca el fichero como binario; al ejecutarlo se está añadiendo un fichero como binario, evitando la conversión de fines de línea entre plataformas y la sustitución de palabras clave.

Mercurial

Mercurial es un sistema de control de versiones distribuido y multiplataforma, orientado a desarrolladores de software, cuyo cliente de línea de órdenes es hg. El comando outgoing (hg outgoing) permite comprobar qué conjuntos de cambios (changesets) se subirían al repositorio de destino si se ejecutara un push; muestra los cambios locales aún no presentes en el remoto, sin llegar a enviarlos.

Herramientas de Microsoft

• Microsoft Visual SourceSafe (VSS) es una herramienta de control de versiones de Microsoft (hoy descatalogada), de modelo centralizado.

• Azure DevOps Server (antes Team Foundation Server, TFS) es la plataforma de control de versiones de Microsoft actual, que soporta tanto repositorios Git como el control centralizado TFVC, además de gestión de proyectos y CI/CD.

Cuadro resumen de identificación

Fuentes

• Git — Documentación oficial (git-scm.com): https://git-scm.com/docs (git-init, git-clone, git-branch, git-tag, git-diff, git-commit, git-push, gitignore)

• Git Reference / gitignore: https://git-scm.com/docs/gitignore

• Apache Subversion — Version Control with Subversion, "Ignoring Unversioned Items" (svn:ignore, propget/propset): https://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html

• Mercurial SCM — Command reference hg outgoing: https://www.mercurial-scm.org/

• CVS — Concurrent Versions System, "Handling binary files" y "Keyword substitution" (-kb, annotate): https://www.gnu.org/software/trans-coord/manual/cvs/html_node/Binary-howto.html

• Atlassian Bitbucket / integración con Jira: https://www.atlassian.com/software/bitbucket

• Microsoft Learn — Azure DevOps Server: https://learn.microsoft.com/azure/devops/

Pruebas de software

Las pruebas constituyen el conjunto de actividades encaminadas a verificar y validar que un sistema de información cumple los requisitos especificados y funciona correctamente. En el contexto de la Administración española, la metodología de referencia es MÉTRICA Versión 3, que estructura las pruebas a lo largo del ciclo de vida (procesos de Construcción del Sistema de Información —CSI— e Implantación y Aceptación del Sistema —IAS—). Junto a ella conviven numerosas herramientas de software libre para automatizar los distintos niveles y tipos de prueba.

Tipos de pruebas en MÉTRICA V3

MÉTRICA V3 distingue varios tipos de prueba, cada uno con un objetivo diferenciado:

• Pruebas unitarias: verifican el comportamiento de cada componente o módulo de forma aislada.

• Pruebas de integración: su finalidad es verificar que los distintos componentes o subsistemas interactúan correctamente a través de sus interfaces, tanto internas como externas, comprobando que cubren la funcionalidad establecida y se ajustan a los requisitos especificados. En términos de propósito, evalúan la capacidad del software para trabajar de manera efectiva con otros componentes y sistemas.

• Pruebas del sistema: comprueban el sistema completo integrado frente a los requisitos.

• Pruebas de implantación: validan el funcionamiento en el entorno de operación real.

• Pruebas de aceptación: permiten al usuario validar que el software cumple con los requisitos establecidos en la Especificación de Requisitos de Pruebas, desde el punto de vista de su funcionalidad y rendimiento.

• Pruebas de regresión: comprueban que los cambios sobre un componente de un sistema de información no introducen un comportamiento no deseado o errores adicionales en otros componentes no modificados (eliminación del "efecto onda"). Estas pruebas sí pueden automatizarse —afirmar que no es posible automatizarlas es incorrecto—; de hecho, la automatización es lo que las hace viables al repetirse tras cada cambio.

• Pruebas de rendimiento: consisten en determinar que los tiempos de respuesta están dentro de los intervalos establecidos en las especificaciones del sistema.

• Pruebas de carga: evalúan la capacidad del software para manejar grandes volúmenes de datos y usuarios concurrentes.

Documentos y planificación de las pruebas en MÉTRICA V3

MÉTRICA V3 formaliza la actividad de pruebas mediante varios productos:

• Plan de Pruebas: su propósito es establecer la estrategia y los objetivos de las pruebas. Recoge las actividades de prueba a realizar según una planificación y se inicia en fases tempranas del desarrollo.

• Especificación del Plan de Pruebas: detalla el plan e incluye, entre sus tareas, la Definición del Alcance de las Pruebas, la Definición de Requisitos del Entorno de Pruebas y la Definición de las Pruebas de Aceptación del Sistema.

• Especificación de Requisitos de Pruebas: sirve como guía para la realización de las pruebas y permite verificar que el sistema de información cumple las necesidades establecidas por el usuario, con las debidas garantías de calidad. Es la referencia contra la que se validan las pruebas de aceptación.

• Informe de Pruebas (o Evaluación del Resultado de las Pruebas): su propósito es documentar los resultados de las pruebas realizadas.

Herramientas de automatización y pruebas

Pruebas unitarias — JUnit

JUnit es el conjunto de bibliotecas para pruebas unitarias de aplicaciones Java. Forma parte de la familia xUnit y permite definir casos de prueba, aserciones y su ejecución automatizada, integrándose habitualmente en los entornos de compilación e integración continua.

Pruebas funcionales web y móviles — Selenium y Appium

Selenium es un entorno (framework) de pruebas de software para aplicaciones basadas en la web, específicamente diseñado para la automatización de pruebas funcionales sobre aplicaciones web. Sus pruebas pueden ejecutarse en Windows, Linux y OSX (macOS), y admite múltiples lenguajes (Java, C#, Python, Ruby, JavaScript, etc.) comunicándose con los navegadores mediante el protocolo WebDriver.

Appium es una herramienta de automatización de código abierto para ejecutar scripts y probar aplicaciones nativas, aplicaciones web y aplicaciones híbridas sobre Android o iOS utilizando un WebDriver. Extiende el modelo de Selenium al ámbito móvil.

Pruebas de carga, estrés y rendimiento

Apache JMeter es una aplicación Java de código abierto para pruebas de carga y estrés, que permite simular escenarios de concurrencia de usuarios sobre servidores, redes u objetos. Puede realizar pruebas de rendimiento y pruebas unitarias. Se define con claridad como una herramienta de pruebas unitarias para conexiones de bases de datos con JDBC, FTP, LDAP, servicios web, JMS, HTTP y conexiones TCP genéricas. Soporta, entre otros, los protocolos HTTP/HTTPS, SOAP/REST, FTP, JDBC, LDAP, JMS, SMTP/POP3/IMAP y TCP; por ello, ante la pregunta de qué protocolo utiliza, la respuesta correcta es que se puede utilizar con todos ellos. En cambio, NO es una funcionalidad de JMeter capturar tramas de red (esa función corresponde a analizadores como Wireshark).

Gatling es una herramienta de prueba de carga de código libre que se integra con soluciones existentes y ofrece integración con herramientas de CI/CD. Está construida sobre Scala, Akka y Netty; su marco distribuido permite la computación totalmente asíncrona, modelando los usuarios virtuales como mensajes ligeros en lugar de hilos, lo que le permite simular grandes cargas con pocos recursos.

Tsung es una herramienta de software libre que se especializa en pruebas de carga y estrés para aplicaciones basadas en protocolos de base de datos (además de HTTP, WebDAV, LDAP, XMPP, MQTT, etc.), destacando por su capacidad de generar cargas distribuidas de alta concurrencia.

Producto que NO es de pruebas — OneTrust

Conviene distinguir las herramientas de prueba de otros productos. OneTrust NO es un producto orientado a las pruebas de software: es una plataforma de gestión de privacidad, cumplimiento normativo y gobierno de datos (GRC), ajena al ámbito del testing.

Resumen comparativo de herramientas

Fuentes

• MÉTRICA Versión 3 — Ministerio (portal de Administración Electrónica / preparatic): https://www.preparatic.org/material/20100918/Metrica_v3.pdf

• MÉTRICA v3, Técnicas de Pruebas (Integración y Regresión) — manuel.cillero.es: https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/pruebas/

• Apache JMeter — sitio oficial (protocolos soportados): https://jmeter.apache.org/

• Apache JMeter — Wikipedia (lista de protocolos): https://en.wikipedia.org/wiki/Apache_JMeter

• Gatling — documentación oficial (arquitectura asíncrona, CI/CD): https://docs.gatling.io/

• Gatling — repositorio oficial: https://github.com/gatling/gatling

• Appium — sitio oficial (automatización móvil vía WebDriver): https://appium.github.io/appium.io/index.html

• JUnit — sitio oficial: https://junit.org/

• Tsung — documentación oficial: http://tsung.erlang-projects.org/

Integración continua y colaboración

El desarrollo de software moderno se apoya en plataformas de desarrollo colaborativo, en sistemas de control de versiones y en un conjunto de herramientas que automatizan la construcción, la prueba y la entrega del código. Este bloque cubre los conceptos y productos que la práctica del desarrollo colaborativo y la integración continua (CI) utiliza a diario, distinguiendo con precisión qué es cada herramienta, porque la principal fuente de error es confundir categorías (control de versiones, plataforma de alojamiento, herramienta de construcción, servidor de CI/CD, análisis de código).

Plataformas de desarrollo colaborativo de software

Una plataforma de desarrollo colaborativo (forge) aloja el código de un proyecto y añade servicios sociales y de gestión alrededor del repositorio: seguimiento de incidencias, wikis, revisión de código, ramas, control de acceso e integración con CI/CD. Los ejemplos canónicos son GitHub, GitLab, Bitbucket y SourceForge.

CVS (Concurrent Versions System) NO es una plataforma de desarrollo colaborativo: es un sistema de control de versiones (VCS) centralizado, precursor de Subversion (SVN). Conviene no confundir la herramienta que versiona los ficheros (CVS, Subversion, Git, Mercurial) con la plataforma web que aloja el proyecto y lo rodea de servicios colaborativos.

CodePlex fue un sitio web para alojar proyectos de software de código abierto creado por Microsoft. Ofrecía alojamiento de proyectos open source con control de versiones, seguimiento de incidencias y descargas. Microsoft anunció su cierre: dejó de admitir nuevos proyectos en marzo de 2017 y lo apagó definitivamente el 15 de diciembre de 2017, ofreciendo herramientas de migración a GitHub, que se había convertido en el estándar de facto para proyectos de código abierto.

Control de versiones y pull requests

En el flujo de trabajo con ramas, el mecanismo central de colaboración es la pull request (también "merge request" en GitLab). Una pull request es una propuesta para fusionar un conjunto de cambios de una rama en otra. El autor publica sus commits en una rama y solicita su incorporación a la rama de destino (por ejemplo, main); antes de la fusión, el equipo revisa el código, comenta las líneas, ejecuta las pruebas automáticas de CI y aprueba o rechaza. Es, por tanto, la unidad de revisión de código y de control de calidad previa a la integración.

Herramientas de construcción de proyectos (build tools)

Las herramientas de construcción automatizan la compilación, la gestión de dependencias, el empaquetado y la ejecución de pruebas. Las más habituales son:

• Apache Maven y Apache Ant (ecosistema Java).

• Gradle (Java/Android, basado en Groovy/Kotlin).

• Make (mundo C/C++ y general).

• MSBuild (.NET).

Subversion NO es una herramienta de construcción de proyectos: es un sistema de control de versiones. Versiona el código, pero no lo compila ni lo empaqueta. Es un error clásico de examen: Subversion pertenece a la categoría de VCS, no a la de build tools.

Integración y entrega continuas (CI/CD)

La integración continua consiste en fusionar frecuentemente los cambios en una rama común y validarlos automáticamente con compilación y pruebas; la entrega/despliegue continuos llevan ese artefacto validado hasta los distintos entornos de forma automatizada. Los servidores de CI/CD orquestan este proceso "desde el código hasta el despliegue":

• Bamboo, de Atlassian, es un producto para la gestión continua de software: automatiza compilación, pruebas y despliegue, creando un pipeline de entrega continua e integrándose con Jira y Bitbucket.

• Otros servidores/servicios de CI/CD: Jenkins, GitLab CI/CD, TeamCity, Travis CI, CircleCI, GitHub Actions.

Contenedores: Docker

Docker es una herramienta de código abierto que empaqueta software en unidades estandarizadas llamadas contenedores. Un contenedor incluye todo lo necesario para que el software se ejecute: el código, el tiempo de ejecución (runtime), las bibliotecas y las herramientas de sistema. Al aislar la aplicación de la máquina anfitriona, garantiza que se ejecute igual en desarrollo, en integración continua y en producción, resolviendo el clásico "en mi máquina funciona" y facilitando el despliegue reproducible dentro del pipeline de CI/CD.

Herramientas de front-end: preprocesadores CSS

Un preprocesador CSS es una herramienta que mejora la funcionalidad del lenguaje de las hojas de estilo en las páginas web. Extiende CSS con características de las que este carece de forma nativa (o carecía históricamente): variables, anidamiento (nesting), mixins, funciones, operaciones y modularización mediante importaciones. El código escrito en la sintaxis del preprocesador se "compila" a CSS estándar que el navegador entiende. Los preprocesadores más difundidos son Sass/SCSS, LESS y Stylus.

Modelado UML

Entre las herramientas de diagramas UML, Papyrus UML (Eclipse Papyrus) es gratuita y de código abierto. Es un entorno de modelado basado en Eclipse, licenciado bajo la Eclipse Public License (EPL) y desarrollado por el CEA-List, que ofrece editores para todos los diagramas UML 2 definidos por el OMG y soporte para SysML. Puede usarse como aplicación independiente o como plugin de Eclipse. Frente a él, herramientas como Enterprise Architect, MagicDraw o Visual Paradigm son comerciales.

Análisis de calidad de código: SonarQube

SonarQube (de SonarSource/Sonar) es una plataforma de análisis estático de código (SAST). Inspecciona el código fuente sin ejecutarlo para detectar bugs, vulnerabilidades de seguridad y code smells (deuda técnica), y mide cobertura de pruebas, duplicidades y complejidad, integrándose en el pipeline de CI/CD y en el IDE. Da soporte a más de 40 lenguajes y se ofrece como SonarQube Server (autoalojado) y SonarQube Cloud.

Por tanto, es INCORRECTO describir SonarQube como una "solución diseñada para realizar análisis dinámico del código fuente": SonarQube realiza análisis estático, no dinámico (el análisis dinámico exige ejecutar el programa, que es lo que SonarQube precisamente no hace).

Resumen de categorías (para no confundirlas)

Fuentes

• Docker Inc. — What is a Container / Docker overview: https://www.docker.com/resources/what-container/

• GitHub Docs — About pull requests: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests

• Atlassian — Bamboo (Continuous Integration & Deployment): https://www.atlassian.com/software/bamboo

• Apache Maven Project (herramienta de construcción): https://maven.apache.org/

• Apache Subversion (control de versiones): https://subversion.apache.org/

• Microsoft / CodePlex — cierre y migración a GitHub: https://learn.microsoft.com/ (anuncio de cierre de CodePlex, 15/12/2017)

• Sonar — SonarQube Server documentation (análisis estático): https://docs.sonarsource.com/sonarqube-server

• Eclipse Papyrus — entorno de modelado UML open source (EPL): https://eclipse.dev/papyrus/

• Sass (preprocesador CSS): https://sass-lang.com/documentation/

• OMG — Unified Modeling Language (UML) Specification: https://www.omg.org/spec/UML/