Criar e Configurar Jobs de Build de Produção

Para implantar extensões na instância PROD do Oracle Cloud Application, você pode usar a página Gerenciar Ciclo de Vida de Extensão ou configurar um pipeline de CI/CD. Se quiser usar um pipeline, você precisará configurar alguns jobs de empacotamento e implantação.

  1. Migre as configurações para a instância de produção do Oracle Cloud Application. Consulte Visão Geral do Ciclo de Vida da Configuração e Visão Geral da Migração em Configurando e Estendendo Aplicativos para obter instruções.
  2. Crie um job de compilação que empacote a extensão. Consulte Criar o Job de Build de Pacote de Produção para obter instruções.
  3. Crie um job de build que implante a extensão na instância de produção. Consulte Criar o Job de Build de Implantação de Produção para obter instruções.
  4. (Opcional) Restrinja quem pode ver ou editar os jobs de build de produção ou executar seus builds. Consulte Configurar Definições de Proteção de Job para obter instruções.
  5. Configure os pipelines para executar os jobs de empacotamento e implantação sucessivamente. Consulte Criar e Configurar o Pipeline de Produção para obter instruções.
  6. Execute o pipeline de produção para empacotar a extensão e implantá-la na instância de produção. Consulte Executar Pipelines de Produção para obter instruções.

Antes de Configurar Jobs de Build e Pipelines

Veja algumas coisas que você precisa saber antes de configurar e executar jobs de build e pipelines:

  • Certifique-se de que as instâncias de origem e destino sejam da mesma release, com os mesmos patches padrão e one-off aplicados a ambos os ambientes.
  • Se você tiver configurado o job de empacotamento de desenvolvimento para substituir a versão do aplicativo definida em visual-application.json, obtenha a nova versão. Você configurará o job de empacotamento da produção para usar a mesma versão.
  • O VB Studio pode criar e ativar os jobs de build e o pipeline para você. No editor de Definições da extensão, em Criando e Publicando, selecione a ramificação de produção e clique em Criar Pipeline CI/CD. Em seguida, é possível modificar os jobs de build recém-criados conforme necessário. Por exemplo, no job de implantação, o destino da implantação é sempre o ambiente associado ao espaço de trabalho; portanto, você precisará alterar a instância de destino para sua instância de produção.

Criar o Job de Criação do Pacote de Produção

O job de empacotamento gera um artefato de extensão que está pronto para implantação na instância de produção.

  1. No navegador esquerdo, clique em Builds Builds.
  2. Na guia Jobs, clique em + Criar Job.
  3. Na caixa de diálogo Novo Job, em Nome, informe um nome exclusivo.
  4. Em Descrição, informe a descrição do job.
  5. Em Modelo, selecione o modelo Padrão do Sistema OL7 para o Visual Builder.
  6. Clique em Criar.
  7. Clique em Configurar Configurar.
  8. Clique na guia Git.
  9. Na lista Adicionar Git, selecione Git.
  10. Em Repositório, selecione o repositório Git. Em Ramificação ou Tag, selecione a ramificação de produção.
  11. Clique na guia Etapas.
  12. Em Adicionar Etapa, selecione Extensão do Aplicativo e, em seguida, Pacote.
  13. Por padrão, a etapa de empacotamento minimiza o código-fonte do aplicativo antes de executar a compilação. Se você não quiser diminuir os arquivos de origem, desmarque a caixa de seleção Otimizar extensão.

    Minificação é um processo para remover os caracteres desnecessários (como espaços em branco, novas linhas e comentários) do código-fonte e reduzir o tamanho dos arquivos, fazendo com que a transferência de arquivos consuma menos largura de banda e armazenamento.

    Observação

    Quando você desmarca a caixa de seleção Otimizar extensão, esse aviso é exibido: Otimização não selecionada. O empacotamento sem otimização pode causar problemas de desempenho. Portanto, evite fazer isso, a menos que esteja depurando ou diagnosticando e solucionando problemas.
  14. (Opcional) Se você quiser alterar o nome do arquivo de artefato, em Artefato de Build, informe o novo nome. A melhor prática é manter o padrão, extension.vx, mas você pode alterá-lo.
    Se você alterá-lo, também deverá usar o novo nome no campo Arquivos a serem arquivados (etapa 18), bem como no campo Artefato de Build do job de implantação. Consulte Criar o Job de Build de Implantação de Produção.
  15. (Opcional) Se você tiver configurado o job de empacotamento de desenvolvimento para substituir a versão padrão da extensão definida no arquivo visual-application.json, especifique a mesma versão em Versão da Extensão.
  16. Clique na guia Após a Criação na janela Configuração do Job.
  17. Em Adicionar Após a Ação de Build, selecione Arquivador de Artefato.
  18. Em Arquivos a serem arquivados, informe o nome do artefato de build.

    Você pode usar caracteres curinga. Por exemplo, *.vx. Certifique-se de incluir o caminho do artefato de build da Extensão do Aplicativo.

    Se você tiver informado um valor no campo Diretório de Destino em Copiar Artefatos para o job de implantação, ele será considerado um subdiretório do espaço de trabalho e deverá fazer parte do caminho do artefato no campo Criar Artefato.

  19. Se quiser descartar os artefatos antigos do build, clique em Definições o ícone de engrenagem. Na guia Geral, marque a caixa de seleção Descartar Builds Antigos e especifique as opções de descarte.
  20. Clique em Salvar.

Criar o Job de Build de Implantação de Produção

O job de implantação implanta o artefato da extensão que foi gerado no job de empacotamento na instância de produção do Aplicativo Oracle Cloud. Antes de criar o job, certifique-se de ter credenciais que o VB Studio possa usar para acessar a instância PROD do Aplicativo Oracle Cloud.

  1. No navegador esquerdo, clique em Builds Builds.
  2. Na guia Jobs, clique em + Criar Job.
  3. Na caixa de diálogo Novo Job, em Nome, informe um nome exclusivo.
  4. Em Descrição, informe a descrição do job.
  5. Em Modelo, selecione o modelo Padrão do Sistema OL7 para o Visual Builder.
  6. Clique em Criar.
  7. Clique em Configurar Configurar.
  8. Clique na guia Antes da Criação.
  9. Em Adicionar Antes da Ação de Build, selecione Copiar Artefatos.
  10. Em Do Job, selecione o job de empacotamento que gerou o artefato da extensão.
  11. Em Qual Build, selecione um dos seguintes:
    • Último build bem-sucedido (padrão)
    • Build mais recente a ser mantido para sempre
    • Build de upstream nesta instância de pipeline
    • Especificado por link permanente
    • Build específico
    • Especificado por parâmetro de build
    Dependendo do que você selecionar, você pode ser solicitado a selecionar qual permalink, compilação ou parâmetro de compilação deseja usar.
  12. Deixe outros campos com seus valores padrão ou vazios.
  13. Clique na guia Etapas.
  14. Em Adicionar Etapa, selecione Extensão do Aplicativo e, em seguida, Implantar.

    Esta imagem mostra a página do job de build de Implantação que foi parcialmente preenchida.
    A descrição da ilustração oracle-deploy-build-step.png segue
    Descrição da ilustração oracle-deploy-build-step.png

  15. Em Instância de Destino, selecione o ambiente com a instância de produção do Aplicativo Oracle Cloud.
  16. Na seção Autorização, especifique o tipo de autorização para executar esta etapa de criação. Com a opção Usar OAuth selecionada por padrão, você verá a mensagem Authorization is required, indicando que essa etapa de build precisa de uma autorização única para tratar solicitações OAuth para a instância do Oracle Cloud Applications do seu ambiente. Clique em Autorizar e informe credenciais para acessar sua instância do Oracle Cloud Applications. Você também pode executar o job manualmente e informar as credenciais quando solicitado.

    De qualquer forma, é recomendável que você autorize sua conexão OAuth durante a configuração inicial. Se você ignorar esta etapa, não poderá publicar suas alterações no Designer e precisará concluir a autorização necessária antes de tentar implantar as alterações.

    Uma vez autorizada, a mensagem Authorization has been provided é exibida.

    Observação

    OAuth é o tipo de autorização recomendado. Só use a autenticação Básica se tiver problemas com a configuração de uma conexão OAuth. Para usar a autenticação Básica, selecione Usar Básico e informe as credenciais de um usuário que pode acessar a instância do Oracle Cloud Applications em Nome do Usuário e Senha. Essas credenciais devem ser de um usuário local, não de uma identidade federada, e não devem exigir autenticação multifator.

    Os tokens OAuth (acesso e atualização) são reiniciados durante o uso regular. Um token de atualização é usado para obter um token de acesso sempre que um usuário acessa a instância de destino. Esse token de atualização geralmente é válido por sete dias. (O tempo de expiração do token é definido no aplicativo de recursos do IDCS e pode ser diferente com base em seus requisitos de segurança.) Se o usuário fizer a autenticação com a instância de destino dentro do período de sete dias, o token de atualização ativo gerará um novo token de acesso e um novo token de atualização. Este ciclo continua indefinidamente enquanto o token de atualização permanecer válido. Se o token de atualização expirar durante longos períodos de inatividade (por exemplo, quando você estiver de férias), clique em Renovar Autorização (ou execute o job manualmente, para que você seja solicitado a autorizar tokens OAuth expirados).

    O campo Artefato de Build deve mostrar o mesmo nome de artefato que foi usado na etapa de build de empacotamento. Confirme esse valor, especialmente se o job de empacotamento tiver usado um nome de artefato diferente do padrão, extension.vx.
  17. Clique em Salvar.
Observação

Se você desenvolver uma extensão em, digamos, 24D em seu ambiente de Teste e quiser implantar a extensão em seu ambiente de Produção 24C, terá que aguardar até que sua instância de Produção tenha sido submetida a upgrade para 24D para que possa ser implantada com sucesso. Na maioria dos casos, não deve haver mais de duas semanas de intervalo entre as atualizações de pod.

Configurar Definições de Proteção de Job

Para restringir o acesso, o proprietário do projeto pode marcar um job como privado. Os usuários que não têm acesso podem ver o job de build na página Visão Geral de Jobs, mas não podem ver a página Detalhes do Job nem exibir os detalhes do build; nem podem ver ou editar a configuração do job ou excluir/ativar/desativar o job de build. Além disso, o proprietário do projeto pode usar um padrão glob definido em uma regra para proteger qualquer job cujo nome corresponda ao padrão especificado.

Observação

Antes de aplicar qualquer proteção a um job, você deve considerar o seguinte:
  • Uma regra de proteção definida com um padrão glob não substituirá uma proteção de job definida usando um nome (sem padrão glob ou regra).
  • Uma proteção aplicada a um único job substituirá uma proteção aplicada usando uma regra (definida por um padrão glob).
  • Quando duas regras são combinadas, a proteção é determinada pela regra mais restritiva. É necessário examinar os eventos no feed Atividades e examinar as notificações, que fornecem as informações que explicam as restrições quando uma regra substitui outra.
  • Não será criado um job se o usuário que estiver criando o job não conseguir acessar seu próprio job. O mesmo princípio é verdadeiro para renomear jobs.
  1. No navegador esquerdo, clique em Project Administration Administração do projeto.
  2. Selecione o mosaico Builds.
  3. Selecione a guia Proteção de Cargo.

    A página Proteção de Job é exibida.


    Descrição da ilustração job-protection-page-initial.png segue
    Descrição da ilustração job-proteection-page-initial.png

  4. No painel Localizar regras por, localizado acima da lista de tarefas/regras, selecione um destes botões de opção:
    • Selecione Nome do job para escolher um job na lista.

      Se o seu projeto tem muitos trabalhos, você pode ter dificuldade em encontrar o trabalho específico que deseja proteger. Use a barra Ícone Pesquisar do Job de filtro para localizar rapidamente o job ao qual você deseja adicionar as definições restritas.

      Clique com o botão direito do mouse na lista de jobs para exibir opções de classificação adicionais. Clique em Classificar por nome de job ou Classificar por job privado para classificar a lista adequadamente. Clique novamente na opção de classificação para alternar entre a ordem crescente e decrescente.


      Opções de classificação da página de proteção do job

      Se um job tiver um ícone de bloqueio Ícone de bloqueio, ele já será protegido. As restrições de um job protegido ainda podem ser modificadas, removidas ou a lista de usuários e grupos autorizados ainda pode ser alterada.

      A caixa de diálogo Proteção de Cargo é exibida.


      Descrição da ilustração job-protection-open.png segue
      Descrição da ilustração job-proteection-open.png

      Quando um job não é protegido diretamente, mas é protegido por uma regra, uma mensagem informativa como a seguinte mostrará as regras, <ExampleRegex05> nesse caso, que protegem o job específico:
      This job is protected by the following glob pattern rules matching this job name: <ExampleRegex05>
    • Selecione Padrão de glob para especificar uma string correspondente ao nome do job.

      Isso é o que você verá se nenhuma regra foi definida ainda.


      Descrição da ilustração job-protection-page-glob-pattern-selected.png a seguir
      Descrição da ilustração job-proteection-page-glob-pattern-selected.png

      A sintaxe glob pode ser usada para especificar o comportamento de correspondência de padrões. Esses caracteres curinga podem ser usados em padrões glob: *, **, ?, [], {} e \.

      Selecione uma regra de proteção existente na lista ou clique em + Regra para exibir a caixa de diálogo Nova Regra de Proteção e criar uma nova.

      A caixa de diálogo Regra de proteção é exibida.
      Segue a descrição da protection-rule-dialog-populated.png
      Descrição da ilustração protection-rule-dialog-populated.png

      Aqui, informamos um nome (Regra de Teste) e um padrão glob (test*) e estamos prestes a pressionar Criar para criar uma nova regra de proteção de job.

  5. Marque a caixa PRIVATE.
    Isso é o que você vê depois de selecionar a opção Privado para um job.


    Descrição da ilustração job-protection-private.png segue
    Descrição da ilustração job-proteection-private.png

    Com apenas essa opção selecionada, somente usuários e grupos autorizados poderão exibir a página Detalhes do Job, editar o job ou executá-lo manualmente. Se o job for acionado em um pipeline por um usuário ou grupo sem autorização ou se ele for acionado por SCM ou um temporizador, ele não será iniciado.

    Isso é o que você vê depois de selecionar a opção Privado para uma regra de proteção.


    Descrição da ilustração job-protection-rule-private.png a seguir
    Descrição da ilustração job-proteection-rule-private.png

  6. Clique no campo Usuários/Grupos Autorizados para exibir uma caixa de diálogo que lista os Grupos e os Usuários do projeto que você pode selecionar.

    Em Usuários, você pode ver uma lista nivelada de todos os usuários que são membros do(s) grupo(s), bem como aqueles que foram adicionados individualmente. Por exemplo, os membros do grupo de desenvolvimento (Clara Coder, Don Developer e Tina Testsuite) aparecem na lista Usuários, junto com Alex Admin, que foi adicionado individualmente. Na lista, selecione um ou mais grupos e/ou usuários. Não se esqueça de adicionar a si mesmo.


    Descrição da ilustração autorizado-groups-users.png a seguir
    Descrição da ilustraçãoauthorized-groups-users.png

    Isso é o que você veria para o job myProtectedJob depois de selecionar Alex Admin como um usuário autorizado.


    Descrição da ilustração job-protection-private-authorized-user.png vem a seguir
    Descrição da ilustração job-protection-private-autorizada-user.png

    Isso é o que você veria para a regra de proteção Test Rule depois de selecionar Alex Admin como um usuário autorizado.


    Descrição da ilustração job-protection-rule-autorizada-user.png a seguir
    Descrição da ilustração job-protection-rule-autorizada-user.png

  7. Marque as caixas de seleção para permitir que os membros do projeto iniciem manualmente jobs privados e/ou permitam que commits e triggers iniciem automaticamente jobs privados:
    • Marque a caixa de seleção Permitir que qualquer membro do projeto inicie manualmente este job privado para permitir que qualquer membro do projeto, e não apenas usuários autorizados, inicie o job manualmente.

      Isso você verá depois de marcar a caixa de seleção Permitir que qualquer membro do projeto inicie manualmente este job privado para o job myProtectedJob.


      Descrição da job-protection-private-both-checkboxes-selected.png a seguir
      Descrição da ilustração job-proteection-private-both-checkboxes-selected.png

      Observe que quando você marca a primeira caixa de seleção, o VB Studio seleciona automaticamente a segunda caixa de seleção, o que permite que commits e triggers iniciem o job privado e o eliminem. Com essa definição, somente usuários e grupos autorizados podem exibir a página Detalhes do Job ou editar o job, mas qualquer membro do projeto pode iniciar e executar o job. Além disso, os triggers ou commits do SCM também iniciarão e executarão automaticamente o job.

      Isso você verá depois de marcar a caixa de seleção Permitir que qualquer membro do projeto inicie manualmente este job privado para a regra de proteção Test Rule.


      Descrição da ilustração job-protection-page-both-check-boxes.png a seguir
      Descrição da ilustração job-proteection-page-both-check-boxes.png

    • Marque apenas a caixa de seleção Permitir que commits e triggers iniciem este job privado se quiser que os commits e triggers do SCM possam executar automaticamente este job.


      Descrição da ilustração job-protection-private-allow-commits-triggers.png a seguir
      Descrição da ilustração job-protection-private-allow-commits-triggers.png

      Com apenas esta caixa de seleção marcada, os triggers periódicos executarão qualquer job ou pipeline, incluindo jobs privados definidos para permitir que commits e triggers iniciem o job privado. No entanto, se um pipeline incluir um job privado com esta opção selecionada e um usuário não autorizado tentar executar o pipeline manualmente, o job privado não será executado, mas os acionadores periódicos e os commits do SCM serão.

      Deixe a caixa de seleção desmarcada se não quiser que o job seja iniciado quando for acionado por um commit ou timer do SCM.
      Observação

      Melhores Práticas:

      Se você usar a caixa de seleção para permitir que o build protegido seja acionado por um commit do SCM, será necessário proteger a ramificação à qual o job de build está vinculado. Se você não fizer isso, qualquer pessoa pode acionar o build protegido fazendo um commit para acioná-lo.

      Isso é o que você veria se tivesse selecionado Allow commits and triggers to start any job matching this glob pattern for the Test Rule.


      Descrição da ilustração job-protection-page-allow-commits-triggers.png a seguir
      Descrição da ilustração job-proteection-page-allow-commits-triggers.png

  8. Clique em Salvar.

    O fluxo de atividades exibe todas as alterações no status de proteção de um job, como alterar a proteção do job de público para privado, ou de privado para público, ou alterar um job privado para permitir commits e triggers.

Você pode ver se um job é privado de vários lugares na interface do usuário do VB Studio.

  • Na lista de jobs encontrada na guia Proteção de Job, no mosaico Builds da página Administração de Projetos, à direita do nome de cada job protegido.

  • Na coluna Privado da página Builds, guia Jobs.

  • Nas jobs mostradas na guia Pipelines na página Builds.

Um job privado é indicado por um ícone Bloquear Bloquear. Um job privado que você pode executar e editar é indicado com um ícone Desbloquear Desbloquear. Um job privado que você pode executar, mas não editar, é indicado com um ícone Bloquear-editar.

Um usuário não autorizado não pode executar um job de build privado manualmente, por meio de um pipeline ou usando um acionador SCM/periódico.