Ir para o conteúdo

Gerenciamento de releases no Jitterbit App Builder

Este artigo apresenta as melhores práticas, os pré-requisitos para criar um release e as etapas a seguir para o gerenciamento geral de releases no App Builder. Para instruções detalhadas sobre como criar o release do App Builder dentro do próprio App Builder, consulte o artigo Criar um release.

Para entender como o gerenciamento de releases se encaixa em uma estratégia geral de atualização de plataforma, consulte Estratégias de atualização de produção.

Melhores práticas

O ambiente de desenvolvimento não é uma sandbox. O App Builder captura cada alteração de banco de dados, rastreia-as e as reproduzirá em QA quando o banco de dados for enviado. Dessa forma, o desenvolvedor deve aplicar alterações ao ambiente de desenvolvimento da mesma forma que esperaria que fossem aplicadas em QA e Prod. Existem dois tipos de alterações que o App Builder captura em desenvolvimento e aplica durante uma atualização de 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

Enviar apenas um aplicativo ou apenas uma fonte de dados

Embora seja possível enviar um único aplicativo ou uma única fonte de dados de Dev para 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 de Dev para QA e Prod. A seguir estão alguns cenários a considerar quando não se incluem todos os objetos dependentes:

Um designer adiciona uma coluna a um objeto de dados na Fonte de Dados A. Em seguida, 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 QA, a atualização será bem-sucedida. O objeto de dados terá uma nova coluna, embora não seja usada pelo aplicativo. No entanto, se o desenvolvedor enviasse o Aplicativo X para QA, sem incluir a Fonte de Dados A em sua solução, a atualização falharia. Ao atualizar o aplicativo, o App Builder tentará adicionar o novo controle, mas a coluna à qual está vinculado não existe na fonte de dados atual em QA e, portanto, falha ao ser adicionado.

Múltiplos 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 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 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 em QA e, portanto, a atualização falhará ao remover a coluna. É melhor incluir todos os aplicativos e fontes de dados que são referenciados na solução para garantir que a atualização seja bem-sucedida.

Adicionar uma coluna não nula

Aproveite as regras de migração. Suponha que uma tabela "Employee" tenha sido enviada para QA e PROD e tenha sido preenchida com dados de produção. Um desenvolvedor remove todas as linhas dessa tabela para adicionar uma coluna NÃO NULA (Active Boolean Allow Nulls = False). Esta operação será bem-sucedida no ambiente de desenvolvimento porque não há registros de funcionários. No entanto, quando este conjunto de alterações for aplicado em QA ou PROD, 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 delete os registros de funcionários. Deixe-os para que o ambiente seja representativo dos ambientes de destino 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 terá sucesso no desenvolvimento e terá sucesso quando enviada para QA e PROD. O App Builder executará as seguintes etapas durante a atualização:

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

Nota

Use Expressões suportadas para definir o bit Active como true/false 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 Active como False para funcionários contratados que não foram contratados no último ano, enquanto define todas as outras linhas de funcionários como Active = true.

Modificando a chave primária de uma tabela

Tome precaução 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 QA e Prod. Existem várias maneiras pelas quais uma chave primária pode 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 que referencia 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. Adicionar SocialSecurity String Allow Null = True a EmployeeAccrual.
  2. Criar uma regra de migração que atualize EmployeeAccrual.SocialSecurity para ser Employee.SocialSecurity unindo as duas tabelas em EmployeeId. Execute a regra de migração.
  3. Alterar SocialSecurity em EmployeeAccrual para Allow Nulls = False
  4. Remover o relacionamento entre Employee e EmployeeAccrual em EmployeeId
  5. Remover a coluna EmployeeId de EmployeeAccrual
  6. Alterar a chave primária de Employee para SocialSecurity
  7. Remover a coluna EmployeeId da tabela Employee
  8. Criar relacionamento entre Employee e EmployeeAccrual em SocialSecurity

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

Nota

Ao executar as etapas 1 a 8, espera-se que o desenvolvedor esteja fazendo alterações em Data Objects, Actions, Panels, Controls e assim por diante. Sinta-se livre para fazer essas alterações a qualquer momento. No exemplo acima, é possível que as 8 etapas listadas sejam executadas durante um período de 8 horas, durante o qual várias páginas, data objects e controls 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. Espera-se e é aceitável executar qualquer número de alterações na fonte de dados lógica ou no aplicativo enquanto essas etapas estão sendo executadas.

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, não use o recurso de importação para Data Sources do App Builder. Para enviar alterações feitas no desenvolvimento, o App Builder captura essas alterações conforme são feitas através de sua interface. Importar uma fonte de dados ignora 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ão:

  1. 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 é suportada.
  2. 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 é suportada.

Pré-requisitos para criar uma release

Os itens a seguir devem ser considerados e concluídos antes de criar uma Release do App Builder:

  1. Certifique-se de que o usuário do banco de dados do App Builder possui permissões de Criação de Tabela e banco de dados no ambiente em que está instalando.
  2. Certifique-se de que um Administrador de Banco de Dados conclua um backup do banco de dados tanto do banco de dados do App Builder quanto de qualquer banco de dados que sofra alterações físicas e/ou de esquema.
  3. Certifique-se de que o pacote de ambiente que será instalado está executando a mesma Versão do App Builder que o ambiente de origem está executando.

Etapas a seguir para gerenciamento de release

  1. Usando os padrões da sua empresa para testes, verifique a funcionalidade da aplicação App Builder.
  2. Crie uma lista de todas as Fontes de Dados anexadas para a aplicação para a qual está criando uma release. Essas informações estão disponíveis no IDE do App Builder, Construir sua aplicação, clique em sua aplicação e revise o Painel de Fontes de Dados resultante.
  3. Crie um Modelo de Release de aplicação e certifique-se de que todas as aplicações que devem ser promovidas estejam incluídas.
  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 cujas alterações de esquema você gerenciará com o App Builder.
  6. Revise e confirme todas as etapas abertas de gerenciamento de alterações de banco de dados para bancos de dados marcados como Instalação Lógica e Física.
  7. Configure a Configuração de Dados para tabelas em bancos de dados marcados para Instalação Lógica e Física.
  8. Após a conclusão da Configuração de Dados, confirme a Configuração de Dados.
  9. Crie a release. Para instruções detalhadas sobre como criar uma Release no próprio App Builder, consulte o artigo Criar uma release.