Debezium CLI: sigue el cambio hasta el destino

Qué dice la publicación y qué versión estás evaluando

La publicación del 26 de octubre distingue validate (descriptor, campos y variables), build (artefactos) y connection (acceso vivo), con operaciones remotas contra Debezium Platform. Usa ejemplos Alpha2/SNAPSHOT. Construir sin daemon no elimina la infraestructura de ejecución; TUI, integración con el operador y doctor aparecen como planes. (Debezium / Binayak Das)

El catálogo revisado apunta a debezium-jbang/debezium-jbang-main/dist/DebeziumJBang.java y fija debezium.jbang.version en 3.7.0.Final. Ese valor observado no acredita que la versión Final se estrenase el 26 de octubre. (Debezium contributors)

Código y catálogo están en debezium/jbang-catalog; debezium/dbz recoge incidencias. El README cita requisitos típicos según destino: JDK 21+, JBang 0.132.1 y Docker/Podman para servicios locales. (Debezium contributors)

Registra por separado versión de la CLI, componentes seleccionados y artefacto resultante. Si cambia uno, decide qué pruebas debes repetir. Un ejemplo histórico sirve para entender un flujo; la versión que aceptes necesita su propia referencia.

Cinco hitos para aceptar una integración CDC

La siguiente tabla es una propuesta de aceptación de KIURO, no una batería oficial de pruebas ni el resultado de una ejecución. Define antes el origen, el destino, el alcance de datos y quién puede autorizar cada ensayo.

No conviertas un estado saludable en una conclusión sobre todos los datos. Acota el conjunto de prueba y comprueba las transformaciones que forman parte del contrato: nombres de campos, claves, valores y tratamiento de eliminaciones cuando proceda. Una cuenta de filas puede coincidir aunque una asociación sea incorrecta.

Separa desarrollo, preproducción y producción

Antes de conectarte, prepara una ficha por entorno. Debe identificar el destino efectivo sin incluir secretos en las fichas, los registros de revisión o los artefactos que vayas a compartir.

Mantén separados el permiso de construir, el de publicar un artefacto y el de operar una integración. Documenta también quién paga y mantiene los recursos de ejecución. La tabla no presupone que ya tengas una instancia de Debezium Platform ni que debas añadirla a tu arquitectura.

Ejemplo hipotético: un pedido de prueba

Imagina un ensayo autorizado en preproducción con el pedido sintético prueba-042. Anota su clave, el estado inicial y la transformación esperada. Cambia su estado en origen y busca en destino el registro asociado a esa misma clave; compara el valor esperado y conserva las referencias de ambas observaciones.

Si el proceso aparece activo pero el registro no llega, conserva ese resultado como pendiente y localiza la última evidencia disponible. Si llega con una clave distinta, investiga el mapeo. Si llega correctamente, limita la conclusión a ese caso y a esas condiciones. Para medir demora, define los puntos de observación y comprueba que los relojes sean comparables.

Este ejemplo no se ha ejecutado. Completarlo tampoco acreditaría por sí solo el comportamiento bajo interrupciones, cambios de esquema o volúmenes distintos: esos casos necesitan criterios propios y una autorización adecuada al entorno.

Qué entregar al responsable de la integración

Entrega la configuración identificada, el artefacto exacto, el entorno, las evidencias del cambio conciliado y una lista de límites pendientes con responsable. Para coordinar una integración entre sistemas, esa lista permite decidir qué falta antes de aceptar su operación.

El LICENSE del catálogo es Apache 2.0. La política distingue código, contenidos web y marcas. (Debezium contributors, Debezium)

La licencia no sustituye el presupuesto del despliegue. Estima por separado infraestructura, almacenamiento, transferencia y mantenimiento según tu caso; esta revisión no aporta una tarifa ni un ahorro medido.