Écrit par : Monica Gaertner, chef de produit
Une caractéristique clé des ensembles de données Brightspace (BDS) est un contrat de données solide, garantissant que les données que nous fournissons fonctionnent de manière cohérente et changent de manière prévisible. Pour faciliter cela, nous avons élaboré une politique de gestion du changement qui décrit les changements qui seront apportés d’une manière qui ajoute de la valeur tout en protégeant cet important contrat de données.
La politique décrit également un schéma de numérotation des versions, qui est utilisé pour communiquer et contrôler la publication de toutes les modifications.
Catégories de changement
Les modifications apportées au BDS se divisent en deux catégories : changements mineurs et changements majeurs.
Modifier la catégorie | Perturbation du CD | Habilitation | Commentaires |
|---|
Mineur | Aucun/Léger | Activé automatiquement sans désinscription. | Avis fourni dans les notes de mise à jour de l’aperçu avec des détails dans les notes de publication avec GA. |
Mineur | Modérée | Activé automatiquement sans désinscription. | Avis donné 60 jours à l’avance. |
Majeur | Grand/Grave | Possibilité de s’inscrire pendant 4 mois avant d’être automatiquement activé sans désinscription. | Avis fourni 60 jours à l’avance avec une période d’adoption de 4 mois. |
Modifications mineures
Ces modifications déclenchent un incrément d’un numéro de version mineur , par exemple, de la version 6.9 à la version 6.10. Il est recommandé de développer autour de ces types de changements afin que les changements de code ne soient pas nécessaires.
Exemples de changements mineurs :
Changement | Exemple hypothétique | Conséquences | Hypothèses | Perturbation du CD |
|---|
Ajouter un nouvel ensemble de données Brightspace | Agents intelligents BDS ajoutés. | Le nouvel ensemble de données apparaît dans l'interface utilisateur et l'API. | Les intégrations sont conçues pour ignorer les nouveaux ensembles de données répertoriés dans l’itinéraire de l’API des ensembles de données. | Légère |
Ajouter une colonne à la clé primaire composite | Clé primaire des questions de quiz BDS mise à jour pour inclure des colonnes supplémentaires : une nouvelle et une existante. | La combinaison de colonnes qui fonctionne comme clé primaire change pour inclure une ou plusieurs colonnes supplémentaires. | Les intégrations peuvent devoir être mises à jour pour utiliser la nouvelle clé primaire composite, mais les intégrations continueront de fonctionner à l'aide de l'ancienne clé primaire composite. | Légère |
Supprimer une colonne de la clé primaire composite, mais la colonne reste dans l'ensemble de données | Clé primaire des questions de quiz BDS mise à jour pour ne plus nécessiter de colonne, mais la colonne supprimée existe toujours. | La combinaison de colonnes qui fonctionne comme clé primaire ne nécessite plus une ou plusieurs colonnes. | Les intégrations continuent de fonctionner à l'aide de l'ancienne clé primaire composite, mais les intégrations peuvent trouver plus de valeur en utilisant la nouvelle clé primaire composite. | Légère |
Modifier si une colonne peut être NULL | Mise à jour d’une colonne qui pouvait auparavant être nulle à non nullable. | Il n'est plus nécessaire de s'attendre à des valeurs NULL lors du traitement. | Les intégrations continuent de fonctionner lorsque quelque chose qui pouvait être NULL dans le passé a maintenant une valeur pour chaque ligne. Cependant, il peut être nécessaire de mettre à jour pour s'attendre à une valeur NULL là où il ne pouvait pas y en avoir auparavant. | Légère |
Ajouter une nouvelle colonne | La colonne LastModifiedDate a été ajoutée à la fin des objets de note BDS. | Une nouvelle colonne apparaît dans l'ensemble de données après les éléments de données existants. | Les intégrations sont conçues pour ignorer les nouveaux éléments de données, mais procéder avec d’autres éléments de données. Voir un exemple de code qui illustre une approche de la mise en œuvre de ce comportement. | Modérée |
Ajouter de nouvelles données sous la forme de lignes supplémentaires | Suppressions logicielles ajoutées au BDS existant. | Des lignes supplémentaires apparaissent dans l'ensemble de données. Selon l'utilisation, elles peuvent avoir besoin d'être filtrées. | Les intégrations peuvent devoir être mises à jour pour gérer les nouvelles lignes ou les filtrer. | Modérée |
Modifier si une colonne peut être NULL | Mise à jour d’une colonne qui auparavant ne pouvait pas être nulle à nullable. | Attendez-vous à des valeurs NULL lors du traitement de l'ensemble de données. | Les intégrations continuent de fonctionner lorsque quelque chose qui pouvait être NULL dans le passé a maintenant une valeur pour chaque ligne. Cependant, il peut être nécessaire de mettre à jour pour s'attendre à une valeur NULL là où il ne pouvait pas y en avoir auparavant. | Modérée |
Modifier le type de données d'une colonne | Changement du type de données d'une colonne de bit à int. | Le type de données précédent n'est plus valide. | Les intégrations peuvent devoir être mises à jour pour gérer le nouveau type de données. | Modérée |
Changements majeurs
Les changements majeurs sont de nature disruptive. Ces modifications peuvent déclencher un incrément d'un numéro de version majeure, par exemple : version 7.x à 8.0. Les changements de version majeure peuvent être choisis lors de la publication et sont automatiquement adoptés quatre mois après la mise à jour mensuelle de Brightspace dans laquelle ils sont introduits. Certains changements majeurs peuvent se produire sans une nouvelle version majeure et ces changements viendront également avec une période d'adoption de quatre mois.
Exemples de changements majeurs :
Changement | Exemple hypothétique | Conséquences | Hypothèses |
|---|
Supprimer une colonne | Supprimé ObjectLookupId2 colonne de BDS Événements de calendrier BDS. | La colonne n’existe plus dans BDS. Dans les cas où la colonne faisait partie de la clé primaire composite, la combinaison de colonnes qui fonctionne comme clé primaire composite ne nécessite plus la colonne supprimée. | Les intégrations doivent être mises à jour pour ne plus s’attendre à ce que la colonne soit supprimée dans le BDS. |
Renommer une colonne | Renommé ObjectId à QuizId. | Le nom de colonne précédemment utilisé n'existe plus, remplacé par un nouveau nom. | Les intégrations doivent être mises à jour pour modifier le nom de la colonne existante. |
Changer le(s) caractère(s) dans le nom de la colonne en majuscules ou en minuscules | Modifié HistoireID à HistoryId. | Le nom de colonne précédemment utilisé n'existe plus, remplacé par un nouveau nom. | Les intégrations doivent être mises à jour pour modifier le nom de la colonne existante (la détection automatique des colonnes est sensible à la casse). |
Supprimer un ensemble de données | Prix et distinctions supprimé. | L'ensemble de données n'est plus disponible au téléchargement.
Certaines suppressions d’ensembles de données peuvent se produire sans modification majeure de la version. | Les intégrations doivent être mises à jour pour supprimer les dépendances sur l'ensemble de données supprimé. |
Remarque : Exceptions pour les corrections de défauts de haute priorité
Lorsqu’un défaut est détecté qui entraîne l’incapacité de continuer à utiliser un ensemble de données ou bloque l’utilisation normale, il sera résolu dans la prochaine version disponible. Toutes les tentatives de réparer le défaut sans interruption seront prises en compte. Toutefois, ce correctif peut inclure des actions classées comme modifications majeures dans le tableau ci-dessus si aucune autre option n’est disponible. Si l’impact de la non-adoption du correctif est élevé, la modification majeure peut être activée par défaut après la version.
Scénarios de publication
Les changements mineurs sont automatiquement adoptés lors de la mise à jour mensuelle de Brightspace dans laquelle ils sont introduits. Les changements majeurs sont automatiquement adoptés quatre mois après la mise à jour mensuelle de Brightspace dans laquelle ils sont introduits. Cette latence est destinée à fournir suffisamment de temps pour mettre à jour les intégrations afin de faire face au changement. Les clients peuvent choisir d’adopter le changement majeur à tout moment au cours de la période d’adoption de quatre mois en mettant à jour leur version active des ensembles de données Brightspace (d2l.Tools.BrightspaceDataSets.Version). Reportez-vous à la section Configurer Data Hub pour obtenir des instructions.
Scénario A - Version mineure
Une version mineure est publiée et automatiquement adoptée.
Exemple : 8.3 est la version active actuelle. Lorsque la version 8.4 est publiée, elle devient la version active et la version 8.3 n’est plus disponible. Il n’y a pas d’options pour refuser de nouveaux changements. Des mises à jour de version mineures peuvent être attendues à chaque version.
Scénario B - Version majeure
Une version majeure est publiée, l'adoption automatique a lieu après une période d'adoption de quatre mois au cours de laquelle vous pouvez opter pour la version majeure.
Exemple : 7.4 est la version active actuelle. Lorsque la 8.0 est publiée, elle est disponible pour l'opt-in. Une fois qu'elle a été en ligne pendant quatre versions, la version active devient 8.x et 7.x n'est plus disponible.
Scénario C - Version majeure avec les versions mineures qui suivent
Une version majeure est publiée, toutes les versions mineures publiées par la suite remplacent cette version opt-in tout au long de la période d'adoption de quatre mois et continuent d'être ajoutées à la version majeure actuelle.
Exemple : 7.8 est la version active actuelle, et 8.0 est publiée (comme la version opt-in) pour permettre quatre publications avant l'adoption automatique. Un mois plus tard, 8.1 est publiée et remplace 8.0 comme version opt-in pendant la période d'adoption, tandis que 7.9 remplace 7.8. Cela se poursuit chaque mois jusqu'à la fin de la période d'adoption et que la version opt-in devienne la version active (et unique) disponible.
Veuillez noter qu'il peut y avoir des cas où le changement mineur publié ne s'applique pas à la version majeure actuelle et ne sera donc appliqué qu'à la nouvelle version majeure et sera communiqué en tant que tel.
Scénario D - Version majeure avec une autre version majeure qui suit
Lorsque l'adoption d'une version majeure se produit, toute version majeure ultérieure doit attendre qu'il y ait à nouveau une seule version en production avant de sortir. D2L ne prend en charge que deux versions actives des ensembles de données Brightspace à la fois.
Exemple : 7.8 est la version active actuelle, et 8.0 est publiée comme version opt-in pour permettre quatre versions avant l'adoption automatique. Une fois la période d'adoption de 4 mois terminée, 8.4 deviendra la version active (et 7.x ne sera plus disponible) et il sera possible de publier 9.0 en tant que version opt-in qui commencera sa période d'adoption de 4 mois.
Liens connexes
Dites-nous ce que vous en pensez
Nous vous invitons à nous faire part de vos commentaires sur cette politique de gestion du changement et les ensembles de données Brightspace en général. S’il vous plaît poster des questions et des commentaires dans le Groupe de la communauté des données et de l’analyse ou partagez vos commentaires avec votre représentant de compte D2L.
La politique de gestion des changements des ensembles de données Brightspace a été publiée le 10 décembre 2018 et est mise à jour périodiquement pour communiquer la politique actuelle.