Como construir um pacote de release no Jitterbit App Builder
Introdução
Esta página mostra como construir um pacote de release, que é uma coleção selecionada de aplicações, fontes de dados e outros componentes, empacotados juntos para implantação. Esse processo é usado ao mover uma aplicação de um ambiente para outro, por exemplo, ao mover uma aplicação de ambientes de desenvolvimento para ambientes de QA e, de lá, para ambientes de produção.
O diagrama a seguir mostra o que um release contém.
Legenda
-
As cores mostram em qual camada cada tipo de objeto reside:
Cor Camada Azul Dados Vermelho Negócios Verde Interface de Usuário Laranja Outro -
As formas indicam o tipo de objeto:
%%{init: {"themeVariables": {"lineColor": "#6b7280", "edgeLabelBackground": "#f5f5f5"}}}%% graph SOLN_OBJ(Solution object) NON_SOLN_OBJ((Non-solution
object)) classDef default fill:white,stroke:black,stroke-width:1px,rx:15px,ry:15px
translation)) end subgraph ASSEMBLIES[**Assembly**] PLUGINS((Plugin)) end end subgraph UI[ ] subgraph APPLICATIONS[**Application**] direction LR MENUS((Menu)) PAGES(Page) SCHEDULES((Schedule)) end subgraph COLLECTIONS[**Collections**] direction LR THEMES((Theme)) IMAGES((Image)) TEMPLATES((Template)) FORMATS((Format)) WIDGETS(Widget) end end subgraph DATA_SOURCES[**Data Source**] direction LR DATA(Data) RULES(Rule) LOGICAL_PHYSICAL_DATA_MODEL(Logical/physical
data model) ROLES(Role) SQL_OBJECTS(SQL object) end end %% General styling classDef defaultSg fill:white,stroke-width:5px,rx:15px,ry:15px class DATA_SOURCES,APPLICATIONS,COLLECTIONS,OTHER,ASSEMBLIES,BUNDLES defaultSg classDef clearSg fill:transparent,stroke-width:0px class UI,OTHER clearSg classDef boundary fill:white,stroke-width:0px,rx:15px,ry:15px class BOUNDARY boundary %% Identifying styling: Subgraphs classDef dataSg stroke:#3b6fc9 class DATA_SOURCES dataSg classDef uiSg stroke:#098565 class APPLICATIONS,COLLECTIONS uiSg classDef otSg stroke:orange class ASSEMBLIES,BUNDLES otSg %% Identifying styling: Nodes classDef dataNode fill:#3b6fc9, color:white class DATA,LOGICAL_PHYSICAL_DATA_MODEL,SQL_OBJECTS dataNode classDef businessNode fill:#db2b48, color:white class RULES,ROLES businessNode classDef uiNode fill:#098565, color:white class THEMES,IMAGES,TEMPLATES,FORMATS,WIDGETS,MENUS,PAGES uiNode classDef otherNode fill:orange class SCHEDULES,PLUGINS,LANGUAGE_TRANSLATIONS,USER_DEFINED_FUNCTIONS,LOGICAL_DATA_TYPE otherNode
Construir um release
Construir um release em um pacote e depois instalar um pacote em um novo ambiente acontece tudo na área Deploy, acessada pelo IDE do App Builder. Durante esse processo, você se move do lado esquerdo da tela Release Template Builder para o lado direito, conforme avança por todas as etapas descritas aqui:
-
Selecione Action Drawer > IDE.
-
Selecione Deploy > Create Release.
-
Para iniciar uma construção, é possível selecionar um template existente (se estiver atualizando um upgrade de aplicação existente) ou clicar em + Release para criar um novo template.
-
Se usar um template existente, clique no botão Template do registro de template existente.
-
Atualize os campos Name, Version e Developer na tela Release Details para refletir a construção que está criando:

-
Clique no botão Next.
-
Na tela Solution Objects, escolha o que entra no pacote de release. As opções são as seguintes:
- Application
- Assembly
- Bundle
- Collection
- Data Source
- Function
- Logical Data Type
- Page
- Role
- Rule
- SQL Object
- Widget
Para adicionar qualquer um desses, clique no botão + Object, selecione o tipo no menu e clique no botão Save:

Notas
Os seguintes pontos se aplicam aos pacotes de release:
-
Ao adicionar um objeto de aplicação, o bundle da aplicação e a fonte de dados são adicionados automaticamente ao pacote de release.
-
O pacote de release não inclui grupos de instância, provedores de segurança de instância ou credenciais de servidor.
-
Objetos recém-suportados (como funções e tipos de dados lógicos) não são adicionados automaticamente a templates pré-existentes. É necessário adicioná-los manualmente.
-
Clique no botão Next.
-
A tela Configure Data Sources lista todas as fontes de dados relevantes para a construção do release. (Se não houver fontes de dados, esta etapa é ignorada.) Para cada fonte de dados listada, marque a coluna Include e certifique-se de que está configurada conforme desejado para a construção. Dependendo do tipo de fonte de dados, qualquer uma das seguintes opções está disponível:
- Logical Model Only: Use quando quiser empacotar apenas os dados criados e que existem no próprio App Builder. Exemplos: dados e objetos de negócio, subconsultas, CRUDs, fluxo de trabalho, pontes. Esta opção é geralmente usada para fontes de dados que não são de sua propriedade e/ou não são mantidas via App Builder (fontes de dados externas, fontes de dados de API, etc.).
-
Somente Modelo Físico: Use quando desejar empacotar apenas as estruturas de tabelas e colunas da fonte de dados, sem os dados.
-
Modelo Lógico e Tabelas Físicas: Use quando desejar trazer todos os dados existentes no próprio App Builder, bem como as estruturas de tabelas e colunas da fonte de dados subjacente. Aqui, físico refere-se ao App Builder manter ou fazer atualizações na camada de banco de dados real. Se você mover um modelo Físico, isso significa que todas as alterações feitas no dev no banco de dados também serão feitas no banco de dados QA/Prod ao mover o LP. Essa opção geralmente é usada para fontes de dados que você gerencia.
-
Não Incluir: Use se não desejar incluir essa fonte de dados nesta versão.
Importante
Se você tem alterações de banco de dados que precisam ser confirmadas, você deve mover Lógico e Físico para esse banco de dados. O processo de Gerenciamento de Versão suporta a importação de Tabelas. Se você importar Tabelas em uma fonte de dados, essas Tabelas importadas serão criadas no sistema de destino se fizerem parte do primeiro conjunto de alterações Físicas.
-
Clique no botão Próximo.
-
Se você tiver traduções em seu aplicativo, a tela Pacotes de Solução aparece. Caso contrário, a tela Notas de Versão aparece com informações gerais sobre o pacote de versão:

-
Nome: O nome do seu aplicativo.
-
Versão: O número de versão do pacote sendo criado.
-
Data de Versão: A data em que você deseja que a versão apareça (essa é uma data suave e pode ser diferente da data de versão real).
-
Data de Compilação: A data em que você confirmou o pacote.
-
Data de Publicação: A data em que você lançou o pacote.
-
Descrição do Modelo: Uma descrição em texto do que seu aplicativo ou suite faz.
-
-
Clique no botão Próximo.
-
Analise as informações na tela Publicar e clique no botão Concluir.
Você agora deve estar de volta na tela Construtor de Modelo de Versão com a coluna Pronto contendo uma marca de seleção verde.
-
Clique no botão Alterações de Banco de Dados e você saberá que tem alterações não confirmadas para revisar e confirmar se vir uma marca de seleção vermelha aparecer na coluna DB na tela Construtor de Modelo de Versão. A tela Solicitações de Gerenciamento de Alterações lista todas as alterações relacionadas à fonte de dados que farão parte do pacote. Se você vir alguma alteração listada com uma marca de seleção vermelha na coluna Status, isso exige que você clique manualmente nela para revisar e aprovar.
Clicar para revisar o traz para a tela Solicitação de Gerenciamento de Alterações. Aqui, o campo Número do Patch é preenchido automaticamente com um valor e indica qual iteração essa atualização de pacote reflete. Certifique-se de revisar todas as entradas listadas no painel Alterações para garantir que essas informações sejam o que você espera que se mova com o pacote. Nesta tela você precisa inserir:
-
Número de Referência: Isso pode espelhar o valor do Número do Patch, ser uma referência de ticket JIRA ou AHA, ou usar um valor de numeração do cliente.
-
Descrição Breve: Forneça uma descrição em texto sobre o pacote. Se desejar, insira informações adicionais no campo Comentários.
-
-
Clique no botão Salvar e, se estiver pronto para prosseguir, clique no botão Fechar esta Solicitação.
-
Feche as telas restantes para que você esteja olhando para a tela Construtor de Modelo de Versão. Agora você verá uma marca de seleção verde aparecer na coluna DB.
-
O Configuração de Dados é opcional e usado apenas se você estiver movendo Dados Lógicos e Físicos com o pacote. Na tela Configuração de Dados você terá itens de linha de todas as fonte de dados, tabelas para a fonte de dados, juntamente com qual Tipo de Proprietário foi atribuído, junto com a ação correspondente que acontece quando a tabela é movida para esse ambiente. Os diferentes Tipos de Proprietários são os seguintes:
- Dados do Usuário: Não transferirá nenhum dos dados. Os usuários em cada ambiente são responsáveis por preencher essa tabela. Por exemplo: Clientes ou Pedidos, que são tabelas transacionais.
-
Compartilhar Dados: Insere os novos registros apenas no próximo ambiente. Por exemplo: Email Templates, uma tabela que você deseja que o usuário personalize com alterações.
-
Dados do Desenvolvedor: Trunca a tabela em QA e insere todos os registros do pacote. Isso é normalmente usado para tabelas de consulta ou tabelas que fazem parte de uma configuração. Por exemplo: CustomerType, EmployeeType.
-
As informações podem ser substituídas manualmente para Owner Types e definidas para o pacote específico, ou você pode simplesmente clicar em Confirm Config. Isso marca este processo como concluído e retorna à tela Release Template Builder. Observe que a melhor prática da metodologia Jitterbit é sempre definir o valor Install Option no nível da tabela, que mapeia para Owner Type na tela Release Template Builder. As opções de Install Options são User Data, Share Data e Developer Data. Se os valores forem definidos no nível da tabela, essas configurações serão transferidas para o pacote de lançamento. Definir essas informações no nível da tabela é útil para projetos com múltiplos membros da equipe.
-
A área SQL Config permite que você escolha o banco de dados e veja se há algum objeto (exibições ou procedimentos armazenados) armazenado no banco de dados na camada SQL nativa. Isso permitirá que você mova exibições ou procedimentos armazenados. Essas informações não preencherão automaticamente a tela Code resultante, e você precisará clicar manualmente no botão Create e adicioná-las. Esta etapa é normalmente usada apenas em situações avançadas e não é uma etapa obrigatória.
-
A etapa Build exibirá a versão para este lançamento, permitirá que você adicione observações específicas deste lançamento e permitirá que você selecione uma opção para tirar um snapshot antes de compilar. Ao estruturar suas notas de lançamento, você deve usar um formato como a captura de tela a seguir. Seguir um processo consistente para nomear suas notas de lançamento ao longo do tempo é importante, especialmente se seu projeto é um que tem múltiplas pessoas trabalhando nele. Isso se torna um registro contínuo das notas de lançamento do app.
-
Clique no botão Build Package, que inicia um trabalho em segundo plano que compila o pacote. Não há notificação que avise quando o pacote é concluído e/ou falha. Para verificar o status do processo, acesse App Builder IDE, Manage Servers and Schedules e verifique o painel Instance Running Jobs.
-
O botão Reset limparia todas as informações associadas ao modelo de pacote e permitiria que você começasse do zero para sua compilação de pacote.
-
Clique no ícone
Packages que o leva à tela Solution Releases, que contém o arquivo LP baixável criado para o próximo ambiente. Este é o arquivo que você levará para instalar no próximo ambiente. Nesta tela, baixe o arquivo Package e armazene-o localmente em seu computador. -
Com o arquivo LP disponível, vá para seu próximo ambiente onde o instalará (QA ou Prod). De lá, acesse Deploy your Application no App Builder IDE e clique no botão Install Release.
Dica
Para ver o conteúdo do pacote antes de instalar, clique no botão Manifest.
-
Clique no botão Create e Browse para localizar o arquivo Package e clique em Save. Ao salvar, você verá o painel Solution à direita exibir as informações do pacote sobre Name, Version, Developer, Release Date, Description e Release Notes.
-
Clique no botão Install após confirmar que este é o pacote que deseja instalar. Este processo é executado em primeiro plano. Se tiver sucesso, você receberá uma mensagem de sucesso. Se falhar, acesse Logs > App Server Fast Logs e você verá informações de erro específicas sobre por que a instalação falhou.
Agendas e pacotes de lançamento
As agendas serão incluídas em um Release Package (ou LP) a menos que sejam removidas manualmente ao compilar o Package. Por design, as agendas que foram implantadas em um ambiente de Production estão "lacradas" ou impedidas de fazer certas edições nas informações de Schedule. Isso impede que alguém acidentalmente faça alterações de desenvolvimento em um ambiente downstream, o que pode levar a vários problemas ao tentar implantar o app no futuro. As agendas fazem parte de um aplicativo, portanto estão "lacradas" nesses ambientes downstream. Você pode ativar ou desativar agendas ou ajustar a hora, mas não consegue alterar o tipo de execução de uma Schedule.
Existem alguns cenários nos quais você pode configurar um Agendamento no Dev, mas uma vez em Produção, o Agendamento do Dev fica desativado. Por exemplo, ao interagir com uma API. Talvez você queira interagir com uma API apenas no ambiente de Produção, portanto, depois que o Dev estiver concluído, você pode desativar o Agendamento no ambiente de Desenvolvimento.
Depois que um Agendamento é adicionado a um LP, observe que nem todas as alterações de Agendamento serão incluídas em futuras Compilações de um pacote. Se você adicionar ou remover Eventos associados a um Agendamento, essas alterações serão refletidas em uma nova Compilação. Outras alterações na definição de um Agendamento não serão incluídas em futuras Compilações.
Para fazer alterações em um Agendamento de Produção que está lacrado, você pode criar um novo Agendamento que será incluído no próximo LP. Esse processo garante que o Agendamento seja criado corretamente com as novas configurações refletidas nos ambientes a jusante.