Gerenciamento de versões no Jitterbit App Builder

Este artigo aborda as melhores práticas, pré-requisitos para construir uma versão e etapas a seguir para o gerenciamento geral de versões no App Builder. Para instruções detalhadas sobre como construir a versão do App Builder dentro do próprio App Builder, consulte o artigo Construir uma versão.

Melhores práticas

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

Alterações de Esquema

1. Renomear uma tabela
2. Adicionar/Modificar/Excluir uma coluna
3. Modificar uma chave primária
4. Adicionar/Modificar/Excluir uma chave estrangeira
5. Adicionar/Modificar/Excluir uma restrição única

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

Transportar todos os aplicativos e fontes de dados dependentes

Enviando apenas um aplicativo ou apenas 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 considerar 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 terá sucesso. O objeto de dados terá uma nova coluna, embora não seja utilizada pelo aplicativo. No entanto, se o desenvolvedor enviar o Aplicativo X para o QA, não incluindo 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 está vinculada não existe na fonte de dados atual no QA e, portanto, não consegue ser adicionada.

Múltiplas aplicações usando a mesma fonte de dados

Suponha que a Aplicação X e a Aplicação Y façam referência à Fonte de Dados A. Uma equipe está trabalhando na Aplicação X e outra equipe está trabalhando na Aplicação Y. Ambas as equipes adicionaram colunas a objetos de dados na Fonte de Dados A, e ambas as equipes adicionaram controles às Aplicações X e Y que estão vinculados a essas colunas. Uma das equipes também removeu um controle da Aplicação X e removeu a coluna, Coluna Z, à qual o controle estava vinculado. Se um desenvolvedor tentar enviar a Aplicação Y e a Fonte de Dados A para QA, a atualização falhará. O App Builder tentará remover a Coluna Z da Fonte de Dados A, mas a coluna ainda é referenciada pela Aplicação X em QA e, portanto, a atualização falhará ao tentar remover a coluna. É melhor incluir quaisquer aplicações e fontes de dados que sejam referenciadas 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 "Funcionário" tenha sido enviada para QA e PROD e tenha sido populada com dados de produção. Um desenvolvedor então remove todas as linhas dessa tabela para adicionar uma Coluna NÃO NULA (Ativo Booleano Permitir Nulos = Falso). Esta operação terá sucesso 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 RDBMS 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-alvo de QA e PROD. Adicione a nova coluna à tabela Funcionário, mas permita valores nulos (Ativo Booleano Permitir Nulos = Verdadeiro). Crie uma regra de migração que atualize o valor de Funcionário.Ativo para verdadeiro/falso para todos os funcionários. Execute a regra. Altere a nova coluna para Permitir Nulos = Falso. Esta operação terá sucesso no desenvolvimento e terá sucesso quando enviada para QA e PROD. O App Builder realizará as seguintes etapas durante a atualização:

1. Adicione Active à tabela Employee Permitir Nulos = Verdadeiro
2. Atualize todas as linhas de Employee para ter Active = verdadeiro/falso
3. Modifique a coluna Active para Permitir Nulos = Falso

Modificando a chave primária de uma tabela

Tenha 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 represente melhor os ambientes de QA e Prod. Existem várias maneiras de uma chave primária mudar. A seguir está um exemplo:

Suponha que Employee tenha uma coluna EmployeeId Integer Chave Primária. Também suponha que EmployeeAccrual tenha uma coluna EmployeeId Integer (chave estrangeira que referencia Employee.EmployeeId). A tabela Employee também possui uma coluna SocialSecurity (String Única Permitir Nulos = Falso).

O desenvolvedor decidiu mudar a chave primária de Employee de EmployeeId para SocialSecurity. Estes são os passos recomendados:

1. Adicione SocialSecurity String Permitir Nulo = Verdadeiro a EmployeeAccrual.
2. Crie uma regra de migração que atualiza EmployeeAccrual.SocialSecurity para ser Employee.SocialSecurity unindo as duas tabelas com base em EmployeeId. Execute a regra de migração.
3. Altere SocialSecurity em EmployeeAccrual para Permitir Nulos = Falso
4. Remova o relacionamento entre Employee e EmployeeAccrual em EmployeeId
5. Remova a coluna EmployeeId de EmployeeAccrual
6. Altere a chave primária de Employee para SocialSecurity
7. Remova a coluna EmployeeId da tabela Employee
8. Crie um relacionamento entre Employee e EmployeeAccrual em SocialSecurity

O App Builder registrará esses passos e os executará com sucesso durante a atualização do QA e Prod.

Evitar 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 através da interface do App Builder e enviar essas alterações para QA e Prod, então não utilize 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 à medida que são feitas através de sua interface. Importar uma fonte de dados contorna a interface 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. Existem situações em que a importação é suportada com gerenciamento de versões:

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

Pré-requisitos para construir uma versão

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

1. Certifique-se de que o Usuário db do App Builder tenha permissões de Criação de Tabelas e banco de dados no ambiente em que você está instalando.
2. Certifique-se de que um Administrador de Banco de Dados complete 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.
3. Certifique-se de que o pacote do ambiente que será instalado esteja rodando na mesma Versão do App Builder que o ambiente de origem está rodando.

Passos a seguir para gerenciamento de lançamentos

1. Usando os padrões da sua empresa para testes, verifique a funcionalidade do aplicativo App Builder.
2. Crie uma lista de todas as Fontes de Dados anexadas para o aplicativo para o qual você está criando um lançamento. Essas informações estão disponíveis no IDE do App Builder, construa seu aplicativo, clique no seu aplicativo e revise o Painel de Fontes de Dados resultante.
3. Crie um Modelo de Lançamento de 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 no passo 2 estejam incluídas no Modelo.
5. Verifique a configuração do Modelo para Fontes de Dados. Defina Lógico e Físico apenas para fontes de dados para as quais você gerenciará alterações de esquema com o App Builder.
6. Revise e comite quaisquer etapas abertas de gerenciamento de alterações de banco de dados para bancos de dados que estão marcados como Lógico e Instalação Física.
7. Configure o Configuração de Dados para tabelas em bancos de dados que foram marcados para Instalação Lógica e Física.
8. Uma vez que a Configuração de Dados esteja completa, confirme a Configuração de Dados.
9. Construa o lançamento. Para instruções detalhadas sobre como construir um Lançamento dentro do próprio App Builder, consulte o artigo Construir um lançamento.