Aqui estão algumas coisas que você precisa saber antes de configurar e executar jobs e pipelines de build:

• 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 job de empacotamento gera um artefato de extensão pronto para implantação na instância de produção.

1. No navegador esquerdo, clique em Builds .
2. Na guia Jobs, clique em + Criar Job.
3. Na caixa de diálogo Novo Job, em Nome, digite um nome exclusivo.
4. Em Descrição, digite 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 .
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 tab Etapas.
12. Em Adicionar Etapa, selecione Extensão do Aplicativo e, em seguida, selecione Pacote.
13. Por padrão, a etapa de empacotamento reduz o código-fonte do aplicativo antes de executar o build. Se você não quiser minificar 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, esta advertência é exibida: Otimização não selecionada. O empacotamento sem otimização pode causar problemas de desempenho. Portanto, não faça isso, a menos que esteja depurando ou diagnosticando problemas.
14. (Opcional) Se você quiser alterar o nome do arquivo de artefato, em Criar Artefato, informe o novo nome. A melhor prática é manter o padrão, extension.vx, mas você pode alterá-lo.
    Se alterá-lo, você também deverá usar o novo nome no campo Arquivos para arquivamento (etapa 18), bem como no campo Criar Artefato 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 o Build na janela Configuração do Job.
17. Em Adicionar Após a Ação de Build, selecione Arquivador de Artefatos.
18. Em Arquivos a serem arquivados, informe o nome do artefato de build.

    Você pode usar caracteres selvagens. 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 . Na guia Geral, marque a caixa de seleção Descartar Builds Antigos e especifique as opções de descarte.
20. Clique em Salvar.

O job de implantação implanta o artefato da extensão que foi gerado no job de empacotamento para a instância de produção do Oracle Cloud Application. 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 .
2. Na guia Jobs, clique em + Criar Job.
3. Na caixa de diálogo Novo Job, em Nome, digite um nome exclusivo.
4. Em Descrição, digite 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 .
8. Clique na guia Antes do Build.
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 uma das seguintes opções:
    • Último build bem-sucedido (padrão)
    • Build mais recente a manter 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, poderá ser solicitado que você selecione qual parâmetro de permalink, build ou build deseja usar.
12. Deixe outros campos com seus valores padrão ou vazios.
13. Clique na tab Etapas.
14. Em Adicionar Etapa, selecione Extensão do Aplicativo e, em seguida, selecione Implantar.

    Esta imagem mostra a página Implantar job de build que foi parcialmente preenchida.
    
    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 autorizar 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. Use a autenticação Básica somente se tiver problemas ao configurar 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 as de um usuário local, não 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 se autenticar 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. Esse ciclo continua indefinidamente, desde que o token de atualização permaneça 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 quaisquer tokens OAuth expirados).

    O campo Criar Artefato deve mostrar o mesmo nome de artefato usado na etapa de criação 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.

Para restringir o acesso, o proprietário do projeto pode marcar um trabalho como privado. Os usuários que não têm acesso podem ver o job de build na página Visão Geral dos 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.

1. No navegador esquerdo, clique em Administração de Projetos .
2. Selecione o mosaico Compilações.
3. Selecione a guia Proteção do Job.

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

   
   
   Descrição da ilustração job-protection-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 da lista.

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

     Se um job na lista de jobs à esquerda tiver um ícone de bloqueio ao lado dele, ele já estará 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 Job é exibida.

     
     
     Descrição da ilustração job-protection-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 Glob para especificar uma string correspondente ao nome do job.

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

     
     
     Descrição da ilustração job-protection-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.
     
     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 de seleção PRIVADO.
   Isso é o que você vê depois de selecionar a opção Privado para um job.

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

   Com apenas essa opção selecionada, somente usuários e grupos autorizados poderão exibir a página Detalhes do Job, editá-lo ou executá-lo manualmente. Se o job for disparado em um pipeline por um usuário ou grupo não autorizado, ou se ele for disparado por SCM ou um timer, 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
   

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 desenvolvedores (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 autorizada-grupos-e-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
   

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

   
   
   Descrição da ilustração job-protection-rule-authorized-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, não apenas usuários autorizados, inicie manualmente o job.

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

     
     
     Descrição da ilustração job-protection-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, que permite que commits e triggers iniciem o job privado e o esmaece. Com essa configuraçã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, commits ou triggers do SCM também iniciarão e executarão automaticamente o job.

     O que você verá depois de marcar a caixa de seleção Permitir que qualquer membro do projeto inicie manualmente esse job privado para a regra de proteção Regra de Teste.

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

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

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

     Com apenas essa 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 essa opção selecionada e um usuário não autorizado tentar executar o pipeline manualmente, o job privado não será executado, mas triggers periódicos e commits do SCM.

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

     Observação
     
     

     Melhor Prática:

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

     Isso é o que você veria se tivesse selecionado Permitir commits e triggers para iniciar qualquer job que corresponda a esse padrão glob para a Regra de Teste.

     
     
     Descrição da ilustração job-protection-page-allow-commits-and-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.