Migrar o histórico do conjunto de atualizações concluído para o Controle de código-fonte

Ao vincular ao Controle de código-fonte, este recurso permite que os desenvolvedores de aplicações tenham a opção de migrar as informações em conjuntos de atualizações concluídos para o histórico do Controle de código-fonte.

Antes de migrar

Verifique se você atendeu a estes critérios antes de tentar migrar seus conjuntos de atualizações:

• Função necessária: administrador
• Leia o tópico Vincular uma aplicação ou personalização de aplicação ao controle de código-fonte
• Conclua todos os conjuntos de atualizações da aplicação que você deseja exportar como histórico do Controle de código-fonte.
• Exporte o conjunto de atualizações concluído se quiser preservá-lo.

Quando você vincula uma aplicação ao Controle de código-fonte, os conjuntos de atualizações e os registros de atualização do cliente são excluídos. Depois de vincular ao Controle de código-fonte, se a aplicação tiver conjuntos de atualizações concluídos, você será solicitado a fazer uma escolha na caixa de diálogo abaixo.

• Se você selecionar “Sim, manter o histórico do conjunto de atualizações como confirmações”, o histórico do conjunto de atualizações será preservado como confirmações do Controle de código-fonte.
• Se você selecionar "Não, não retenha o histórico do conjunto de atualizações como confirmações", eles não serão preservados como confirmações.

Independentemente da opção selecionada, se você selecionar Continuar, a operação Vincular ao controle de código-fonte será iniciada e todos os conjuntos de atualizações concluídos e todos os registros de atualização do cliente serão excluídos. Se você precisar concluir quaisquer conjuntos de atualizações adicionais ou optar por não continuar, selecione Cancelar.

Para cada conjunto de atualizações concluído com atualizações para a aplicação que você está vinculando ao Controle de código-fonte, as confirmações são geradas automaticamente pelo sistema com base nos registros sys_update_xml nos conjuntos de atualizações. As confirmações são ordenadas pelo carimbo de data/hora sys_recorded_at. Para aplicações globais: todos os registros sys_update_xml que pertencem à aplicação e fazem parte de um conjunto de atualizações global concluído são capturados como confirmações históricas.

Quando a operação Vincular ao controle de código-fonte é concluída, a confirmação mais recente é o estado atual da sua aplicação em sua totalidade. Você pode exibir confirmações históricas no repositório Git ou clicando na opção de menu Controle de código-fonte e selecionando Exibir histórico. As atualizações são separadas em várias confirmações:

• Se houver atualizações para um arquivo que estão fora de ordem entre diferentes conjuntos de atualizações.
• Se um conjunto de atualizações contiver vários registros de atualização para um único arquivo.

As confirmações de um conjunto de atualizações são divididas em várias confirmações ([Confirmação de histórico 1], [Confirmação de histórico 2]...) para representar cada atualização. Isso é feito para que cada arquivo tenha um histórico ordenado de atualizações.

Aviso:

Qualquer confirmação prefixada por [Confirmação de histórico] é gerada exclusivamente para exibir seu histórico. Não tente fazer check-out dessas confirmações no processo de desenvolvimento, pois elas não representam necessariamente um snapshot estável da aplicação.

A pasta autor_elective_update não é criada até a confirmação inicial. Isso significa que, na confirmação inicial, você pode ver arquivos como arquivos sys_choice sendo renomeados e movidos da pasta de atualização para a pasta de autor_elective_update. Todos os arquivos excluídos dos conjuntos de atualizações em confirmações históricas são excluídos e não movidos para a pasta autor_elective_update como seriam para confirmações reais. Durante a confirmação inicial, as cargas DELETE também são criadas para todos os registros SYS_update_xml DELETE que foram excluídos como parte dos conjuntos de atualizações concluídos.

Exemplo de mensagem de confirmação:

[Historical Commit 1] <Name of update set that this commit belongs to>
Description: <Description of update set that this commit belongs to>
Update Set was completed on / installed on <date>
Update Set was completed by <sys_user user_name > <sys_user email>
{

Valores adicionais do registro sys_update_set (consulte a seção Personalização abaixo)

}
{

Informações do conjunto de atualizações em lote: consulte a seção Conjuntos de atualizações em lote abaixo.

Conjuntos de atualizações em lote

Se um conjunto de atualizações fizer parte de um conjunto de atualizações em lote, essas informações serão anexadas à mensagem de confirmação no seguinte formato, com o número mais alto sendo a base do lote:

{
"1": {
"parent": "<name of parent update set>",
"description": "<description of parent update set>"
},
"2": {
"parent": " <name of parent 1’s parent update set> ",
"description": " <description of parent 1’s parent update set> "
}
}

Personalização

Você pode adicionar mais campos a serem incluídos na mensagem de confirmação adicionando uma propriedade glide.source_control.historical_commit_fields. O valor é uma lista separada por vírgulas de campos que o usuário deseja incluir dos campos XML sys_update_set. Espaços e nomes de campo inválidos ou com erros ortográficos são ignorados. Esta propriedade será usada para todas as aplicações vinculadas ao controle de código-fonte da instância se o confirmador optar por manter o histórico do conjunto de atualizações.

Nota:

Se o valor de um campo fizer referência a outra tabela ou sys_id, somente o valor do campo será adicionado. Por exemplo: sys_id para um usuário em vez do nome do usuário.

Figura 1. Exemplo de XML

Figura 2. Valor da propriedade

Figura 3. Resultado na mensagem de confirmação