Escrito por: Monica Gaertner, Gerente de Produto
Um recurso importante dos Conjuntos de dados do Brightspace (BDS) é um contrato de dados forte, garantindo que os dados que fornecemos funcionem de forma consistente e mudem de forma previsível. Para facilitar isso, desenvolvemos uma política de gerenciamento de mudanças que descreve que as alterações serão feitas de uma forma que agregue valor e, ao mesmo tempo, proteja esse importante contrato de dados.
A política também descreve um esquema de numeração de versão, que é usado para comunicar e controlar a liberação de todas as alterações.
Categorias de Mudança
As alterações no BDS se enquadram em duas categorias: Pequenas Alterações e Grandes Mudanças.
Alterar categoria | Interrupção do CD | Capacitação | Comentários |
|---|
Menor | Nenhum/Ligeiro | Ativado automaticamente sem recusa. | Aviso fornecido nas Notas de versão prévia com detalhes nas Notas de versão com GA. |
Menor | Moderado | Ativado automaticamente sem recusa. | Aviso fornecido com 60 dias de antecedência. |
Principal | Grande/Grave | Oportunidade de optar por 4 meses antes de ser ativado automaticamente, sem desativação. | Aviso fornecido com 60 dias de antecedência com período de adoção de 4 meses. |
Pequenas alterações
Essas alterações acionam um incremento de um número de versão secundária – por exemplo, da versão 6.9 para a 6.10. É recomendável desenvolver em torno desses tipos de alterações para que as alterações de código não sejam necessárias.
Exemplos de pequenas alterações:
Mudar | Exemplo hipotético | Impacto | Suposições | Interrupção do CD |
|---|
Adicionar um novo conjunto de dados do Brightspace | Agentes Inteligentes BDS adicionado. | Novo conjunto de dados aparece na interface do usuário e na API. | As integrações são projetadas para ignorar novos conjuntos de dados listados na Rota da API de conjuntos de dados. | Ligeiro |
Adicionar uma coluna à chave primária composta | Chave primária de perguntas do questionário BDS atualizado para incluir colunas adicionais: uma nova e outra existente. | A combinação de colunas que funciona como chave primária é alterada para incluir uma ou mais colunas adicionais. | As integrações podem precisar ser atualizadas para usar a nova chave primária composta, mas as integrações continuarão a funcionar usando a chave primária composta anterior. | Ligeiro |
Remova uma coluna da chave primária composta, mas a coluna permanece no conjunto de dados | Chave primária das perguntas do questionário O BDS foi atualizado para não exigir mais uma coluna, mas a coluna removida ainda existe. | A combinação de colunas que funciona como Chave Primária não requer mais uma ou mais colunas. | As integrações continuam a funcionar usando a chave primária composta anterior, mas as integrações podem encontrar mais valor usando a nova chave primária composta. | Ligeiro |
Alterar se uma coluna pode ser NULL | Atualizada uma coluna que anteriormente poderia ser nula para não anulável. | Não é mais necessário esperar valores NULL durante o processamento. | As integrações continuam a funcionar quando algo que poderia ser NULL no passado agora tem um valor para cada linha. No entanto, pode ser necessário haver uma atualização para esperar um valor NULL onde não poderia haver um antes. | Ligeiro |
Acrescentar uma nova coluna | LastModifiedDate adicionada ao final do BDS de objetos de nota. | Nova coluna aparece no conjunto de dados após os elementos de dados existentes. | As integrações são projetadas para ignorar novos elementos de dados, mas prosseguir com outros elementos de dados. Veja um exemplo de código que demonstra uma abordagem para implementar esse comportamento. | Moderado |
Adicionar novos dados na forma de linhas adicionais | Exclusões reversíveis adicionadas ao BDS existente. | Linhas adicionais aparecem no conjunto de dados. Dependendo do uso, eles podem precisar ser filtrados. | As integrações podem precisar ser atualizadas para lidar com as novas linhas ou filtrá-las. | Moderado |
Alterar se uma coluna pode ser NULL | Atualizada uma coluna que anteriormente não podia ser nula para anulável. | Espere valores NULL ao processar o conjunto de dados. | As integrações continuam a funcionar quando algo que poderia ser NULL no passado agora tem um valor para cada linha. No entanto, pode ser necessário haver uma atualização para esperar um valor NULL onde não poderia haver um antes. | Moderado |
Alterar o tipo de dados de uma coluna | Alterado o tipo de dados de uma coluna de bit para int. | O tipo de dados anterior não é mais válido. | As integrações podem precisar ser atualizadas para lidar com o novo tipo de dados. | Moderado |
Principais mudanças
As principais mudanças são de natureza disruptiva. Essas alterações podem disparar um incremento de um número de versão principal, por exemplo: versão 7.x para 8.0. As alterações de versão principais podem ser ativadas no lançamento e são adotadas automaticamente quatro meses após a atualização mensal do Brightspace em que são introduzidas. Algumas mudanças importantes podem ocorrer sem uma nova versão principal e essas mudanças também virão com um período de adoção de quatro meses.
Exemplos de grandes mudanças:
Mudar | Exemplo hipotético | Impacto | Suposições |
|---|
Remover uma coluna | Removido ObjectLookupId2 coluna de Eventos do calendário BDS. | A coluna não existe mais no BDS. Nos casos em que a coluna fazia parte da Chave Primária composta, a combinação de colunas que funciona como Chave Primária composta não requer mais que a coluna seja removida. | As integrações devem ser atualizadas para não esperar mais que a coluna seja removida no BDS. |
Renomear uma coluna | Renomeado ObjectId Para QuizId. | O nome da coluna usado anteriormente não existe mais, com um novo nome tomando seu lugar. | As integrações devem ser atualizadas para atualizar o nome da coluna existente. |
Altere o(s) caractere(s) no nome da coluna para maiúsculas ou minúsculas | Mudou ID da história Para Histórico. | O nome da coluna usado anteriormente não existe mais, com um novo nome tomando seu lugar. | As integrações devem ser atualizadas para atualizar o nome da coluna existente (a detecção automática de coluna diferencia maiúsculas de minúsculas). |
Remover um conjunto de dados | Prêmios BDS removido. | O conjunto de dados não está mais disponível para download.
Algumas remoções de conjuntos de dados podem ocorrer sem uma alteração de versão principal. | As integrações devem ser atualizadas para remover dependências no conjunto de dados removido. |
Observação: exceções para correções de defeitos de alta prioridade
Quando for encontrado um defeito que resulte na incapacidade de continuar usando um conjunto de dados ou bloqueie o uso normal, ele será resolvido na próxima versão disponível. Todas as tentativas de corrigir o defeito sem interrupção serão consideradas. No entanto, essa correção pode incluir ações classificadas como Grandes Mudanças na tabela acima se nenhuma outra opção estiver disponível. Se o impacto de não adotar a correção for alto, a Alteração Principal poderá ser habilitada por padrão após o lançamento.
Cenários de lançamento
As pequenas alterações são adotadas automaticamente durante a atualização mensal do Brightspace em que são introduzidas. As principais alterações são adotadas automaticamente quatro meses após a atualização mensal do Brightspace em que são introduzidas. Essa latência destina-se a fornecer tempo de espera suficiente para atualizar as integrações para lidar com a alteração. Os clientes podem optar por adotar a Alteração Principal a qualquer momento durante o período de adoção de quatro meses, atualizando sua versão ativa dos Conjuntos de dados do Brightspace (d2l. Tools.BrightspaceDataSets.Version). Referir-se a Configurar o Data Hub para obter instruções.
Cenário A - Versão secundária
Uma versão secundária é lançada e adotada automaticamente.
Exemplo: 8.3 é a versão ativa atual. Quando o 8.4 é lançado, ele se torna a versão ativa e o 8.3 não está mais disponível. Não há opções para recusar novas alterações. Atualizações de versão secundária podem ser esperadas a cada versão.
Cenário B - Versão principal
Uma versão principal é lançada, a adoção automática ocorre após um período de adoção de quatro meses no qual você pode aceitar a versão principal.
Exemplo: 7.4 é a versão ativa atual. Quando a versão 8.0 for lançada, ela estará disponível para aceitação. Depois de estar no ar por quatro versões, a versão ativa se torna 8.x e 7.x não está mais disponível.
Cenário C - Versão principal com versões secundárias a seguir
Uma versão principal é lançada, todas as versões secundárias lançadas posteriormente substituem essa versão opcional durante o período de adoção de quatro meses e continuam a ser adicionadas à versão principal atual.
Exemplo: 7.8 é a versão ativa atual e 8.0 é lançada (como a versão opcional) para permitir quatro versões antes da adoção automática. Um mês depois, o 8.1 é lançado e substitui o 8.0 como a versão opcional durante o período de adoção, ao mesmo tempo em que o 7.9 substitui o 7.8. Isso continua a cada mês até que o período de adoção termine e a versão de aceitação se torne a versão ativa (e única) disponível.
Observe que pode haver alguns casos em que a Pequena Alteração que está sendo lançada não é aplicável à Versão Principal atual e, portanto, será aplicada apenas à nova Versão Principal e será comunicada como tal.
Cenário D - Versão principal com outra versão principal a seguir
Quando ocorre a adoção de uma versão principal, qualquer versão principal subsequente deve aguardar até que haja novamente uma única versão em produção antes de ser lançada. A D2L oferecerá suporte apenas a duas versões ativas do Conjunto de dados do Brightspace por vez.
Exemplo: 7.8 é a versão ativa atual e 8.0 é lançada como a versão opcional para permitir quatro versões antes da adoção automática. Assim que o período de adoção de 4 meses terminar, o 8.4 se tornará a versão ativa (e o 7.x não estará mais disponível) e existe a possibilidade de lançar o 9.0 como a versão opcional que iniciará seu período de adoção de 4 meses.
Links Relacionados
Diga-nos o que você pensa
Agradecemos seus comentários sobre esta política de gerenciamento de alterações e os Conjuntos de dados do Brightspace em geral. Por favor, poste perguntas e feedback no Grupo da Comunidade de Dados e Análises ou compartilhe seus comentários com seu representante de conta da D2L.
A Política de gerenciamento de alterações dos conjuntos de dados do Brightspace foi publicada em 10 de dezembro de 2018 e é atualizada periodicamente para comunicar a política atual.