Gerenciamento de versão no Jitterbit App Builder

Este artigo aborda as melhores práticas, pré-requisitos para criar um Release e etapas a serem seguidas para o Gerenciamento geral de Release no App Builder. Para obter instruções detalhadas sobre como criar o App Builder Release dentro do próprio App Builder, consulte Criar um release artigo.

Melhores práticas

O ambiente de desenvolvimento não é um sandbox. O App Builder captura cada alteração do banco de dados, rastreia-as e as reproduz no QA quando o banco de dados é 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 o App Builder captura no desenvolvimento e aplica durante uma atualização do QA e do PROD:

Alterações de esquema

Renomeando uma tabela
Adicionar/Modificar/Excluir uma coluna
Modificando uma chave primária
Adicionar/Modificar/Excluir uma chave estrangeira
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. O 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, o App Builder tentará adicionar o novo controle, mas a coluna à qual ele está vinculado não existe na fonte de dados atual no QA e, portanto, não 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á. O 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 for 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 para 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. O App Builder executará as seguintes etapas durante a atualização:

Adicionar Ativo à tabela de Funcionários Permitir Nulos = Verdadeiro
Atualize todas as linhas de funcionários para que Ativo = verdadeiro/falso
Modifique a coluna Ativo para Permitir Nulos = Falso

Nota

Use Expressões suportadas para definir o bit Ativo como verdadeiro/falso com base em condições práticas. Normalmente, ao adicionar uma coluna a uma tabela, não se espera que todas as linhas tenham o mesmo valor para essa coluna. Neste cenário, a regra de migração pode definir Ativo como Falso para funcionários contratados que não foram contratados no ano passado, enquanto define todas as outras linhas de funcionários como Ativo = verdadeiro.

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:

Adicione SocialSecurity String Allow Null = True para EmployeeAccrual.
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.
Altere SocialSecurity em EmployeeAccrual para Permitir Nulos = Falso
Solte o relacionamento entre Employee e EmployeeAccrual em EmployeeId
Remova a coluna EmployeeId de EmployeeAccrual
Alterar chave primária de Employee para SocialSecurity
Remova a coluna EmployeeId da tabela Employee
Crie um relacionamento entre Employee e EmployeeAccrual no SocialSecurity

O App Builder registrará essas etapas e as executará com sucesso durante a atualização do QA e da produção.

Nota

Ao executar as etapas de 1 a 8, espera-se que o desenvolvedor faça alterações em Objetos de Dados, Ações, Painéis, Controles e assim por diante. Sinta-se à vontade para fazer essas alterações a qualquer momento. No exemplo acima, é possível que as 8 etapas listadas sejam executadas em um período de 8 horas durante o qual várias páginas, objetos de dados e controles também são alterados em vários estágios. O ponto importante é executar as etapas listadas na ordem correta, para que sejam executadas na ordem correta durante uma atualização. É esperado e aceitável executar qualquer número de alterações na fonte de dados lógica ou no aplicativo ao executar essas etapas.

Evite importar esquema

Se a intenção for 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 da interface do usuário do App Builder e enviar essas alterações para QA e Prod, não use o recurso de importação para fontes de dados do App Builder. Para enviar alterações feitas no desenvolvimento, o App Builder captura essas alterações conforme elas são feitas por meio de sua interface do usuário. A importação de uma fonte de dados ignora a interface do usuário do App Builder, sincronizando o modelo lógico do App Builder 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:

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

Pré-requisitos para construir uma versão

Os seguintes itens devem ser considerados e concluídos antes de criar uma versão do App Builder:

Certifique-se de que o usuário do banco de dados do App Builder tenha permissões para criar tabelas e bancos de dados no ambiente em que você está instalando.
Certifique-se de que um administrador de banco de dados conclua um backup do banco de dados do App Builder e de qualquer banco de dados que esteja passando por alterações físicas e/ou de esquema.
Certifique-se de que o pacote de ambiente que será instalado esteja sendo executado na mesma versão do App Builder em que o ambiente de origem está sendo executado.

Etapas a seguir para gerenciamento de liberação

Usando os padrões da sua empresa para testes, verifique a funcionalidade do aplicativo App Builder.
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 no App Builder IDE, Construa seu aplicativo, clique em seu aplicativo e revise o Painel de Fontes de Dados resultante.
Crie um Modelo de versão do aplicativo e garanta que todos os aplicativos que devem ser promovidos estejam incluídos.
Certifique-se de que todas as Fontes de Dados vinculadas identificadas na etapa 2 estejam incluídas no Modelo.
Verifique a configuração do Template para Data Sources. Defina apenas Logical e Physical para data sources que você gerenciará alterações de esquema com o App Builder.
Revise e confirme todas as etapas de gerenciamento de alterações de banco de dados abertas para bancos de dados marcados como Instalação lógica e instalação física.
Configure a Configuração de Dados para tabelas em bancos de dados que foram marcados para Instalação Lógica e Física.
Quando a Configuração de dados estiver concluída, confirme a Configuração de dados.
Crie a versão. Para obter instruções detalhadas sobre como criar uma versão dentro do próprio App Builder, consulte Criar uma versão artigo.