Tema 23. 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.

1. Repositorios: estructura y actualización

1. Repositorios: estructura y actualización

🎯 Idea clave

• Un repositorio es una ubicación centralizada o distribuida que almacena código, artefactos y documentación junto con su historial completo de cambios.
• Su valor fundamental reside en permitir la trazabilidad, reproducibilidad y colaboración en el desarrollo de proyectos software.
• Existen múltiples tipos de repositorios según su contenido: de código fuente, artefactos, contenedores, paquetes, datos y documentos.
• La estructura típica incluye directorios específicos y ficheros canónicos que facilitan la organización y el flujo de colaboración.
• La correcta estructuración y actualización del repositorio afecta directamente a la calidad, seguridad e integración continua del software.

📚 Desarrollo

Concepto y naturaleza. Un repositorio constituye el espacio organizado donde se almacena y gestiona la evolución de un proyecto software o documental. No se trata meramente de una carpeta con archivos, sino de una infraestructura crítica que conserva el historial completo de cambios, metadatos descriptivos, referencias a versiones, ramas, etiquetas y configuraciones asociadas al flujo colaborativo de trabajo diario.

Alcance y tipologías. Existen diversas categorías según su contenido y función específica: repositorios de código fuente como Git, SVN o Mercurial; de artefactos compilados como Maven, npm o PyPI; de contenedores como Docker Hub o ECR; de paquetes del sistema como apt o Homebrew; de datos estructurados como Iceberg o Delta Lake; y de documentación institucional como DSpace o Confluence.

Estructura organizativa. La configuración interna habitual incluye directorios específicos como src/ para el código fuente, tests/ para las pruebas automatizadas y docs/ para la documentación técnica. Además, incorpora ficheros canónicos esenciales: README con la descripción del proyecto, LICENSE con los términos legales, CONTRIBUTING con las normas de colaboración, CHANGELOG con el registro de modificaciones y SECURITY con las políticas de vulnerabilidades.

Modelos de distribución. Los repositorios pueden adoptar arquitecturas centralizadas, donde existe un único servidor maestro, o distribuidas, donde cada clon local contiene el repositorio completo con todo su historial. En el desarrollo software contemporáneo, Git se ha consolidado como el estándar de facto para el control de versiones distribuido, ofreciendo flexibilidad y redundancia.

Impacto en el ciclo de vida. La estructura y la correcta actualización del repositorio determinan directamente la calidad, trazabilidad, seguridad, integración continua y mantenibilidad del proyecto. Constituye la fuente de verdad del código y almacena buena parte del conocimiento técnico del equipo, permitiendo saber con precisión qué cambio se realizó, cuándo, por quién y sobre qué versión anterior.

Contexto institucional. En el ámbito de las Administraciones Públicas, los repositorios se han convertido en infraestructura crítica para garantizar la reproducibilidad, la trazabilidad completa y la colaboración segura en los desarrollos tecnológicos. Facilitan la reconstrucción precisa del contexto en que cada modificación fue introducida, manteniendo metadatos asociados que permiten auditorías y control de cambios rigurosos.

🧩 Elementos esenciales

• Ubicación centralizada o distribuida: modelo arquitectónico que determina cómo se almacenan y acceden los activos digitales y su historial.
• Historial completo: registro persistente de todas las modificaciones realizadas sobre los archivos del proyecto a lo largo del tiempo.
• Metadatos asociados: información contextual que permite reconstruir las circunstancias, autores y motivaciones de cada cambio introducido.
• Repositorios de código fuente: especializados en almacenar el código de programas utilizando sistemas como Git, SVN o Mercurial.
• Repositorios de artefactos: destinados a bibliotecas compiladas, dependencias y paquetes como los gestionados por Maven, npm o NuGet.
• Repositorios de contenedores: almacenan imágenes de despliegue y configuraciones como Docker Hub, ECR o ACR.
• Ficheros canónicos: documentos estándar como README, LICENSE, CONTRIBUTING, CHANGELOG, SECURITY y .gitignore que organizan el proyecto.
• Directorios estructurales: carpetas típicas como src/, tests/ y docs/ que separan el código fuente de las pruebas y documentación.
• Fuente de verdad: rol del repositorio como referencia única y oficial del estado actual y histórico del código del proyecto.

🧠 Recuerda

• Un repositorio es más que almacenamiento: es historial, contexto y mecanismo de colaboración entre desarrolladores.
• La estructura afecta directamente a la calidad, trazabilidad y mantenibilidad del software desarrollado.
• Git se ha consolidado como el estándar de facto para los repositorios distribuidos actuales.
• Los ficheros canónicos facilitan la comprensión, colaboración y gobernanza del proyecto software.
• La trazabilidad completa exige metadatos precisos sobre qué, cuándo, quién y por qué.
• Las Administraciones Públicas dependen de estos sistemas para garantizar seguridad y reproducibilidad en sus desarrollos.
• Cada clon en sistemas distribuidos contiene el repositorio completo con todo su historial de cambios.
• Existen tipos específicos según el activo almacenado: código, artefactos, datos, documentos o imágenes.

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

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

🎯 Idea clave

• La generación de código produce artefactos a partir de modelos, plantillas, contratos, esquemas o metadatos de alto nivel.
• Existen dos enfoques diferenciados: código como punto de partida editable manualmente y código regenerable que no debe modificarse directamente.
• OpenAPI permite describir APIs HTTP para generar automáticamente clientes, servidores base, documentación y pruebas asociadas.
• Javadoc y Doxygen extraen documentación técnica a partir de comentarios estructurados y la firma del código fuente.
• La inteligencia artificial generativa asiste en la escritura de código pero requiere revisión exhaustiva y control de confidencialidad.
• La documentación técnica se clasifica según su audiencia específica: API, arquitectura, operación, usuario, desarrollador y cumplimiento normativo.

📚 Desarrollo

Definición fundamental. La generación de código consiste en producir código fuente, configuraciones o artefactos relacionados a partir de descripciones de mayor nivel, modelos formales, plantillas predefinidas o esquemas estructurados. Un generador aplica reglas deterministas para interpretar estas especificaciones y escribir archivos en lenguajes o frameworks concretos, automatizando la creación de estructuras repetitivas y reduciendo errores manuales en el desarrollo inicial.

Enfoques operativos. Se distinguen dos modalidades principales en la práctica profesional. En la primera, el código generado funciona como punto de partida que los desarrolladores modifican manualmente posteriormente, habitual en procesos de scaffolding inicial de proyectos. En la segunda modalidad, el código se considera derivado de una fuente canónica y no debe editarse directamente, pues cualquier regeneración futura sobrescribiría irremediablemente los cambios realizados.

Tecnologías de generación. Las estrategias comprenden templating o scaffolding con herramientas como Yeoman, Spring Initializr o Angular CLI, generación dirigida por modelos mediante arquitecturas MDA o frameworks EMF, generación desde esquemas o IDL utilizando OpenAPI Generator o Swagger Codegen, creación automática desde bases de datos con Hibernate o EF Core, y procesadores de anotaciones en tiempo de compilación como Lombok o MapStruct.

Especificación OpenAPI. El estándar OpenAPI permite describir APIs HTTP de forma declarativa para generar automáticamente clientes, servidores base, documentación interactiva y casos de prueba asociados. Swagger Codegen y OpenAPI Generator constituyen ejemplos representativos de esta categoría, aplicando transformaciones deterministas a partir de contratos formales que sirven como fuente única de verdad.

Documentación técnica automática. Herramientas como Javadoc para el ecosistema Java y Doxygen para múltiples lenguajes generan documentación técnica a partir de comentarios estructurados, firmas de métodos y definiciones de tipos. Este enfoque mantiene la documentación cercana al código fuente, facilitando su actualización sincronizada, aunque la calidad final depende enteramente de la precisión y completitud de los comentarios originales.

Asistencia mediante IA. La inteligencia artificial generativa asiste en la escritura de código, pruebas unitarias y documentación explicativa, pero debe tratarse exclusivamente como apoyo, no como autoridad final. El contenido producido puede contener errores sintácticos, vulnerabilidades de seguridad, dependencias inexistentes o licencias problemáticas, requiriendo revisión manual exhaustiva y verificación de confidencialidad antes de su incorporación a repositorios corporativos.

Clasificación por audiencia. La documentación técnica se diferencia según su destinatario y ritmo de actualización en: documentación de API para consumidores de servicios, documentación de arquitectura para equipos de diseño, documentación de usuario para operadores finales, documentación de desarrollador para mantenedores del código, documentación de operación para equipos de despliegue, y documentación de cumplimiento para auditorías normativas.

Garantías de calidad. Los generadores utilizados deben versionarse y ejecutarse de forma reproducible en entornos controlados. El código generado requiere revisión humana, pruebas funcionales y análisis de seguridad antes de su integración. La documentación automática no garantiza por sí sola calidad explicativa cuando los comentarios fuente resultan triviales, obsoletos o técnicamente incorrectos.

🧩 Elementos esenciales

• Scaffolding: generación de estructuras iniciales de proyectos mediante plantillas como Yeoman, Spring Initializr, dotnet new o Angular CLI.
• Generación dirigida por modelos (MDA): transformación de modelos abstractos en código mediante herramientas como EMF, Acceleo o Sparx Enterprise Architect.
• OpenAPI Generator: herramienta que genera clientes, servidores y documentación desde especificaciones OpenAPI de APIs HTTP.
• Javadoc: sistema de generación de documentación API en HTML a partir de comentarios estructurados en código Java.
• Doxygen: herramienta multiplenguaje para generar documentación a partir de comentarios y estructura del código fuente.
• Código regenerable: artefactos derivados de fuentes canónicas que no deben editarse manualmente para evitar pérdida de cambios en regeneraciones sucesivas.
• Procesadores de anotaciones: mecanismos como Lombok, MapStruct, Dagger 2 o Roslyn que generan código en tiempo de compilación.
• IA generativa: asistentes como Copilot, CodeWhisperer o Tabnine que producen código probabilístico requiriendo validación humana y control de seguridad.
• Documentación de API: especificaciones técnicas destinadas a consumidores de bibliotecas y servicios, generables mediante Javadoc, JSDoc o OpenAPI.
• Documentación de operación: manuales orientados a equipos de despliegue, monitorización y mantenimiento de sistemas en producción.

🧠 Recuerda

• Distingue siempre entre código generado editable y código regenerable inmutable que proviene de fuentes canónicas.
• La regeneración de código sobrescribe automáticamente cualquier cambio manual no reflejado en la especificación fuente.
• OpenAPI permite generar simultáneamente clientes, servidores y documentación de APIs HTTP a partir de un contrato único.
• Javadoc y Doxygen mantienen la documentación cercana al código, pero no corrigen comentarios erróneos o triviales.
• Los generadores deben versionarse y ejecutarse de forma reproducible en entornos controlados y auditables.
• El código generado por IA requiere revisión de seguridad, verificación de dependencias y control de licencias.
• Nunca introduzcas secretos, credenciales ni datos personales en servicios de IA generativa no autorizados.
• La documentación automática necesita criterios editoriales para garantizar su valor explicativo y utilidad real.
• Separa claramente el código manual del código generado en la estructura de directorios del proyecto.
• La calidad de la documentación generada depende exclusivamente de la calidad de los comentarios y contratos fuente.

3. Metodologías de desarrollo

3. Metodologías de desarrollo

🎯 Idea clave

• Las metodologías de desarrollo son marcos sistemáticos que organizan procesos, roles, prácticas y artefactos para construir y mantener software con calidad y sostenibilidad.
• Constituyen filosofías de trabajo que articulan personas, procesos y herramientas alrededor de objetivos comunes de predictibilidad y valor.
• En las Administraciones Públicas españolas, su elección trasciende lo técnico para convertirse en decisión organizativa vinculada al cumplimiento de principios constitucionales de eficiencia.
• No deben confundirse con herramientas tecnológicas, ya que determinan cómo se capturan requisitos, se planifica el trabajo y se gestionan los cambios.
• El ciclo de vida del software abarca fases secuenciales desde el análisis de requisitos hasta la retirada del sistema.
• La Estrategia TIC 2021-2025 y el Plan de Digitalización promueven explícitamente metodologías ágiles y cultura DevSecOps en la Administración General del Estado.

📚 Desarrollo

Definición fundamental. Las metodologías de desarrollo constituyen marcos sistemáticos para planificar, estructurar, ejecutar y controlar el proceso de creación, evolución y mantenimiento de sistemas informáticos. Representan auténticas filosofías de trabajo que coordinan personas, procesos, herramientas y entregables en torno a objetivos de calidad y sostenibilidad.

Naturaleza organizativa. Se configuran como conjuntos organizados de principios, procesos, prácticas, roles, artefactos y técnicas orientados a reducir incertidumbre, coordinar equipos, controlar riesgos y asegurar que el producto responda a necesidades reales. Determinan cómo se capturan requisitos, se diseña la solución, se implementa, se prueba y se entrega el software.

Distinción operativa. Una metodología no debe confundirse con las herramientas que la soportan. Plataformas de gestión de tareas, repositorios o sistemas de integración continua pueden apoyar una metodología, pero no la sustituyen. Un proyecto puede fracasar aunque use buenas tecnologías si su forma de trabajo no gestiona adecuadamente requisitos, comunicación y validación.

Ámbito público español. En las Administraciones Públicas, donde concurren exigencias de transparencia, control presupuestario e interoperabilidad, la elección metodológica impacta directamente en la prestación de servicios a la ciudadanía y en el cumplimiento de los principios de eficiencia y eficacia consagrados en el artículo 103 de la Constitución. Aunque Métrica v3 sigue siendo metodología oficial de referencia y aparece en pliegos, grandes ministerios y entidades como la AEAT o la Seguridad Social han incorporado Scrum, Kanban y DevOps.

Marcos ágiles y normativos. La Estrategia TIC de la Administración General del Estado para el periodo 2021-2025, así como el Plan de Digitalización de las Administraciones Públicas, promueven explícitamente metodologías ágiles, equipos producto y cultura DevSecOps. Organismos como el INCIBE y el CCN-CERT han integrado estas prácticas en sus guías y servicios.

Ciclo de vida y enfoques. El ciclo de vida incluye requisitos, diseño, construcción, pruebas, despliegue, operación, mantenimiento y retirada. Existen enfoques secuenciales como Cascada, útiles cuando los requisitos son estables, modelos iterativos e incrementales que entregan valor en ciclos sucesivos, y familias ágiles basadas en valores y principios como Scrum, Kanban y Extreme Programming.

Contratación pública. La Ley 9/2017 de Contratos del Sector Público admite cada vez más figuras compatibles con la entrega iterativa, como los contratos basados en acuerdos marco, las contrataciones por bolsas de horas o los servicios continuados, facilitando la adopción de metodologías flexibles.

🧩 Elementos esenciales

• Marco sistemático: Estructura completa de principios, procesos y prácticas para gestionar el desarrollo de software desde la concepción hasta la retirada.
• Ciclo de vida completo: Secuencia que abarca requisitos, diseño, construcción, pruebas, despliegue, operación, mantenimiento y retirada del sistema.
• Modelo en cascada: Enfoque secuencial donde cada fase se completa antes de iniciar la siguiente, útil cuando los requisitos son estables desde el inicio.
• Modelos iterativos e incrementales: Permiten entregar versiones parciales del producto y refinarlo mediante ciclos sucesivos que reducen la incertidumbre progresivamente.
• Metodologías ágiles: Familia de enfoques basada en valores y principios que priorizan la adaptabilidad y la colaboración, sin suponer ausencia de planificación.
• Scrum: Marco ligero que define responsabilidades, eventos y artefactos específicos para la gestión de proyectos complejos.
• Kanban: Sistema de gestión de flujo que visualiza el trabajo, limita el trabajo en curso y mejora continuamente mediante ajustes evolutivos.
• Extreme Programming (XP): Metodología que aporta prácticas técnicas específicas como desarrollo guiado por pruebas, refactorización e integración continua.
• DevOps: Enfoque cultural y técnico que une desarrollo y operaciones mediante automatización, colaboración, entrega continua y monitorización.
• Métrica v3: Metodología oficial de referencia en las Administraciones Públicas españolas que continúa apareciendo habitualmente en pliegos de contratación.
• DevSecOps: Evolución de DevOps que integra la seguridad desde las primeras fases del desarrollo, alineando los pipelines con prácticas de seguridad.

🧠 Recuerda

• Una metodología organiza procesos, roles, prácticas y artefactos para construir software que aporte valor con calidad y sostenibilidad.
• No confundir metodología con herramientas: la gestión adecuada de requisitos y riesgos es independiente de las tecnologías utilizadas.
• En las AAPP españolas, Métrica v3 es referencia oficial pero coexisten ya Scrum, Kanban y DevOps en ministerios y organismos clave.
• La Estrategia TIC 2021-2025 y el Plan de Digitalización promueven explícitamente metodologías ágiles y equipos producto.
• El ciclo de vida completo incluye desde el análisis de requisitos hasta la retirada final del sistema.
• Ágil no significa ausencia de planificación, sino adaptación continua basada en valores y principios definidos.
• Scrum establece un marco de gestión pero debe complementarse con prácticas técnicas de ingeniería de software.
• DevOps integra desarrollo y operaciones, mientras que DevSecOps añade la seguridad desde el inicio del pipeline.
• La contratación pública actual admite figuras compatibles con entrega iterativa como acuerdos marco y bolsas de horas.

4. Pruebas

4. Pruebas

🎯 Idea clave

• Las pruebas de software son actividades planificadas de verificación y validación destinadas a evaluar la calidad del sistema, detectar defectos y reducir riesgos antes de la entrega.
• La verificación determina si el producto se construyó correctamente respecto a especificaciones, mientras que la validación confirma si satisface las necesidades reales de uso previsto.
• Los niveles de prueba siguen el modelo en V: unitarias, integración, sistema y aceptación, cada uno asociado a una fase específica del desarrollo.
• Las pruebas no funcionales verifican atributos de calidad como rendimiento, carga, estrés, seguridad, accesibilidad, compatibilidad y recuperación ante fallos.
• Las metodologías actuales incluyen TDD, BDD y shift-left, priorizando la automatización en pipelines CI/CD y la distribución estratégica según la pirámide de Cohn.
• Las pruebas pueden demostrar la presencia de defectos, pero nunca su ausencia total, por lo que se priorizan según riesgo, criticidad y probabilidad de fallo.

📚 Desarrollo

Definición y limitación. Las pruebas son actividades sistemáticas que buscan obtener información sobre la calidad del software y aportar confianza antes de la puesta en producción. Sin embargo, como señaló Dijkstra, solo pueden mostrar la presencia de errores, nunca garantizar su ausencia total en sistemas no triviales.

Verificación frente a validación. La verificación responde si el producto se ha construido correctamente conforme a requisitos y diseños, mediante revisiones de código, análisis estático y pruebas técnicas. La validación responde si se ha construido el producto correcto para el usuario, comprobando que los trámites reales puedan completarse satisfactoriamente.

Nivel unitario. Las pruebas unitarias verifican la unidad mínima de código funcional mediante aislamiento completo mediante técnicas de mocking. Deben ser rápidas, deterministas y numerosas, utilizando herramientas como JUnit, TestNG, pytest, Jest o xUnit, junto con frameworks de dobles como Mockito, Moq o Sinon.

Niveles de integración y sistema. Las pruebas de integración verifican interacciones entre módulos, servicios, bases de datos y APIs, detectando errores de contrato, formato o comunicación. Las pruebas de sistema evalúan el conjunto completo en entornos representativos, comprobando flujos completos, configuración, rendimiento y comportamiento extremo.

Pruebas de aceptación. Este nivel valida que el sistema satisface necesidades de usuarios, negocio o administración, pudiendo vincularse en proyectos públicos a pliegos, criterios de recepción, normativa, accesibilidad e interoperabilidad.

Tipos por propósito. Las pruebas funcionales comprueban que cada característica hace lo que debe hacer. Las no funcionales evalúan atributos de calidad mediante herramientas específicas: rendimiento con JMeter o Gatling, accesibilidad con axe o Lighthouse, y seguridad mediante SAST, DAST o pruebas de intrusión.

Metodologías y estrategia. TDD propone escribir tests antes que el código siguiendo el ciclo rojo-verde-refactor. BDD utiliza lenguaje Gherkin para alinear negocio y desarrollo. La pirámide de Cohn recomienda una base amplia de tests unitarios, una capa intermedia de integración y un mínimo de tests end-to-end, automatizándolos en CI/CD como procesos aislados, deterministas e idempotentes.

🧩 Elementos esenciales

• Pruebas unitarias: Verifican funciones, métodos o clases aisladas mediante mocks, siendo rápidas y deterministas.
• Pruebas de integración: Detectan errores de contrato, configuración y comunicación entre componentes que individualmente funcionan.
• Pruebas de sistema: Evalúan el comportamiento completo en entornos realistas, incluyendo rendimiento, seguridad y compatibilidad.
• Pruebas de aceptación: Confirman la satisfacción de necesidades del usuario final y criterios de recepción contractual.
• Verificación: Proceso de comprobar la conformidad respecto a especificaciones técnicas mediante revisiones y análisis estático.
• Validación: Proceso de confirmar la adecuación al propósito real de uso y necesidades del negocio.
• Pruebas de carga: Comportamiento del sistema bajo la demanda operativa esperada.
• Pruebas de estrés: Evaluación más allá de los límites normales hasta provocar fallos para conocer los puntos de ruptura.
• Pruebas de estabilidad (soak): Ejecución prolongada durante horas o días para detectar fugas de memoria o degradación gradual.
• Pruebas de accesibilidad: Verificación del cumplimiento de criterios para personas con discapacidad mediante herramientas como axe, WAVE o Pa11y.
• Pirámide de Cohn: Estrategia de distribución con base unitaria amplia, integración intermedia y capa superior mínima de E2E.
• Cobertura de código: Métrica orientativa del 70-80% que mide el código ejecutado durante pruebas, necesaria pero no suficiente para calidad.

🧠 Recuerda

• Las pruebas muestran la presencia de defectos, no su ausencia.
• Verificar es construir correctamente; validar es construir el producto correcto.
• Las unitarias requieren aislamiento total mediante dobles de prueba como Mockito o Moq.
• Las de integración detectan fallos reales que surgen al combinar componentes.
• El modelo en V asocia cada fase de construcción con su nivel de prueba correspondiente.
• Las no funcionales incluyen rendimiento, estrés, spike, volumen, seguridad y recuperación.
• TDD sigue el ciclo rojo-verde-refactor antes de escribir el código de producción.
• La pirámide prioriza tests rápidos y baratos sobre tests costosos de interfaz.
• Cobertura del 100% no garantiza ausencia de errores lógicos.
• Los tests en CI/CD deben ser deterministas, rápidos, aislados e idempotentes.

5. Programas para control de versiones

5. Programas para control de versiones

🎯 Idea clave

• Los programas de control de versiones registran, organizan y permiten recuperar la evolución de archivos conservando el historial completo de cambios y facilitando el trabajo simultáneo.
• Un sistema de control de versiones no equivale a una copia de seguridad ni a una plataforma colaborativa completa, pues añade funcionalidades específicas de historial estructurado y gestión de cambios.
• Los sistemas pueden ser centralizados, con un repositorio principal único, o distribuidos, permitiendo que cada colaborador disponga de un clon completo con todo el historial para trabajo local.
• Git es el sistema distribuido dominante en el desarrollo moderno, mientras que Subversion mantiene presencia en entornos centralizados heredados y Perforce destaca en repositorios de gran escala.
• Herramientas como el tag permiten etiquetar versiones, blame identifica el autor de cada línea, log muestra historiales filtrados y diff compara estados entre ramas o commits.
• Los cambios se agrupan en commits o revisiones que representan unidades lógicas de modificación con alcance claro y mensaje comprensible para facilitar la trazabilidad.

📚 Desarrollo

Definición fundamental. Un sistema de control de versiones es un programa o conjunto de programas cuya función esencial consiste en registrar y gestionar los cambios que se producen sobre uno o varios archivos a lo largo del tiempo, permitiendo recuperar versiones anteriores, identificar quién hizo cada modificación, cuándo se hizo y por qué.

Diferencia con copia de seguridad. Aunque ambos preservan datos, el control de versiones añade historial estructurado, cambios atómicos, ramas, fusiones, etiquetas y comparación de diferencias, mientras que una copia de seguridad busca solo recuperar datos ante pérdida o fallo sin gestión histórica.

Tipología de sistemas. Los sistemas centralizados utilizan un único repositorio principal donde se almacena el historial completo, mientras que los distribuidos permiten que cada colaborador disponga de un clon completo del repositorio con todo su historial, facilitando el trabajo local sin conexión.

Sistemas principales. Git, como sistema distribuido, domina el desarrollo moderno por sus ramas ligeras, ecosistema e integración con plataformas. Subversion es centralizado y mantiene presencia en entornos heredados o con necesidades de control central fuerte. Mercurial es distribuido y conceptualmente cercano a Git, aunque menos extendido actualmente. Perforce Helix Core destaca en repositorios grandes, activos binarios, bloqueo y equipos de gran escala.

Gestión de cambios. Los cambios se agrupan en commits o revisiones que representan unidades lógicas de modificación. Un commit adecuado posee alcance claro y mensaje comprensible, facilitando la revisión, el diagnóstico y la reversión cuando sea necesario.

Resolución de conflictos. El control de versiones gestiona situaciones donde dos cambios afectan a la misma parte de un archivo. Algunas fusiones se resuelven automáticamente, pero otras requieren intervención humana para comprender la intención de ambos cambios y construir una solución coherente.

Comandos esenciales. Herramientas como el tag permiten etiquetar versiones específicas, blame identifica qué autor introdujo cada línea de código, log muestra el historial con múltiples opciones de filtrado, y diff compara estados del repositorio, ramas o commits entre sí.

🧩 Elementos esenciales

• VCS: programa que registra cambios sobre archivos permitiendo recuperar versiones anteriores y mantener historial completo.
• Commit: unidad lógica de modificación que agrupa cambios con alcance claro y mensaje descriptivo.
• Sistema centralizado: utiliza un repositorio principal único donde se almacena todo el historial.
• Sistema distribuido: cada usuario posee una copia completa del repositorio con todo su historial para trabajo local.
• Git: sistema distribuido dominante por sus ramas ligeras, ecosistema amplio e integración con plataformas.
• Subversion: sistema centralizado que mantiene presencia en entornos heredados con control central fuerte.
• Mercurial: sistema distribuido conceptualmente cercano a Git pero menos extendido actualmente.
• Perforce Helix Core: destacado para repositorios grandes, activos binarios, bloqueo y equipos de gran escala.
• Branch: línea de desarrollo separada que permite modificar el código sin afectar la versión principal.
• Tag: etiqueta que marca versiones específicas o puntos importantes en el historial.
• Merge: operación de fusión de cambios entre diferentes ramas o líneas de desarrollo.
• Conflict: situación que requiere resolución manual cuando dos cambios afectan simultáneamente la misma porción de código.

🧠 Recuerda

• Un programa de control de versiones registra cambios, conserva historial y permite recuperar, comparar, ramificar y fusionar versiones.
• Control de versiones no es lo mismo que copia de seguridad ni que plataforma colaborativa completa.
• Los sistemas centralizados usan un repositorio principal; los distribuidos permiten clones con historial y trabajo local.
• Git es distribuido y domina el desarrollo moderno por ramas ligeras, ecosistema e integración con plataformas.
• Subversion es centralizado y mantiene presencia en entornos heredados o con control central fuerte.
• Mercurial es distribuido y conceptualmente cercano a Git, aunque menos extendido actualmente.
• Perforce Helix Core destaca en repositorios grandes, activos binarios, bloqueo y equipos de gran escala.
• Branch, commit, tag, merge, fetch, pull, push, checkout y conflict son conceptos esenciales.
• Las ramas protegidas, revisiones y pruebas convierten el control de versiones en control de calidad.
• No deben versionarse secretos; si se filtran, deben revocarse y tratarse como incidente.

6. Plataformas de desarrollo colaborativo de software

6. Plataformas de desarrollo colaborativo de software

🎯 Idea clave

• Las plataformas de desarrollo colaborativo son entornos integrados, disponibles como SaaS o auto-hospedables, que unifican control de versiones, gestión de incidencias, revisiones de código, pipelines CI/CD y documentación.
• Git constituye el sistema de control de versiones distribuido, mientras que GitHub, GitLab, Bitbucket y Azure DevOps son plataformas colaborativas construidas sobre repositorios.
• Estas herramientas se han convertido en el sistema nervioso de las organizaciones que producen software, incluidas las Administraciones Públicas españolas.
• En el ámbito público español, organismos despliegan GitHub Enterprise o GitLab self-managed según criterios de soberanía, presupuesto y ecosistema tecnológico.
• El Centro de Transferencia de Tecnología opera como catálogo oficial de aplicaciones reutilizables alineado con el Esquema Nacional de Interoperabilidad.

📚 Desarrollo

Concepto integrador. Las plataformas de desarrollo colaborativo constituyen entornos unificados que concentran funcionalidades esenciales: control de versiones distribuido, gestión de issues, revisiones de código mediante pull requests o merge requests, pipelines de integración y despliegue continuo, wikis, páginas estáticas, registros de paquetes y funciones de seguridad avanzada. Su disponibilidad como SaaS o solución auto-hospedable permite adaptarse a distintas necesidades de infraestructura y soberanía de datos.

GitHub y GitLab. GitHub, creado en 2008 y adquirido por Microsoft en 2018, supera los cien millones de usuarios y representa el referente mundial para proyectos de código abierto. Ofrece servicios de revisión de código, issues, GitHub Actions para CI/CD, GitHub Packages y Copilot. GitLab proporciona una plataforma equivalente tanto en versión SaaS como autoalojada, destacando por integrar CI/CD desde su concepción original.

Bitbucket y Azure DevOps. Bitbucket, propiedad de Atlassian, se beneficia de integración estrecha con Jira para gestión ágil y Confluence para documentación, incluyendo Bitbucket Pipelines como motor de CI/CD. Azure DevOps, heredera de Team Foundation Server, agrupa cinco servicios diferenciados: Azure Repos con soporte para Git y TFVC, Azure Pipelines multiplataforma con definiciones en YAML y modo clásico, Azure Boards con plantillas Scrum, Agile y CMMI, Azure Test Plans para pruebas manuales y exploratorias, y Azure Artifacts como registro de paquetes.

Opciones complementarias. Para autoalojamiento ligero existen Gitea, Forgejo como fork comunitario de Gitea, y el veterano Gogs. Los grandes proveedores cloud ofrecen AWS CodeCommit y Google Cloud Source Repositories. SourceForge mantiene su relevancia histórica como pionero en el hospedaje de proyectos libres, aunque su cuota de mercado actual es menor.

Ámbito público español. El Centro de Transferencia de Tecnología, alojado en el Portal de Administración Electrónica, opera como catálogo oficial de aplicaciones y soluciones reutilizables por las distintas administraciones, incluyendo códigos, manuales y documentación. Esta iniciativa se alinea con los principios de reutilización del Esquema Nacional de Interoperabilidad.

Políticas de reutilización. Distintos organismos públicos han desplepado GitHub Enterprise o GitLab self-managed para sus equipos internos, atendiendo a preferencias de soberanía, presupuesto y ecosistema existente. La política de reutilización de software en la Administración General del Estado promueve la publicación bajo licencias compatibles y el aprovechamiento de soluciones existentes antes de desarrollar nuevas. Ejemplos de software liberado incluyen AutoFirma, el cliente Cl@ve, INSIDE para gestión documental, ARCHIVE para archivo electrónico y GEISER para registro.

🧩 Elementos esenciales

• Plataforma colaborativa: entorno integrado que agrupa repositorios, revisión de código, gestión de incidencias, documentación, automatización, permisos y trazabilidad.
• Git vs Plataformas: Git es el sistema de control de versiones distribuido; GitHub, GitLab, Bitbucket y Azure DevOps son plataformas colaborativas construidas sobre repositorios.
• Pull/Merge Requests: mecanismos para proponer, revisar, probar y fusionar cambios de código entre ramas de forma controlada.
• Issues y tableros: sistemas para gestionar tareas, errores, requisitos y seguimiento del trabajo del equipo de desarrollo.
• CI/CD integrado: pipelines que automatizan compilación, pruebas, análisis, generación de artefactos y despliegues continuos dentro del flujo de trabajo.
• GitHub: plataforma líder en código abierto con más de cien millones de usuarios, propiedad de Microsoft desde 2018, que incluye Actions y Copilot.
• GitLab: ofrece versiones SaaS y autoalojadas con CI/CD nativo integrado desde su concepción inicial.
• Bitbucket: integración nativa con Jira y Confluence de Atlassian, incluyendo Pipelines para CI/CD.
• Azure DevOps: suite de Microsoft con cinco servicios específicos: Repos, Pipelines, Boards, Test Plans y Artifacts.
• Seguridad: protección mediante ramas protegidas, revisores obligatorios, CODEOWNERS, checks automatizados y gestión de secretos y tokens.
• CTT: Centro de Transferencia de Tecnología que cataloga soluciones reutilizables para administraciones públicas españolas según el ENI.
• Software libre AGE: ejemplos como AutoFirma, cliente Cl@ve, INSIDE, ARCHIVE y GEISER disponibles para reutilización por otros organismos.

🧠 Recuerda

• Una plataforma colaborativa integra múltiples herramientas en un único entorno SaaS o auto-hospedable.
• GitHub, GitLab, Bitbucket y Azure DevOps son las principales opciones del mercado actual para equipos profesionales.
• Azure DevOps hereda funcionalidades de Team Foundation Server y mantiene soporte para Git y el histórico TFVC.
• El CTT es el punto de referencia oficial para la reutilización de software en la Administración General del Estado.
• Las administraciones españolas despliegan soluciones Enterprise o self-managed según necesidades de soberanía y presupuesto.
• AutoFirma, Cl@ve, INSIDE, ARCHIVE y GEISER son ejemplos concretos de software liberado por la AGE.
• Las plataformas conectan el código fuente con sistemas de trazabilidad, auditoría y gestión avanzada de permisos.
• La elección de plataforma debe considerar seguridad, costes, integración con ecosistemas existentes y necesidades específicas del equipo.
• CI/CD integrado permite automatizar todo el flujo desde el commit hasta el despliegue en producción.
• La documentación debe mantenerse actualizada y distinguirse entre conocimiento temporal y documentación estable del proyecto.