Como construir um pacote de lançamento
Esta página mostra como criar um pacote de lançamento, que é uma coleção selecionada de aplicativos, fontes de dados e outros componentes, empacotados juntos para implantação. Este processo é usado ao mover um aplicativo de um ambiente para outro, por exemplo, ao mover um aplicativo de ambientes de desenvolvimento para QA e, de lá, para ambientes de produção.
Crie uma versão
A construção de uma versão em um pacote e a instalação de um pacote em um novo ambiente ocorrem na área Implantar, acessada a partir do App Builder IDE. Durante esse processo, você passará do lado esquerdo da tela Release Template Builder para o lado direito, conforme você avança em todas as etapas descritas aqui:
-
Selecione Gaveta de ação > IDE.
-
Selecione Implementar > Criar versão.
-
Para iniciar uma compilação, você pode selecionar um modelo existente (se estiver atualizando uma atualização de aplicativo existente) ou clicar em + Versão para criar um novo modelo.
-
Se estiver usando um modelo existente, clique no botão Modelo para o registro do modelo existente.
-
Atualize os campos Nome, Versão e Desenvolvedor na tela Detalhes da versão para refletir a compilação que você está criando:
-
Clique no botão Avançar.
-
Na tela Objetos de solução, você escolhe o que vai no pacote de lançamento. As opções são as seguintes:
- Aplicativo
- Montagem
- Pacote
- Coleção
- Fonte de dados
- Página
- Regra
- Objeto SQL
Para adicionar qualquer um deles, clique no botão + Objeto, selecione o tipo no menu e clique no botão Salvar:
Nota
Quando você adiciona um objeto de aplicativo, o pacote e a fonte de dados do aplicativo são adicionados automaticamente ao pacote de lançamento.
O pacote de lançamento não inclui grupos de instâncias, provedores de segurança de instância ou credenciais de servidor.
-
Clique no botão Avançar.
-
A tela Configurar fontes de dados lista todas as fontes de dados relevantes para a compilação de lançamento. (Se não houver fontes de dados, esta etapa será ignorada.) Para cada fonte de dados listada, marque a coluna Incluir e certifique-se de que ela esteja definida como você deseja para a compilação (Somente modelo lógico, Modelo lógico e tabelas físicas ou Não incluir). As diferentes configurações para cada fonte de dados a serem incluídas são:
-
Somente modelo lógico: Use quando quiser empacotar apenas os dados que foram criados e existem em App Builder em si. Exemplos: dados e objetos de negócios, subconsultas, CRUDs, workflow, pontes. Esta opção é geralmente usada para fontes de dados que você não possui e/ou não são mantidas por meio App Builder (fontes de dados externas, fontes de dados de API, etc.).
-
Modelo Lógico e Tabelas Físicas: Use quando quiser trazer todos os dados existentes em App Builder em si, bem como as tabelas de fontes de dados subjacentes e estruturas de colunas. Aqui, físico se refere a App Builder mantendo ou fazendo atualizações na camada de banco de dados real. Se você mover um modelo físico, isso significa que quaisquer alterações feitas no dev para o banco de dados também serão feitas no banco de dados QA/Prod ao mover o LP. Esta opção é geralmente usada para fontes de dados que você gerencia.
-
Não incluir: Use se você não deseja incluir esta fonte de dados nesta versão.
Importante
Se você tiver alterações no 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 Liberação suporta a importação de Tabelas. Se você importar Tabelas para 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 Avançar.
-
Se você tiver traduções no seu aplicativo, a tela Pacotes de Soluções será exibida. Caso contrário, a tela Notas de Liberação será exibida com informações gerais sobre o pacote de liberação:
-
Nome: O nome do seu aplicativo.
-
Versão: O número da versão do pacote que está sendo criado.
-
Data de lançamento: A data em que você deseja que o lançamento apareça (esta é uma data flexível e pode ser diferente da data de lançamento real).
-
Data de compilação: A data em que você enviou o pacote.
-
Data de publicação: A data em que você lançou o pacote.
-
Descrição do modelo: Uma descrição de texto do que seu aplicativo ou conjunto faz.
-
-
Clique no botão Avançar.
-
Revise as informações na tela Publicar e clique no botão Concluir.
Agora você deve estar de volta à tela Release Template Builder com a coluna Pronto contendo uma marca de seleção verde.
-
Clique no botão Database Changes 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 Release Template Builder. A tela Change Management Requests 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 exigirá que você clique manualmente nela para revisar e aprovar.
Clicar em revisão leva você para a tela Change Management Request. Aqui, o campo Patch Number é preenchido automaticamente com um valor e indica qual iteração esta atualização de pacote reflete. Certifique-se de revisar todas as entradas listadas no painel Changes para garantir que essas informações sejam o que você espera que sejam movidas com o pacote. Nesta tela, você precisa inserir:
-
Número de referência: Pode espelhar o valor do número do patch, ser uma referência de tíquete do JIRA ou AHA ou usar um valor de numeração do cliente.
-
Descrição curta: Forneça uma descrição de 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 Release Template Builder. Agora você verá uma marca de verificação verde aparecer na coluna DB.
-
O Data Config é opcional e usado somente se você estiver movendo Dados Lógicos e Dados Físicos com o pacote. Na tela Data Configuration você alinhará itens de todas as fontes de dados, tabelas para a fonte de dados, juntamente com o Owner Type que foi atribuído, juntamente com a ação correspondente que acontece quando a tabela é movida para esse ambiente. Os diferentes Owner Types são os seguintes:
-
Dados do usuário: Não transferirá nenhum dado. 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 somente no próximo ambiente. Por exemplo: Modelos de E-Email, que é uma tabela na qual você deseja que o usuário personalize as alterações.
-
Dados do desenvolvedor: Trunca a tabela no QA e insere todos os registros do pacote. Isso é normalmente usado sempre que você tem tabelas de pesquisa ou tabelas que fazem parte de uma configuração. Por exemplo: CustomerType, EmployeeType.
-
-
As informações podem ser substituídas manualmente para Tipos de Proprietário e definidas para o pacote específico, ou você pode simplesmente clicar em Confirmar Configuração. Isso marca esse processo como concluído e retorna para a tela Construtor de Modelo de Lançamento. Observe que a metodologia Jitterbit A prática recomendada é sempre definir o valor Opção de Instalação no nível da Tabela, que mapeia para Tipo de Proprietário na tela Construtor de Modelo de Lançamento. Opções de Instalação são Dados do Usuário, Dados de Compartilhamento e Dados do Desenvolvedor. 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 vários membros da equipe.
-
A área SQL Config permite que você escolha o banco de dados e veja se há algum objeto (views ou stored procedures) armazenado no banco de dados na camada SQL nativa. Isso permitirá que você mova views ou stored procedures. Essas informações não serão preenchidas automaticamente na tela Code resultante, e você precisará clicar manualmente no botão Create e adicioná-las. Essa etapa normalmente é usada apenas em situações avançadas e não é uma etapa obrigatória.
-
A etapa Build mostrará a versão para esta versão e permitirá que você adicione notas específicas para esta versão. Ao estruturar suas notas de versão, você deve usar um formato como a captura de tela a seguir. Seguir um processo consistente para nomear suas notas de versão ao longo do tempo é importante, especialmente se seu projeto tiver várias pessoas trabalhando nele. Isso se torna um log em execução das notas de versão do aplicativo.
-
Clique no botão Build Package, que inicia um trabalho em segundo plano que constrói o pacote. Não há nenhuma notificação que acontece para informá-lo quando o pacote é concluído e/ou falha. Para verificar o status do processo, você precisa ir para App Builder IDE, Gerenciar Servidores e Agendamentos e verificar 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 a construção do seu pacote.
-
Clique em Ícone Packages que leva você para a tela Solution Releases, que tem o arquivo LP para download criado para o próximo ambiente. Este é o arquivo que você usará para instalar no próximo ambiente. Nesta tela, baixe o arquivo Package e armazene-o localmente no seu computador.
-
Com o arquivo LP disponível, vá para o seu próximo ambiente onde você irá instalá-lo (QA ou Prod). De lá, vá para Implementar seu aplicativo do 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 Criar e Navegar para localizar o arquivo do pacote e clique em Salvar. Ao salvar, você verá o painel Solução à direita exibir as informações do pacote sobre Nome, Versão, Desenvolvedor, Data de lançamento, Descrição e Notas de lançamento.
-
Clique no botão Instalar após confirmar que este é o pacote que você deseja instalar. Este processo é executado em primeiro plano. Se for bem-sucedido, você receberá uma mensagem de sucesso. Se falhar, vá para Logs > App Server Fast Logs e você verá informações de erro específicas sobre o motivo da falha na instalação.
Cronogramas e pacotes de lançamento
Os agendamentos serão incluídos em um Pacote de Lançamento (ou LP), a menos que sejam removidos manualmente ao criar o Pacote. Por design, os Agendamentos que foram implantados em um ambiente de Produção são "selados" ou impedidos de fazer certas edições nas informações do Agendamento. Isso evita que alguém acidentalmente faça alterações de desenvolvimento em um ambiente abaixo, o que pode levar a vários problemas ao tentar implantar o aplicativo no futuro. Os agendamentos são parte de um aplicativo, portanto, são "selados" nesses ambientes abaixo. Você pode ativar ou desativar os Agendamentos ou ajustar o tempo, mas não pode alterar o tipo de execução de um Agendamento.
Existem alguns cenários em que você pode configurar um Schedule no Dev, mas uma vez em Production o Dev Schedule é desativado. Por exemplo, interagir com uma API. Você pode querer interagir apenas com uma API do ambiente Production, então, uma vez que o Dev esteja concluído, você pode desativar o Schedule no ambiente Development.
Depois que um Schedule for adicionado a um LP, observe que nem todas as alterações de Schedule serão enviadas para Builds futuros de um pacote. Se você adicionar ou remover Eventos associados a um Schedule, essas alterações serão refletidas em um novo Build. Outras alterações em uma definição de Schedule não serão enviadas para Builds futuros.
Para fazer alterações em um Production Schedule que está selado, você pode criar um novo Schedule que será incluído no próximo LP. Esse processo garantirá que o Schedule seja criado corretamente com quaisquer novas configurações refletidas nos ambientes abaixo.