Escrito por: Monica Gaertner, Directora de Producto
Una característica clave de los conjuntos de datos de Brightspace (BDS) es un contrato de datos sólido, lo que garantiza que los datos que entregamos funcionen de manera coherente y cambien de manera predecible. Para facilitar esto, hemos desarrollado una política de gestión de cambios que describe los cambios que se realizarán de una manera que agregue valor mientras se protege ese contrato de datos importante.
La política también describe un esquema de numeración de versiones, que se utiliza para comunicar y controlar la publicación de todos los cambios.
Categorías de cambio
Los cambios en el BDS se dividen en dos categorías: cambios menores y cambios importantes.
Cambiar categoría | Interrupción de CD | Habilitación | Comentarios |
|---|
Menor | Ninguno/Leve | Habilitado automáticamente sin opción de exclusión. | Aviso proporcionado en las notas de la versión preliminar con detalles en las notas de la versión con GA. |
Menor | Moderado | Habilitado automáticamente sin opción de exclusión. | Aviso proporcionado con 60 días de anticipación. |
Destacado | Grande/Grave | Oportunidad de optar por participar durante 4 meses antes de habilitarse automáticamente sin opción de exclusión. | Aviso proporcionado con 60 días de anticipación con un período de adopción de 4 meses. |
Cambios menores
Estos cambios desencadenan un incremento de un número de versión secundaria, por ejemplo, de la versión 6.9 a la 6.10. Se recomienda desarrollar en torno a estos tipos de cambios para que no sea necesario realizar cambios en el código.
Ejemplos de cambios menores:
Cambio | Ejemplo hipotético | Impacto | Suposiciones | Interrupción de CD |
|---|
Agregar un nuevo conjunto de datos de Brightspace | Agentes inteligentes BDS añadido. | Aparece un nuevo conjunto de datos en la interfaz de usuario y la API. | Las integraciones están diseñadas para ignorar los nuevos conjuntos de datos enumerados en la ruta de la API de conjuntos de datos. | Leve |
Adición de una columna a la clave principal compuesta | Clave principal de las preguntas del cuestionario BDS actualizado para incluir columnas adicionales: una nueva y otra existente. | La combinación de columnas que funciona como clave principal cambia para incluir una o varias columnas adicionales. | Es posible que sea necesario actualizar las integraciones para usar la nueva clave principal compuesta, pero las integraciones seguirán funcionando con la clave principal compuesta anterior. | Leve |
Quitar una columna de la clave principal compuesta, pero la columna permanece en el conjunto de datos | Clave principal de las preguntas del cuestionario BDS actualizado para que ya no requiera una columna, pero la columna eliminada sigue existiendo. | La combinación de columnas que funciona como clave principal ya no requiere una o varias columnas. | Las integraciones siguen funcionando con la clave principal compuesta anterior, pero las integraciones pueden encontrar más valor con la nueva clave principal compuesta. | Leve |
Cambiar si una columna puede ser NULL | Se actualizó una columna que anteriormente podía ser nula a no anulable. | Ya no es necesario esperar valores NULL al procesar. | Las integraciones siguen funcionando cuando algo que podría ser NULL en el pasado ahora tiene un valor para cada fila. Sin embargo, es posible que sea necesario realizar una actualización para esperar un valor NULL donde antes no podía haberlo. | Leve |
Anexar una nueva columna | Se ha agregado la columna LastModifiedDate al final del BDS de objetos de calificación. | Aparece una nueva columna en el conjunto de datos después de los elementos de datos existentes. | Las integraciones están diseñadas para ignorar los nuevos elementos de datos, pero continuar con otros elementos de datos. Vea un ejemplo de código que muestra un enfoque para implementar este comportamiento. | Moderado |
Agregar nuevos datos en forma de filas adicionales | Se han añadido eliminaciones temporales a los BDS existentes. | Aparecen filas adicionales en el conjunto de datos. Dependiendo del uso, es posible que deban filtrarse. | Es posible que sea necesario actualizar las integraciones para manejar las nuevas filas o filtrarlas. | Moderado |
Cambiar si una columna puede ser NULL | Se ha actualizado una columna que anteriormente no podía ser nula a anulable. | Espere valores NULL al procesar el conjunto de datos. | Las integraciones siguen funcionando cuando algo que podría ser NULL en el pasado ahora tiene un valor para cada fila. Sin embargo, es posible que sea necesario realizar una actualización para esperar un valor NULL donde antes no podía haberlo. | Moderado |
Cambiar el tipo de datos de una columna | Se ha cambiado el tipo de datos de una columna de bit a int. | El tipo de datos anterior ya no es válido. | Es posible que sea necesario actualizar las integraciones para manejar el nuevo tipo de datos. | Moderado |
Cambios importantes
Los cambios importantes son disruptivos por naturaleza. Estos cambios pueden desencadenar un incremento de un número de versión principal, por ejemplo: de la versión 7.x a la 8.0. Los cambios de versión principales se pueden aceptar en el momento del lanzamiento y se adoptan automáticamente cuatro meses después de la actualización mensual de Brightspace en la que se introducen. Es posible que se produzcan algunos cambios importantes sin una nueva versión principal y estos cambios también vendrán con un período de adopción de cuatro meses.
Ejemplos de cambios importantes:
Cambio | Ejemplo hipotético | Impacto | Suposiciones |
|---|
Quitar una columna | Quitado ObjectLookupId2 columna de Calendario de eventos BDS. | La columna ya no existe en BDS. En los casos en los que la columna formaba parte de la clave principal compuesta, la combinación de columnas que funciona como clave principal compuesta ya no requiere que se elimine la columna. | Las integraciones deben actualizarse para que ya no se espere que la columna se elimine en el BDS. |
Cambiar el nombre de una columna | Retitulado ObjectId (Id) Para QuizId. | El nombre de columna utilizado anteriormente ya no existe, y un nuevo nombre ocupa su lugar. | Las integraciones deben actualizarse para actualizar el nombre de la columna existente. |
Cambie los caracteres del nombre de la columna a mayúsculas o minúsculas | Cambiado HistoryID (ID de historia) Para HistoryId. | El nombre de columna utilizado anteriormente ya no existe, y un nuevo nombre ocupa su lugar. | Las integraciones deben actualizarse para actualizar el nombre de la columna existente (la detección automática de columnas distingue entre mayúsculas y minúsculas). |
Eliminar un conjunto de datos | Premios Se ha eliminado el BDS. | El conjunto de datos ya no está disponible para su descarga.
Es posible que se produzcan algunas eliminaciones de conjuntos de datos sin un cambio importante en la versión. | Las integraciones deben actualizarse para eliminar las dependencias del conjunto de datos eliminado. |
Tenga en cuenta: Excepciones para correcciones de defectos de alta prioridad
Cuando se encuentra un defecto que resulta en la imposibilidad de continuar usando un conjunto de datos o bloquea el uso normal, se solucionará en la próxima versión disponible. Se considerarán todos los intentos de arreglar el defecto sin interrupciones. Sin embargo, esta corrección puede incluir acciones clasificadas como Cambios importantes en la tabla anterior si no hay otras opciones disponibles. Si el impacto de no adoptar la corrección es alto, el cambio principal puede habilitarse de forma predeterminada después de la versión.
Escenarios de lanzamiento
Los cambios menores se adoptan automáticamente durante la actualización mensual de Brightspace en la que se introducen. Los cambios importantes se adoptan automáticamente cuatro meses después de la actualización mensual de Brightspace en la que se introducen. Esta latencia está pensada para proporcionar suficiente tiempo de espera para actualizar las integraciones para hacer frente al cambio. Los clientes pueden optar por adoptar el cambio principal en cualquier momento durante el período de adopción de cuatro meses actualizando su versión activa de los conjuntos de datos de Brightspace (D2L. Herramientas.BrightspaceDataSets.Version). Refiérase a Configurar el centro de datos para obtener instrucciones.
Escenario A: lanzamiento de la versión secundaria
Se publica una versión secundaria y se adopta automáticamente.
Ejemplo: 8.3 es la versión activa actual. Cuando se lanza la versión 8.4, se convierte en la versión activa y la 8.3 ya no está disponible. No hay opciones para optar por no recibir nuevos cambios. Se pueden esperar actualizaciones de versiones secundarias en cada versión.
Escenario B: lanzamiento de la versión principal
Se publica una versión principal, la adopción automática se produce después de un período de adopción de cuatro meses en el que puede optar por la versión principal.
Ejemplo: 7.4 es la versión activa actual. Cuando se lance la versión 8.0, estará disponible para participar. Una vez que ha estado activo durante cuatro versiones, la versión activa se convierte en 8.x y la 7.x ya no está disponible.
Escenario C: lanzamiento de la versión principal con las versiones secundarias siguientes
Se publica una versión principal, cualquier versión secundaria publicada posteriormente reemplaza esa versión opt-in durante el período de adopción de cuatro meses y continúa agregándose a la versión principal actual.
Ejemplo: 7.8 es la versión activa actual y se lanza 8.0 (como la versión opt-in) para permitir cuatro versiones antes de la adopción automática. Un mes después, se lanza la versión 8.1 y reemplaza a la 8.0 como versión opt-in durante el período de adopción, al mismo tiempo que la 7.9 reemplaza a la 7.8. Esto continúa cada mes hasta que finaliza el período de adopción y la versión opt-in se convierte en la versión activa (y única) disponible.
Tenga en cuenta que puede haber algunos casos en los que el cambio menor que se publica no sea aplicable a la versión principal actual y, por lo tanto, solo se aplicará a la nueva versión principal y se comunicará como tal.
Escenario 
lanzamiento de la versión principal con otra versión principal que le sigue
Cuando se produce la adopción de una versión principal, cualquier versión principal posterior debe esperar hasta que vuelva a haber una sola versión en producción antes de publicarla. D2L solo admitirá dos versiones activas del conjunto de datos de Brightspace a la vez.
Ejemplo: 7.8 es la versión activa actual y 8.0 se publica como la versión opt-in para permitir cuatro versiones antes de la adopción automática. Una vez finalizado el período de adopción de 4 meses, la 8.4 se convertirá en la versión activa (y la 7.x ya no estará disponible) y existe la posibilidad de lanzar la 9.0 como la versión opt-in que comenzará su período de adopción de 4 meses.
Enlaces relacionados
Cuéntanos lo que piensas
Agradecemos sus comentarios sobre esta política de gestión de cambios y los conjuntos de datos de Brightspace en general. Por favor, publique sus preguntas y comentarios en el Grupo de la comunidad de datos y análisis o comparta sus comentarios con su representante de cuentas de D2L.
La Política de administración de cambios de conjuntos de datos de Brightspace se publicó el 10 de diciembre de 2018 y se actualiza periódicamente para comunicar la política actual.