Gerenciamento de Liberação¶

Este artigo aborda as melhores práticas, pré-requisitos para a construção de uma versão e etapas a serem seguidas para o gerenciamento geral de versões em App Builder. Para obter instruções detalhadas sobre como construir o App Builder liberação dentro de App Builder em si, veja Construir uma versão artigo.

Melhores Práticas¶

O ambiente de desenvolvimento não é uma sandbox. App Builder está capturando cada alteração do banco de dados, rastreando-as e as reproduzirá no QA quando o banco de dados for enviado. Como tal, o desenvolvedor deve aplicar as alterações ao ambiente de desenvolvimento da mesma forma que esperaria que as alterações fossem aplicadas no QA e no Prod. Existem dois tipos de alterações que App Builder captura em desenvolvimento e aplica durante uma atualização de QA e PROD:

Alterações de esquema

1. Renomeando uma tabela
2. Adicionar/Modificar/Excluir uma coluna
3. Modificando uma chave primária
4. Adicionar/Modificar/Excluir uma chave estrangeira
5. Adicionar/Modificar/Excluir uma restrição exclusiva

Regras de migração - As regras de migração são definidas de forma semelhante a uma regra Criar/Atualizar/Excluir e são executadas no ambiente de desenvolvimento. App Builder registra a regra e a executa durante uma atualização.

Transporte Todos os Aplicativos e Fontes de Dados Dependentes¶

Envio Apenas de um Aplicativo Ou Apenas de uma Fonte de Dados¶

Embora seja possível enviar um único aplicativo ou uma única fonte de dados do Dev para o QA, isso deve ser feito apenas por administradores avançados com conhecimento detalhado das alterações que estão sendo enviadas com o objeto. Em geral, é melhor incluir todos os objetos dependentes ao enviar uma solução do Dev para o QA e Prod. A seguir estão alguns cenários a serem considerados ao não incluir todos os objetos dependentes:

Um designer adiciona uma coluna a um objeto de dados na Fonte de Dados A. Em seguida, ele adiciona um controle a um painel no Aplicativo X que está vinculado à nova coluna. Se o desenvolvedor tentar enviar a Fonte de Dados A para o QA, a atualização será bem-sucedida. O objeto de dados terá uma nova coluna, embora ela não seja usada pelo aplicativo. No entanto, se o desenvolvedor enviou o Aplicativo X para o QA, sem incluir a Fonte de Dados A em sua solução, a atualização falhará. Ao atualizar o aplicativo, App Builder tentarei adicionar o novo controle, mas a coluna à qual ele está vinculado não existe na fonte de dados atual no QA e, portanto, ele falha ao ser adicionado.

Vários Aplicativos Usando a Mesma Fonte de Dados¶

Suponha que o Aplicativo X e o Aplicativo Y façam referência à Fonte de Dados A. Uma equipe está trabalhando no Aplicativo X e outra equipe está trabalhando no Aplicativo Y. Ambas as equipes adicionaram colunas a objetos de dados na Fonte de Dados A, e ambas as equipes adicionaram controles aos Aplicativos X e Y que estão vinculados a essas colunas. Uma das equipes também removeu um controle do Aplicativo X e removeu a coluna, Coluna Z, à qual o controle estava vinculado. Se um desenvolvedor tentar enviar o Aplicativo Y e a Fonte de Dados A para o QA, a atualização falhará. App Builder tentará remover a Coluna Z da Fonte de Dados A, mas a coluna ainda é referenciada pelo Aplicativo X no QA e, portanto, a atualização falhará ao remover a coluna. É melhor incluir quaisquer aplicativos e fontes de dados que sejam referenciados na solução para garantir que a atualização seja bem-sucedida.

Adicionando uma Coluna Não Nula¶

Aproveite as regras de migração. Suponha que uma tabela "Employee" foi enviada para QA e PROD e foi preenchida com dados de produção. Um desenvolvedor então remove todas as linhas dessa tabela para adicionar uma coluna NON NULL (Active Boolean Allow Nulls = False). Essa operação será bem-sucedida no ambiente de desenvolvimento porque não há registros de funcionários. No entanto, quando esse conjunto de alterações é aplicado em QA ou PROD, ele falhará. Um banco de dados RDMBs não permitirá que uma coluna não nula seja adicionada a uma tabela que contém linhas.

Em vez disso, no ambiente de desenvolvimento, não exclua os registros de funcionários. Deixe-os de modo que o ambiente seja representativo dos ambientes de destino de QA e PROD. Adicione a nova coluna à tabela Employee, mas permita valores nulos (Active Boolean Allow Nulls = True). Crie uma regra de migração que atualize o valor de Employee.Active para true/false para todos os funcionários. Execute a regra. Altere a nova coluna para Allow Nulls = False. Esta operação será bem-sucedida no desenvolvimento e será bem-sucedida quando enviada para QA e PROD. App Builder executará as seguintes etapas durante a atualização:

1. Adicionar Ativo à tabela Employee Allow Nulls = True
2. Atualizar todas as linhas Employee para ter Ativo = true/false
3. Modificar a coluna Ativo para Allow Nulls = False

Modificando a Chave Primária de uma Tabela¶

Tome cuidado ao modificar uma chave primária em uma tabela que já foi enviada para QA e contém dados. Novamente, é melhor garantir que o ambiente de desenvolvimento tenha dados na tabela, para que ela represente melhor os ambientes QA e Prod. Há várias maneiras de uma chave primária mudar. A seguir está um exemplo:

Suponha que Employee tenha uma coluna EmployeeId Integer Primary Key. Suponha também que EmployeeAccrual tenha uma coluna EmployeeId Integer (chave estrangeira faz referência a Employee.EmployeeId). A tabela Employee também tem uma coluna SocialSecurity (String Unique Allow Nulls = False).

O desenvolvedor decidiu alterar a chave primária de Employee de EmployeeId para SocialSecurity. Estas são as etapas recomendadas:

1. Adicione SocialSecurity String Allow Null = True para EmployeeAccrual.
2. Crie uma regra de migração que atualize EmployeeAccrual.SocialSecurity para Employee.SocialSecurity unindo as duas tabelas em EmployeeId. Execute a regra de migração.
3. Altere SocialSecurity em EmployeeAccrual para Permitir Nulos = Falso
4. Solte o relacionamento entre Employee e EmployeeAccrual em EmployeeId
5. Remova a coluna EmployeeId de EmployeeAccrual
6. Alterar chave primária de Employee para SocialSecurity
7. Remova a coluna EmployeeId da tabela Employee
8. Crie um relacionamento entre Employee e EmployeeAccrual no SocialSecurity

App Builder registrará essas etapas e as executará com sucesso ao atualizar QA e Prod.

Evite Importar Esquema¶

Se a intenção é mover um banco de dados físico de Dev para Qa para Prod, e modificar ainda mais esse banco de dados físico por meio do App Builder uI e envie essas alterações para QA e Prod, então não use o recurso de importação para App Builder fontes de dados. Para enviar as alterações feitas no desenvolvimento, App Builder captura essas alterações conforme elas são feitas por meio de sua IU. A importação de uma fonte de dados ignora o App Builder uI, sincronizando o App Builder modelo lógico para corresponder ao modelo físico da fonte de dados importada. Portanto, nenhuma alteração na fonte de dados importada seria propagada durante uma atualização. Há situações em que a importação é suportada com o gerenciamento de versão:

1. Se o banco de dados físico for mantido e modificado fora de App Builder em todos os ambientes, então a importação da fonte de dados durante todo o ciclo de vida do desenvolvimento é suportada.
2. Se o banco de dados físico for compartilhado por Dev/Qa/Prod, então a importação da fonte de dados durante todo o ciclo de vida do desenvolvimento é suportada.

Pré-requisitos para Construir uma Versão¶

Os seguintes itens devem ser considerados e concluídos antes da construção an App Builder liberação:

1. Garanta que o App Builder o usuário db tem permissões de criação de tabela e banco de dados no ambiente em que você está instalando.
2. Certifique-se de que um administrador de banco de dados conclua um backup do banco de dados de ambos App Builder banco de dados e qualquer banco de dados que esteja passando por alterações físicas e/ou de esquema.
3. Certifique-se de que o pacote de ambiente que será instalado esteja sendo executado na mesma versão do App Builder no qual o ambiente de origem está sendo executado.

Etapas a Seguir para Gerenciamento de Liberação¶

1. Usando os padrões da sua empresa para testes, verifique a funcionalidade do App Builder aplicação.
2. Crie uma lista de todas as Fontes de Dados anexadas para o aplicativo para o qual você está construindo uma versão. Essas informações estão disponíveis em App Builder IDE, crie seu aplicativo, clique nele e revise o Painel de Fontes de Dados resultante.
3. Crie um Modelo de versão do aplicativo e garanta que todos os aplicativos que devem ser promovidos estejam incluídos.
4. Certifique-se de que todas as Fontes de Dados vinculadas identificadas na etapa 2 estejam incluídas no Modelo.
5. Verifique a configuração do modelo para fontes de dados. Defina apenas Lógico e Físico para fontes de dados para as quais você gerenciará as alterações de esquema com App Builder.
6. Revise e confirme quaisquer etapas de gerenciamento de alterações de banco de dados aberto para bancos de dados que estão marcados como Instalação Lógica e Física.
7. Configure a Configuração de Dados para tabelas em bancos de dados que foram marcados para Instalação Lógica e Física.
8. Assim que a Configuração de Dados estiver concluída, confirme a Configuração de Dados.
9. Crie a versão. Para obter instruções detalhadas sobre como criar uma versão em App Builder em si, veja Construir uma versão artigo.