2.10 Gestión de configuración de software

Resumen y motivación

La gestión de configuración de software (GCS) es la disciplina que identifica los componentes de un sistema de software, controla cómo cambian, registra el estado de cada modificación y verifica que lo que se construyó y se entregó coincida con lo que se pretendía. Responde una pregunta que en apariencia es simple pero se vuelve difícil a gran escala: ¿qué contiene exactamente este lanzamiento, cómo llegó a ser lo que es y quién lo aprobó? El SWEBOK (Cuerpo de Conocimiento de Ingeniería de Software) considera la GCS un área de conocimiento fundamental por una razón clara: toda actividad de ingeniería necesita una configuración estable y conocida sobre la que trabajar.

En un equipo grande, la GCS es el tejido conectivo que mantiene coherentes miles de piezas en movimiento. El código fuente, las librerías, las imágenes de contenedor, las definiciones de infraestructura, los datos de configuración, la documentación y los artefactos de prueba cambian cada uno a su propio ritmo, y un sistema entregado es una combinación concreta de versiones concretas de todo ello. Sin una gestión de configuración deliberada, esa combinación es desconocida y no puede reproducirse. No es posible recrear un lanzamiento anterior, rastrear un defecto hasta el cambio que lo originó ni afirmar con certeza qué está en ejecución en producción.

En entornos empresariales y de la administración pública, las stakes se elevan. Los programas regulados y del sector público deben demostrar que los cambios fueron autorizados, revisados y registrados; que una construcción entregada se remonta a requisitos y código fuente aprobados; y que nada entró en el sistema fuera de control. Aquí, la GCS es tanto un sistema de evidencias como uno de ingeniería. El control de versiones (capítulo 2.6) gestiona el historial del código fuente; la GCS gobierna toda la configuración y el proceso controlado mediante el cual esta cambia. Está estrechamente ligada a la infraestructura como código (capítulo 8.2), los flujos de entrega (capítulo 8.1) y la auditoría y la garantía (capítulo 10.2).

Principios fundamentales

Todo lo que determina el comportamiento del sistema es un elemento de configuración bajo control, no solo el código fuente.
Una línea base es un punto de referencia conocido y acordado; los cambios se realizan frente a las líneas base de forma deliberada, no improvisada.
El cambio se controla y se registra, no se impide; el objetivo es un cambio autorizado y trazable.
El registro de estado de configuración permite responder siempre qué contiene una configuración y cuál es su historial de cambios.
Las auditorías verifican que el sistema construido y entregado coincide con la configuración registrada y con los requisitos aprobados.
La reproducibilidad no es negociable: cualquier versión lanzada debe poder recompilarse a partir de entradas controladas.
Automatizar la identificación, el registro y la verificación; la contabilidad manual no escala y no sobrevive a una auditoría.

Recomendaciones

Definir el proceso de GCS y asignar responsabilidad

Redactar un plan de GCS que especifique qué está bajo control de configuración, cómo se identifican los elementos, cómo se proponen y aprueban los cambios y cómo se registra y audita el estado. Asignar una responsabilidad clara, como un gestor de configuración o un equipo designado como responsable, para que la GCS no sea responsabilidad de todos y, por tanto, de nadie. Escalar el proceso según el riesgo: una herramienta interna pequeña necesita un control ligero, mientras que un sistema crítico para la seguridad o regulado exige comités formales y registros formales. Anclar el plan en una norma reconocida como la IEEE 828 para que auditores y socios puedan seguirlo.

Identificar elementos de configuración y establecer líneas base

Enumerar los elementos de configuración que determinan el comportamiento del sistema: código fuente, dependencias, scripts de compilación, imágenes de contenedor, definiciones de infraestructura, datos de configuración, esquemas y documentos clave. Asignar a cada uno un identificador estable y un esquema de versionado. Establecer líneas base en puntos significativos (una versión publicada, un conjunto de requisitos aprobado, una construcción certificada) para contar con una referencia acordada frente a la cual cambiar y a la que regresar. Una línea base es inmutable: una vez declarada, no se edita. Solo se reemplaza por una nueva línea base creada a través del proceso de cambios.

Controlar el cambio mediante un proceso definido y los comités adecuados

Encaminar los cambios a los elementos controlados por una vía definida: propuesta, evaluación de impacto, aprobación, implementación y verificación. Para elementos de mayor riesgo, utilizar un comité de control de cambios (CCB, por sus siglas en inglés) que sopesa coste, riesgo y plazo antes de autorizar un cambio. Dimensionar el comité adecuadamente: una puerta automatizada ligera para cambios rutinarios de código, y un CCB formal interfuncional para los cambios que afecten a líneas base, interfaces o comportamientos regulados. Registrar cada decisión y el razonamiento que la sustenta, y vincular las decisiones de configuración significativas a los registros de decisión (capítulo 1.6) para que el razonamiento perdure.

Mantener el registro de estado de configuración

Conservar un registro preciso y consultable de cada elemento de configuración: su versión actual, a qué línea base pertenece y las solicitudes de cambio aplicadas a él. Este registro de estado es lo que permite responder, en cualquier momento, qué contiene un lanzamiento y cómo llegó a ser lo que es. Generar el registro automáticamente a partir de las herramientas de referencia (control de versiones, flujo de entrega, registro de artefactos) en lugar de mantener una hoja de cálculo paralela que se desvía de la realidad. Este registro es la columna vertebral de la trazabilidad del requisito al cambio, del cambio a la construcción y de la construcción a la implementación.

Realizar auditorías de configuración

Verificar dos cosas con regularidad. Una auditoría funcional de configuración confirma que la configuración se comporta según lo que especifican sus requisitos. Una auditoría física de configuración confirma que los artefactos entregados coinciden con la configuración registrada: que la construcción proviene del código fuente y de las dependencias registradas y no contiene nada sin registro. Automatizar la mayor parte de este proceso: las compilaciones reproducibles, las sumas de verificación de artefactos, las listas de materiales de software (SBOM, por sus siglas en inglés) y los atestiguados de procedencia convierten la auditoría en una verificación continua en lugar de una inspección manual.

Gestionar los lanzamientos y la entrega como eventos controlados

Tratar un lanzamiento como una línea base específica e identificada, entregada mediante un proceso repetible. Versionar los lanzamientos de forma explícita, producir un manifiesto o una lista de materiales que describa exactamente qué incluye, y registrar la correspondencia entre lanzamiento, revisión de código fuente y artefacto implementado. Firmar y verificar la integridad de los artefactos publicados para que cualquier parte aguas abajo pueda comprobar su integridad. Vincular la gestión de lanzamientos al flujo de entrega (capítulo 8.1) para que la promoción entre entornos sea, en sí misma, controlada, registrada y reversible.

Elegir e integrar las herramientas de GCS

Apoyarse en herramientas que automatizan la identificación, el control, el registro y la auditoría, en lugar de depender solo de la disciplina: control de versiones para el código fuente, registros de artefactos e imágenes para los binarios, un flujo de entrega inmutable para las compilaciones, infraestructura como código para los entornos y herramientas de dependencias y SBOM para la procedencia. Conectarlas de modo que un único cambio fluya trazablemente desde el envío hasta el lanzamiento implementado. Lo que se busca es una cadena de herramientas en la que el registro de configuración sea un subproducto del trabajo, no una tarea burocrática aparte.

Compromisos: ventajas e inconvenientes

Decisión	Ventajas	Inconvenientes
Comités formales de control de cambios	Fuerte trazabilidad de autorizaciones y auditoría; el riesgo se evalúa antes de cambiar	Menor cadencia; sobrecarga si se aplica a cambios rutinarios
Puertas automatizadas ligeras	Flujo rápido; bajo coste de mantenimiento; escala a muchos cambios	Menor fiabilidad para líneas base de alto riesgo; menor deliberación
Líneas base estrictas e inmutables	Puntos de referencia reproducibles y auditable	Exigen disciplina y herramientas; generan fricción si se usan en exceso
Registro de estado automatizado	Registro preciso y siempre actualizado; listo para auditoría	Inversión inicial de herramientas e integración
Registros de configuración manuales	Simples de iniciar; no requieren herramientas	Se desvían de la realidad; fallan a escala y bajo auditoría

El compromiso central es entre control y fluidez. Un control de cambios exhaustivo ofrece una garantía sólida pero ralentiza la entrega. Un control ligero fluye rápido pero debilita la trazabilidad. La respuesta no es elegir uno u otro de forma global, sino estratificar el control por el riesgo: automatizar los cambios rutinarios a través de puertas rápidas y reservar los comités formales y las líneas base inmutables para los elementos donde la autorización y la auditabilidad realmente importan. El segundo compromiso es entre la inversión inicial en herramientas y el coste clerical y el riesgo de auditoría continuos. La contabilidad automatizada cuesta más de instalar y mucho menos de sostener en el tiempo.

Preguntas para debatir con el equipo

¿Qué pertenece exactamente a nuestra lista de elementos de configuración y quién decide cuando aparece algo nuevo? La GCS solo funciona si la lista de elementos controlados coincide con el conjunto de cosas que realmente determinan el comportamiento, y en un sistema grande ese conjunto es más amplio de lo que la mayoría de los equipos cree: código fuente, dependencias, scripts de compilación, imágenes de contenedor, definiciones de infraestructura, esquemas, banderas de función y los datos de configuración que silenciosamente cambian lo que el software hace. Si nadie es responsable de la lista, esta se desactualiza, y el elemento que provocó un incidente en producción resulta ser el único que nadie pensó en controlar. Traer al equipo el inventario actual y buscar los elementos que determinan el comportamiento y faltan de la lista. Asignar un responsable concreto (un gestor de configuración o un equipo designado) para que añadir un elemento nuevo sea una decisión deliberada, no un accidente, porque una GCS que es responsabilidad de todos es responsabilidad de nadie.
¿Podemos demostrar que un artefacto implementado proviene del código fuente y del flujo que creemos que lo originaron, y resistiría esa prueba un intento de manipulación? La reproducibilidad y la trazabilidad son el núcleo de la GCS, y la pregunta en su forma más exigente es si se puede enlazar el binario en ejecución con un envío concreto y una ejecución de compilación específica, con evidencia, no con una afirmación. En un sistema regulado o de alto valor, esta es también la defensa de la cadena de suministro: atestiguados de procedencia firmados, sumas de verificación de artefactos y una lista de materiales de software transforman el «estamos bastante seguros» en algo que un auditor o un responsable de incidentes puede verificar. Traer el último lanzamiento e intentar recorrerlo hacia atrás, desde el artefacto implementado hasta el cambio aprobado. Si algún eslabón es una afirmación manual en lugar de un enlace registrado y verificable, ahí es donde un atacante o un error involuntario puede colar algo sin que nadie lo note, y cerrarlo significa integrar la firma y la procedencia en el flujo de entrega para que el registro sea un subproducto de la propia entrega.
¿Hay alguien que pueda editar un lanzamiento en este momento, y qué implicaciones tendría eso para nuestra capacidad de fiarnos de él? Una línea base solo es útil si es inmutable: en el instante en que «el lanzamiento» puede modificarse a posteriori, ya no se puede reproducir ni confiar en ella como referencia, y toda auditoría posterior se convierte en arqueología. El fallo clásico es la configuración editada directamente en producción o una etiqueta movida en silencio, que es precisamente el atajo que parece inocuo y hace imposible reconstruir un lanzamiento más adelante. Traer a la reunión la respuesta honesta: ¿quién tiene acceso para modificar una línea base implementada sin pasar por el proceso de cambios, y ha ocurrido? La solución es hacer que las líneas base sean genuinamente inmutables y encaminar cada cambio por la vía de propuesta, evaluación de impacto, aprobación y verificación, estratificando la rigidez para que los cambios rutinarios fluyan por puertas automatizadas rápidas mientras los cambios en líneas base y regulados pasan por un comité.
¿Nuestro registro de estado de configuración se genera automáticamente a partir de nuestras herramientas de referencia o se mantiene a mano, y cuánto se ha desviado de lo que realmente está implementado? El registro de estado es el documento que permite responder, en cualquier momento, qué contiene un lanzamiento y cómo llegó a ser lo que es, y en un sistema grande ese registro solo es fiable si emerge del propio trabajo en lugar de teclearse en una hoja de cálculo paralela. La tensión es que un registro manual parece barato de iniciar y flexible, mientras que automatizarlo implica integrar el control de versiones, el flujo de entrega y el registro de artefactos para que el registro sea un subproducto de la entrega. Traer el registro que se usa hoy, elegir tres lanzamientos recientes al azar y comprobar si las versiones, líneas base y solicitudes de cambio registradas coinciden con lo que las herramientas indican que se implementó. En un programa empresarial o de la administración pública, un registro de estado que diverge de la realidad no es un problema de orden, es una hallazgo de auditoría a la espera de producirse, porque un auditor que detecta una sola brecha deja de confiar en todo el conjunto y exige que se reconstruya a mano.
¿Nuestro control de cambios está estratificado por el riesgo, o el mismo nivel de protocolo rige cada cambio con independencia de lo que afecte? El control y la fluidez se tensan entre sí: un comité de control de cambios sopesa coste, riesgo y plazo antes de autorizar un cambio, pero aplicar ese protocolo a un ajuste rutinario de código solo añade demora, mientras que empujar una línea base compartida o un flujo de pago regulado por una puerta automatizada rápida elimina la deliberación justo donde más se necesita. Los modos de fallo son simétricos: una uniformidad excesivamente pesada que la gente aprende a esquivar, o una uniformidad excesivamente laxa que deja pasar un cambio de alto riesgo sin examen. Traer una muestra de los cambios del último trimestre clasificados por lo que cada uno afectó, y comprobar si la rigurosidad que recibió realmente correspondió a su riesgo. En un entorno regulado o de la administración pública, especificar qué clases de elementos deben llegar a un comité interfuncional y cuáles pueden fluir por puertas automatizadas, y registrar esa estratificación de forma explícita, porque «usamos criterio» no es un control que un auditor o un organismo de supervisión pueda verificar.
¿Cuándo realizamos por última vez una auditoría funcional y una física de configuración, y cuánto de la evidencia sería un registro vivo en lugar de una reconstrucción? Una auditoría funcional de configuración confirma que el sistema se comporta según lo que especifican sus requisitos, y una auditoría física confirma que los artefactos entregados coinciden con la configuración registrada y no contienen nada sin registro; omitirlas es confiar en que las líneas base y el registro de estado son honestos sin comprobarlo nunca. La tensión es el coste: las auditorías manuales son lentas y laboriosas, que es precisamente por lo que los equipos las posponen, y la salida es automatizar las comprobaciones con compilaciones reproducibles, sumas de verificación de artefactos, listas de materiales de software y atestiguados de procedencia, de modo que la verificación se vuelva continua. Traer el lanzamiento más reciente e intentar producir, sobre la marcha, la trazabilidad de requisito a cambio a construcción a implementación y la prueba de artefacto a código fuente. Para programas empresariales y de la administración pública, esa cadena de evidencias es lo que la certificación y la supervisión exigen, de modo que la pregunta honesta es si la auditoría de mañana se respondería con registros que ya se tienen o con un ejercicio de arqueología que no se puede permitir.

Perspectiva por sector

Emprendimiento. Mantener la GCS ligera pero real. Poner el código fuente, las definiciones de infraestructura y los datos de configuración bajo control de versiones, y hacer que cada lanzamiento sea una construcción etiquetada producida por un único flujo en lugar de un artefacto ensamblado a mano. Saltarse los comités de control de cambios y las líneas base formales, que son un lujo innecesario a esa escala, pero jamás permitir que nadie edite la configuración directamente en producción, porque ese solo atajo es lo que hace imposible reproducir un lanzamiento cuando un cliente reporta un error el martes siguiente.

Pequeña empresa. Sin gestor de configuración y con un presupuesto ajustado, apoyarse en herramientas que ofrecen GCS casi de regalo: una plataforma de control de versiones alojada, su flujo de entrega integrado y un registro de artefactos, para que el registro de configuración sea un subproducto y no un puesto que hay que cubrir. Adquirir esta capacidad embebida en herramientas que ya se pagan en lugar de construir un proceso a medida. Destinar la atención escasa a los dos hábitos que más importan: lanzamientos etiquetados reproducibles y mantener la configuración que cambia el comportamiento fuera de ediciones manuales en producción.

Gran empresa. El problema es la coherencia entre muchos equipos: un plan de GCS compartido, una taxonomía común de elementos de configuración, un control de cambios estratificado y un registro de estado generado automáticamente a partir del control de versiones, el registro de artefactos y el flujo de entrega. Reservar los comités formales de control de cambios y las líneas base inmutables para la plataforma compartida y los flujos regulados, dejar que los cambios rutinarios fluyan por puertas automatizadas y estandarizar la procedencia firmada y las SBOM para que el lanzamiento de cualquier equipo pueda rastrearse y cualquier auditor pueda consultar un registro vivo en lugar de encargar una reconstrucción.

Sector público. Las normas de contratación, la transparencia y la rendición de cuentas pública dan forma al proceso. Seguir un plan de GCS formal alineado con una norma reconocida como la IEEE 828, establecer líneas base de los elementos de configuración en hitos contractuales y encaminar cada cambio a una línea base controlada por un comité que registre el impacto, la decisión y la justificación. Exigir que los artefactos entregados sean reproducibles a partir de entradas controladas, verificados con sumas de control y trazables de extremo a extremo, desde el requisito aprobado hasta la construcción entregada, porque esa cadena documentada de evidencias es exactamente lo que la certificación, la auditoría y la supervisión pública exigen.

Ejemplos

Emprendimiento. Un emprendimiento de seis personas mantiene su GCS ligera pero real: el código fuente, las definiciones de infraestructura y los datos de configuración viven todos bajo control de versiones, y cada lanzamiento es una construcción etiquetada y versionada producida por el mismo flujo en lugar de ensamblada a mano. Cuando un cliente reporta un error que apareció el martes pasado, rastrean el artefacto implementado hasta el envío exacto en minutos, en lugar de adivinar. Se saltan los comités de control de cambios y las líneas base formales, que a su escala serían un exceso, pero se niegan a permitir que nadie edite la configuración directamente en producción, porque ese atajo único es lo que hace imposible reproducir un lanzamiento después.

Gran empresa. Una gran empresa de servicios financieros somete todos los artefactos desplegables, las definiciones de infraestructura y los datos de configuración a control de configuración. Cada lanzamiento es una línea base inmutable y versionada con una lista de materiales de software generada automáticamente, y cada artefacto implementado lleva un atestiguado de procedencia firmado que lo enlaza con una revisión de código fuente y una ejecución de flujo específicas. Los cambios rutinarios de aplicación fluyen por puertas automatizadas en el flujo, mientras que los cambios en líneas base de plataforma compartida o en flujos de pago regulados pasan por un comité de control de cambios. El registro de estado se genera automáticamente a partir del control de versiones, el registro de artefactos y el flujo de entrega, para que los auditores consulten un registro vivo en lugar de solicitar una reconstrucción.

Sector público. Un programa de defensa sigue un plan de GCS formal alineado con la IEEE 828. Los elementos de configuración se listan y se establecen en líneas base en hitos contractuales, y un comité de control de cambios autoriza cada cambio a una línea base controlada, registrando el impacto, la decisión y la justificación. Las auditorías funcionales de configuración confirman que el sistema entregado cumple los requisitos especificados, y las auditorías físicas confirman que los artefactos entregados coinciden exactamente con la configuración registrada. Los lanzamientos son reproducibles a partir de entradas controladas, verificados con sumas de control y trazables de extremo a extremo, desde el requisito aprobado, a través de la solicitud de cambio, hasta la construcción entregada, que es exactamente la cadena de evidencias que la certificación y la supervisión exigen.

Justificación económica: motivaciones, retorno de la inversión y coste total de propiedad

La GCS existe para controlar el riesgo y el coste a lo largo de la vida del sistema. El retorno se materializa en la reproducibilidad y la trazabilidad: se puede recrear cualquier lanzamiento, rastrear defectos hasta los cambios que los causaron y responder a preguntas de auditoría con registros en lugar de arqueología. Eso reduce el tiempo de diagnóstico de incidentes, disminuye el coste y la duración de las auditorías y previene la clase costosa de fallo en la que nadie puede decir qué está en ejecución ni cómo reconstruirlo.

El coste total de propiedad favorece la automatización. Los registros de configuración manuales son baratos de iniciar y caros de mantener en el tiempo, y fallan justo cuando más se necesitan, durante un incidente o una auditoría, porque se han desviado de la realidad. La identificación, el registro y la auditoría automatizados cuestan más al principio pero convierten el registro de configuración en un subproducto casi gratuito del flujo de entrega. Para presentar el caso ante la dirección, enmarcar la GCS como el control que hace reproducibles los lanzamientos y auditables los cambios, y ponderarlo contra el coste de lanzamientos irreproducibles, auditorías prolongadas y el riesgo de incumplimiento por cambios sin control.

Antipatrones y trampas

Configuración por conocimiento tribal: el contenido real de un lanzamiento reside solo en la cabeza de un ingeniero, no en ningún registro.
Líneas base mutables: «el lanzamiento» se edita sobre la marcha, de modo que ya no puede reproducirse ni fiarse de él como referencia.
Datos de configuración sin control: el código está bajo control de versiones, pero la configuración que modifica su comportamiento se edita de forma improvisada en producción.
Teatro de control de cambios: un comité que aprueba todo por inercia, añadiendo demora sin añadir un examen real.
Registro de estado manual: una hoja de cálculo de versiones que se desvía en silencio de lo que realmente está implementado.
Compilaciones irreproducibles: lanzamientos que no pueden reconstruirse a partir de entradas controladas, de modo que las auditorías y las reconstrucciones se convierten en conjeturas.
Lanzamientos intrazables: sin correspondencia entre el artefacto implementado y la revisión de código fuente, la solicitud de cambio y la aprobación.

Modelo de madurez

Nivel 1 (Iniciar): la GCS es ad hoc y reactiva. Solo el código fuente está bajo control; los lanzamientos se ensamblan a mano; no hay líneas base, no hay registro fiable de lo que está implementado y no hay forma de reproducir una construcción pasada.
Nivel 2 (Desarrollar): existen prácticas básicas pero varían de un equipo a otro. Algunos sistemas definen elementos de configuración y un proceso de cambios y versionan sus lanzamientos; las líneas base aparecen aquí y allá, pero los registros son en parte manuales y la rigurosidad del control es inconsistente en toda la organización.
Nivel 3 (Estandarizar): las prácticas están documentadas y se aplican a nivel de organización. Se establece una taxonomía común de elementos de configuración, líneas base inmutables, control de cambios estratificado y registro de estado, en gran parte automatizados; los lanzamientos son reproducibles y trazables, y las auditorías se apoyan en herramientas en lugar de en la memoria.
Nivel 4 (Gestionar): la GCS se mide y controla con datos. La tasa de reproducibilidad, la cobertura de trazabilidad del requisito al artefacto implementado, el tiempo de ciclo de cada nivel de control, los incidentes de deriva de configuración y los hallazgos de auditoría se trackean frente a líneas base y objetivos. Las desviaciones activan la corrección, y cada decisión de aprobación o rechazo se apoya en esa evidencia en lugar de en una afirmación.
Nivel 5 (Orquestar): la GCS se mejora de forma continua y se integra a través de la organización. Totalmente automatizada y verificada de forma continua con compilaciones reproducibles, SBOM, atestiguados de procedencia y registro de estado en vivo, el proceso está tejido en la entrega, la seguridad y la auditoría, y se adapta a medida que el riesgo y los resultados de entrega cambian, retirando y redefiniendo controles en función de la evidencia.

Ideas para la reflexión

¿Podemos reproducir hoy nuestro último lanzamiento exactamente a partir de entradas controladas, y cuánto tardaríamos?
¿Qué elementos de configuración determinan el comportamiento pero no están realmente bajo control, especialmente los datos de configuración y la infraestructura?
¿Está nuestro control de cambios estratificado por el riesgo, o añade una sobrecarga uniforme o una laxitud uniforme en todas partes?
¿Dónde reside nuestro registro de configuración y cuánto se ha desviado de lo que realmente está implementado?
¿Qué evidencias podríamos producir en una auditoría mañana y cuánto de ellas sería una reconstrucción en lugar de un registro?
¿Cómo cambian las compilaciones reproducibles, las SBOM y los atestiguados de procedencia lo que nuestras auditorías pueden verificar de forma automática?

Puntos clave

La GCS controla toda la configuración (código, dependencias, infraestructura y datos de configuración), no solo el código fuente.
Las líneas base son puntos de referencia inmutables; el cambio se autoriza y se registra frente a ellas, no se impide.
El registro de estado debe permitir responder, en cualquier momento, qué contiene un lanzamiento y cómo llegó a ser lo que es.
Las auditorías verifican que lo construido y entregado coincide con la configuración registrada y los requisitos aprobados.
Estratificar el control por el riesgo y automatizar la identificación, el registro y la auditoría para que el registro sea un subproducto de la entrega.

Referencias y lectura complementaria

IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), área de conocimiento de Gestión de Configuración de Software
IEEE Std 828, Standard for Configuration Management in Systems and Software Engineering (Norma para la gestión de configuración en ingeniería de sistemas y de software)
ISO/IEC/IEEE 12207, Systems and software engineering: Software life cycle processes (Ingeniería de sistemas y de software: procesos del ciclo de vida del software), proceso de gestión de configuración
Jez Humble y David Farley, Continuous Delivery
Bob Aiello y Leslie Sachs, Configuration Management Best Practices: Practical Methods that Work in the Real World (Prácticas recomendadas de gestión de configuración: métodos prácticos que funcionan en el mundo real)
Guías del NIST sobre seguridad de la cadena de suministro de software, listas de materiales de software (SBOM) y procedencia de artefactos
CNCF y normas abiertas sobre procedencia de compilaciones y atestiguados (como marcos de referencia)