Legado - Migrar histórico de conjunto de atualizações concluído para o controle de origem
Ao vincular ao controle de origem, este recurso permite que os desenvolvedores de aplicações escolham migrar as informações em conjuntos de atualizações concluídos para o histórico do controle de origem.
Tente criar e editar apps na versão atual de ServiceNow Studioem vez disso. Para obter mais informações, consulte ServiceNow Studio.
Antes de migrar
- Função necessária: administrador
- Leia Legado - Vincular uma aplicação ou aplicação-customização ao controle de origemtópico
- Conclua todos os conjuntos de atualizações da sua aplicação que você deseja exportar como histórico de controle de origem.
- Exporte o conjunto de atualizações concluído se quiser preservá-lo.
- Se você selecionar "Sim, manter 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 origem.
- Se você selecionar "Não, não reter o histórico do conjunto de atualizações como confirmações", eles não serão preservados como confirmações.
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 por sys_recorded_at carimbo de data/hora. Para aplicações globais: Qualquer sys_update_xml Os registros que pertencem à aplicação e fazem parte de um conjunto de atualizações globais concluído são capturados como confirmações históricas.
- 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 histórica 1], [Confirmação histórica 2]...) para representar cada atualização. Isso é feito para que cada arquivo tenha um histórico ordenado de atualizações.
. author_elective_update a pasta não é criada até a confirmação inicial. Isso significa que na confirmação inicial, você pode ver arquivos como sys_choice arquivos sendo renomeados e movidos da pasta de atualização para author_elective_update pasta. Todos os arquivos excluídos de conjuntos de atualizações em confirmações históricas serão excluídos e não movidos para author_elective_update como seriam para confirmações reais. Durante a confirmação inicial, as cargas de EXCLUSÃO também são criadas para todos os registros sys_update_xml de EXCLUSÃO que foram excluídos como parte dos conjuntos de atualizações concluídos.
[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>
{}
{Informações do conjunto de atualizações em lote: Consulte 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 em 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 campos adicionais para incluir na mensagem de confirmação adicionando um glide.source_control.historical_commit_fields propriedade. 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 campos inválidos ou com erros ortográficos são ignorados. Esta propriedade é usada para todas as aplicações vinculadas ao Controle de código-fonte da instância se o committer optar por manter o histórico do conjunto de atualizações.