Diseñar una matriz de compatibilidad

1325. Identidad de la lección

Módulo

3.13 — Versionado de esquemas y builds

Lección

2 del módulo

Tipo académico

Construcción guiada

Tipo de esquema

Práctica

Tiempo estimado

45–60 minutos

Propósito

Hacer explícitos los supuestos de versión.

Concepto principal

Sellos de esquema, sellos de build, dirección de las operaciones y combinaciones compatibles.

1326. Objetivo de aprendizaje

Al terminar esta lección, podrás producir una matriz de compatibilidad que relacione esquemas de origen, esquemas de destino o salida, sellos de build y operaciones con decisiones explícitas de soporte. También podrás definir un invariante de ida y vuelta y redactar un plan de diagnóstico para una combinación no compatible o desconocida.

1327. Por qué importa

Una etiqueta de versión solo sirve si el equipo puede actuar a partir de ella. El sello de esquema identifica la forma de los datos y sus reglas de interpretación; el sello de build identifica el comportamiento del ejecutable. Una matriz de compatibilidad convierte esas identidades en una política explícita de soporte.

Las migraciones y las comprobaciones de ida y vuelta requieren algo más que un esquema de origen. Una migración debe indicar el esquema de destino, mientras que una operación de ida y vuelta debe especificar su secuencia y qué debe permanecer sin cambios. Sin esos datos, una matriz puede parecer precisa y aun así ocultar supuestos importantes sobre la transformación.

1328. Conocimientos previos

Debes haber completado La identidad de versión tiene más de un significado, del módulo 3.13. Debes poder distinguir una versión de esquema de una versión de build y explicar por qué un build puede leer un registro que otro rechaza. Usa únicamente un formato de datos pequeño, ficticio o local, cuyos supuestos puedas verificar.

1329. Concepto central

La compatibilidad es una propiedad de una combinación concreta de esquema, build y operación, incluida la dirección de la operación.

Un registro de compatibilidad útil incluye:

• Sello del esquema de origen: esquema de los datos de entrada.
• Sello del esquema de destino o salida: esquema que debe producir una escritura, migración, exportación u operación de ida y vuelta; usa No aplica solo cuando no exista una salida.
• Sello de build: programa que realiza la operación.
• Operación: lectura, escritura, migración o una secuencia de ida y vuelta definida con precisión.
• Resultado: compatible, compatible con migración, no compatible o desconocido.
• Evidencia o regla: resultado de una prueba, regla de migración o motivo documentado.
• Acción de diagnóstico: señal observable y respuesta segura para los casos no compatibles o desconocidos.

La lectura directa y la migración son decisiones distintas. Un build puede leer un esquema antiguo sin modificarlo, migrarlo a uno nuevo, permitir la escritura únicamente en el esquema nuevo o rechazar un esquema de salida solicitado.

1330. Modelo mental

Usa el modelo ORIGEN × DESTINO × BUILD × OPERACIÓN → DECISIÓN:

Para cada fila, pregunta:

1. ¿Puede este build interpretar el esquema de origen para la operación indicada?
2. ¿La operación produce una salida y, en ese caso, está explícito su esquema de destino?
3. Si la operación es una migración, ¿existe una migración definida entre el origen y el destino?
4. Si es una operación de ida y vuelta, ¿cuál es la secuencia exacta y qué invariante debe conservarse?
5. ¿Qué diagnóstico observable debe aparecer cuando la combinación no es compatible o sigue siendo desconocida?

Una operación de ida y vuelta no significa simplemente “guardar y volver a cargar”. Debes indicar su dirección. Para esta lección, una secuencia válida es leer S1 → escribir S2 → leer S2. Su invariante establece que los valores de credits e items del registro S1 original deben conservarse de forma equivalente tras la lectura final de S2. El nuevo campo heat sigue el valor predeterminado documentado de la migración y no forma parte de ese invariante de conservación.

1331. Ejemplo concreto

Supón que un registro de guardado pequeño comienza con el esquema S1 y después añade el campo heat en S2:

• B1 solo conoce S1.
• B2 conoce S1 y S2, y puede migrar S1 a S2 asignando a heat un valor predeterminado documentado.

La columna de destino o salida evita que términos como “migrar” o “escribir” oculten el esquema que se pretende producir. La secuencia explícita evita tratar como equivalentes direcciones opuestas de ida y vuelta.

1332. Errores comunes

Evita estos errores:

• Tratar la lectura directa y la migración como si fueran la misma capacidad.
• Suponer que un build más reciente admite todos los esquemas y operaciones.
• Escribir “migrar” sin indicar los esquemas de origen y destino.
• Escribir “ida y vuelta” sin definir la secuencia y el invariante de conservación.
• Marcar una celda sin probar como compatible en lugar de desconocida.
• Aceptar la pérdida silenciosa de campos como una migración inversa válida.

1333. Práctica guiada

Crea una matriz de compatibilidad y un plan de diagnóstico para este formato ficticio:

• El esquema S1 contiene credits e items.
• El esquema S2 añade heat y registra un sello de esquema.
• El build B1 puede leer y escribir S1.
• El build B2 puede leer S1, migrarlo a S2, y leer y escribir S2.
• No se ha definido ninguna migración de S2 a S1.

Sigue estos pasos:

1. Enumera por separado los sellos de esquema y de build.
2. Incluye operaciones de lectura, escritura, migración e ida y vuelta.
3. En cada fila, indica el esquema de origen y el build. Si la operación produce o transforma datos, indica también el esquema de destino o salida; en caso contrario, escribe No aplica.
4. Define la operación de ida y vuelta requerida como leer S1 → escribir S2 → leer S2.
5. Nombra su invariante: el registro final debe conservar los valores originales de credits e items. Registra por separado la regla esperada para heat.
6. Marca cada resultado como compatible, compatible con migración, no compatible o desconocido.
7. Para cada resultado no compatible o desconocido, crea un registro de diagnóstico que capture en conjunto:
   • el sello del esquema de origen;
   • el sello del esquema de destino o salida pertinente;
   • el sello de build;
   • la operación y su dirección;
   • el fallo o advertencia esperados;
   • la evidencia que confirmaría el diagnóstico;
   • la siguiente acción segura.
8. Indica por separado qué campo registrado inspeccionarías primero durante el triaje y por qué. Esta decisión de secuencia no elimina el requisito de capturar el registro de diagnóstico completo.
9. Decide si la ruta S2 → S1 se admite, se rechaza o queda pendiente de evidencia. No diseñes ni implementes una migración inversa. Si la rechazas, explica por qué no es aceptable perder heat silenciosamente.

Usa esta estructura:

No sustituyas la evidencia que falta por una suposición. Desconocido es una decisión adecuada cuando todavía se necesita verificación.

1334. Validación / evidencia

1335. Puntos clave

• La compatibilidad pertenece a una combinación de esquema de origen, esquema de destino, build y operación.
• Las migraciones deben indicar sus esquemas de origen y destino.
• Las operaciones de ida y vuelta deben definir su secuencia y su invariante de conservación.
• La lectura directa, la escritura, la migración y la ida y vuelta requieren decisiones separadas.
• Es preferible marcar una combinación como desconocida que respaldarla con una suposición.
• Los registros de diagnóstico deben capturar juntas todas las identidades pertinentes y conducir a una acción segura.

1336. Siguiente lección

Continúa con 3.14 — Git profesional.

1337. Comprobación