UiPath® Automation Ops™ - Pipelines

Automation Ops™ - Pipelines fornece uma maneira fácil de configurar um sistema de integração/entrega contínua para gerenciar o código de seus projetos de automação em repositórios externos, como o Github ou o Azure DevOps.

Os pipelines contêm um conjunto de etapas que dependem de processos de automação usados para alterar o código em seu ambiente. Esses processos, também chamados de Processos de Pipeline, usam o pacote de atividades de Pipeline . Para um usuário verificar esses processos de pipeline, deve ter acesso à pasta do Orchestrator que os contém.

Quando um pipeline é disparado, é iniciado um trabalho que executa o processo de pipeline associado usando um Unattended Robot.

Pré-requisitos

• Versões do robô:
  • 2021.10 e 2022.4: O.NET Desktop Runtime 6.0.* deve ser instalado manualmente na máquina do robô.
  • 2022.8 e mais recente: .NET Desktop Runtime é instalado automaticamente com o robô.
• Particularidades do processo:
  • O processo de pipeline deve ser configurado para ser executado como um processo em segundo plano. Isso é feito a partir do menu de configurações do projeto no Studio. Saiba mais sobre processos em segundo plano.
  • Ao publicar o processo de pipeline do Studio para o Orchestrator, certifique-se de também selecionar Incluir Origens na seção Opções de Publicação . Leia mais sobre como publicar projetos de automação.

Configuração

Os Automation Ops™- Os pipelines funcionam executando processos de pipeline usando robôs não assistidos, o que significa que é necessária uma configuração específica no Orchestrator antes de usá-los. Essa configuração é chamada de ambiente de runtime de pipelines.

A configuração básica do Orchestrator tem uma pasta dedicada que contém os processos de pipeline e uma conta de robô, além de uma máquina ou modelo de máquina para executar os trabalhos de pipeline.

Importante:

A conta de robô criada durante a configuração rápida é essencial. Todos os pipelines (trabalhos do Orchestrator) são executados em seu nome. Excluir a conta do robô causa uma configuração de runtime de pipeline inválida e a necessidade de executar novamente a configuração rápida. Excluir a pasta de pipelines dedicados no Orchestrator interrompe todos os pipelines associados a ela.

Configuração inicial

Ao configurar o Automation Ops™ - Pipelines pela primeira vez, uma janela de configuração rápida é exibida, permitindo que você escolha o Tenant e o tipo de máquina com a qual deseja executar os pipelines futuros. Você pode escolher entre usar uma máquina existente do seu ambiente ou criar automaticamente uma nova máquina sem servidor chamada "Robot de Pipelines".

Observação:

Se você optar por criar uma nova máquina sem servidor, certifique-se de que haja Robot Units suficientes disponíveis em seu tenant.

Como parte da experiência de configuração rápida, uma nova pasta chamada "Pipelines" e as seguintes funções são criadas automaticamente:

• Função do tenant de pipelines
• Função de pasta de pipelines

O robô de pipelines recebe as seguintes funções atribuídas automaticamente:

• Tenant: função de tenant de pipelines, Permitir ser Automation User, Permitir ser Automation Publisher
• Pasta de pipelines: função de pasta de pipelines, Automation User, Automation Publisher

Observação:

Verifique se a conta do Robot criada para pipelines também está atribuída à pasta de destino do Orchestrator. Isso é necessário porque os pipelines operam nessa conta. Para obter detalhes, consulte Configurando acesso para contas.

A atividade Run Tests executa os testes na pasta fornecida do Orchestrator. A conta do robô do Pipelines publica o pacote na pasta respectiva, mas os testes podem ser executados por qualquer conta do robô nessa pasta que se qualifique para a execução do teste, não apenas pela conta do robô do Pipelines.

Além disso, os processos de pipelines pré-definidos estão disponíveis por padrão, conforme apresentado na tabela a seguir:

Build.and.publish	Clonar -> Analisar -> Compilar -> Publicar
Copy.package.between.environments	Baixar pacote -> Publicar pacote
Update.process.from.code	Clonar -> Analisar -> Compilar -> Publicar pacote -> Atualizar processo
Update.with.tests	Clonar -> Analisar -> Executar Testes -> Compilar -> Publicar Pacote -> Atualizar Processo
Build.and.promote.with.approval	Clonar -> Analisar -> Executar Testes -> Compilar -> Publicar Pacote -> Atualizar Processo -> Aprovar -> Baixar Pacote -> Carregar Pacote -> Atualizar Processo

Esses processos de pipelines padrão vêm com seu próprio conjunto de argumentos, por exemplo, o Build.and.promote.with.approval tem os seguintes argumentos:

• PularTestes - Permite que você escolha se os casos de teste são executados ou não durante o pipeline.
• PastaDeTestes - A pasta do Orchestrator na qual os testes são executados.
• AnalisarPolítica - a política de governança que contém as regras do analisador de fluxo de trabalho usadas no processo de pipeline. Se deixado em branco, a análise do projeto é ignorada.
• PularValidação - Permite que você ignore a validação antes de criar o pacote. Esse valor fica desabilitado por padrão.
• Aprovador - O endereço de email do aprovador da tarefa criada no Action Center.
• PrimeiroUrlDoOrchestrator - O URL para o Orchestrator onde o pacote criado é publicado.
• FirstOrchestratorFolder - A pasta do Orchestrator na qual o pacote criado é publicado.
• SegundoUrlDoOrchestrator - O URL para o Orchestrator no qual o pacote criado é publicado após a aprovação.
• SegundaPastaDoOrchestrator - A pasta do Orchestrator na qual o pacote criado é publicado após a aprovação.
• TerSamePackageFeed - Este campo é definido como "False" por padrão. Defina como "Verdadeiro" se o primeiro e o segundo ambientes estiverem usando o mesmo feed de pacote/biblioteca.
• NomeDoProcesso — o nome do processo a ser atualizado. Usado apenas se o projeto for um processo.

Você também pode começar a trabalhar com pipelines usando os modelos disponíveis no UiPath Studio e Studio Web ( aba Modelos ).

Você pode usar os seguintes modelos:

• Build and promote with approval pipeline:

  • Uso: gerenciamento do projeto de automação do início à aprovação.
  • Etapas: Clonar, Analisar, Executar Teste, Criar, Publicar Pacote, Atualizar Processo, Aprovar, Baixar Pacote, Carregar Pacote e Atualizar Pacote.

• Update process from a code line:

  • Uso: destaca um procedimento simplificado para atualizações e modificações em processos em andamento.
  • Etapas: Clonar, Analisar, Criar, Publicar Pacote e Atualizar Processo.

Importante:

Os Cloud Serverless Robots criados na configuração inicial são de tamanho Padrão . Ao usar a atividade RunTests, se ela envolver uma pasta do Orchestrator com robôs Cloud Serverless, certifique-se de que os robôs sejam de tamanho padrão.

Ao usar a atividade Build, valide os requisitos de compatibilidade entre os projetos de automação que você está construindo e a máquina que está executando o processo.

Por exemplo, um projeto criado usando a compatibilidadeWindows-Legacy or Windows não pode ser criado em um Cloud Serverless Robot. Em vez disso, você deve usar uma máquina baseada em Windows .

Ao executar um pipeline que gera e publica um processo usando conexões do Integration Service, certifique-se de que todas as pastas do projeto necessárias estejam confirmadas no seu provedor de controle de origem. Por exemplo, é necessário ao inicializar o git a partir do Studio, para confirmar todas as pastas do projeto associadas, como .settings, .project, .tmh.

Criação do primeiro pipeline

Após a configuração do Orchestrator ser concluída, você deve configurar a integração inicial entre o Automation Ops™-Pipelines, o repositório do GitHub que contém seu código e o ambiente de runtime dos pipelines do Orchestrator. Ao fazer essa integração, você também cria o primeiro pipeline.

Siga estas etapas:

1. No Automation Cloud™, navegue até Automation Ops™ > Pipelines na barra de navegação do lado esquerdo.

2. Selecione Novo pipeline. Se você tiver o repositório externo conectado ao Controle de origem, então ele será conectado automaticamente.

   Observação:

   Apenas uma organização da UiPath® Automation Cloud™ pode ser conectada a uma organização do GitHub ao mesmo tempo.

3. Na guia Local , selecione a organização do repositório externo, repositório, ramificação e um projeto de automação (opcional). Selecione Avançar.

   

4. Na guia Definição do pipeline , selecione o processo do pipeline. Se seu processo de pipeline contiver argumentos, você pode adicionar seus valores.
   

5. Na aba Salvar e executar , configure o seguinte:

   • Nome do projeto - Insira um nome para o projeto de pipeline. Por padrão, o nome é composto pelo nome do repositório e pelo nome do projeto de automação do pipeline.
   • Descrição — opcionalmente, adicione uma descrição.
   • Executar esse pipeline — selecione como você deseja que o pipeline seja executado:
     • For each commit - A automação do pipeline é disparada toda vez que há uma alteração no código no repositório para o projeto selecionado.
     • Executarei manualmente – A automação do pipeline é acionada manualmente.
       Observação:

       Em pipelines acionados manualmente, a confirmação usada quando um trabalho é iniciado é a confirmação mais recente na pasta do arquivo project.json selecionado. Não é a confirmação mais recente em todo o repositório, se nenhum arquivo nessa pasta tiver sido alterado nessa confirmação.

6. Selecione Salvar para salvar o pipeline ou Salvar e executar para salvar e executar o pipeline.

Importante:

Se nenhum processo específico do repositório for escolhido na etapa 1 (nenhum projeto de automação selecionado) e o pipeline estiver definido para ser acionado por uma confirmação, o pipeline será acionado por qualquer confirmação no repositório.

O argumento ProjectPath é preenchido com o valor selecionado no campo Automation project (optional) na Etapa Local da configuração do pipeline. Se o campo for deixado em branco, o argumento do processo ProjectPath permanecerá vazio. Este cenário pode ser usado para repositórios que possuem apenas um projeto de automação.

Execução manual de um pipeline

1. No Automation Cloud™ , navegue até o Automation Ops™ na barra de navegação do lado esquerdo.
2. Selecione Pipelines. Os pipelines disponíveis são exibidos.
3. Selecione um pipeline e, em seguida, selecione Iniciar novo trabalho. Isso aciona o pipeline para ser executado e você pode observar o progresso de cada etapa em tempo real.

Você também pode editar o pipeline selecionando Configurações do pipeline. Isso exibirá o resumo do pipeline, a partir do qual é possível:

• Editar pipeline — selecione para fazer atualizações no pipeline. Você só pode atualizar o nome do pipeline, a descrição, o tipo de gatilho e os argumentos personalizados do pipeline. A localização e a definição do pipeline não podem ser alteradas.
• Excluir pipeline - selecione para excluir o pipeline (todas as informações relacionadas ao pipeline serão excluídas).

Processos de pipeline pré-definidos

A tabela a seguir descreve os processos de pipelines predefinidos disponíveis por padrão:

Build.and.publish	Clonar -> Analisar -> Compilar -> Publicar
Copy.package.between.environments	Baixar pacote -> Publicar pacote
Update.process.from.code	Clonar -> Analisar -> Compilar -> Publicar pacote -> Atualizar processo
Update.with.tests	Clonar -> Analisar -> Executar Testes -> Compilar -> Publicar Pacote -> Atualizar Processo
Build.and.promote.with.approval	Clonar -> Analisar -> Executar Testes -> Compilar -> Publicar Pacote -> Atualizar Processo -> Aprovar -> Baixar Pacote -> Carregar Pacote -> Atualizar Processo

As versões mais recentes dos modelos de pipeline predefinidos estão disponíveis no Marketplace.

Esses processos de pipelines padrão vêm com o seguinte conjunto de argumentos:

• Processo de criação.e.promoção.com.aprovação :
  • NomeDoProcesso — o nome do processo a ser atualizado. Usado apenas se o projeto for um processo.
  • Aprovador - O endereço de email do aprovador da tarefa criada no Action Center.
  • PularTestes - Permite que você escolha se os casos de teste são executados ou não durante o pipeline.
  • AnalisarPolítica - a política de governança que contém as regras do analisador de fluxo de trabalho usadas no processo de pipeline. Se deixado em branco, a análise do projeto é ignorada.
  • PularValidação - Permite que você ignore a validação antes de criar o pacote. Esse valor fica desabilitado por padrão.
  • FirstOrchestratorFolder - A pasta do Orchestrator na qual o pacote criado é publicado.
  • PrimeiroUrlDoOrchestrator - O URL para o Orchestrator onde o pacote criado é publicado.
  • SegundaPastaDoOrchestrator - A pasta do Orchestrator na qual o pacote criado é publicado após a aprovação.
  • SegundoUrlDoOrchestrator - O URL para o Orchestrator no qual o pacote criado é publicado após a aprovação.
  • PastaDeTestes - A pasta do Orchestrator na qual os testes são executados.
  • TerSamePackageFeed - Este campo é definido como "False" por padrão. Defina como "Verdadeiro" se o primeiro e o segundo ambientes estiverem usando o mesmo feed de pacote/biblioteca.
• Build.and.publish
  • AnalisarPolítica - a política de governança que contém as regras do analisador de fluxo de trabalho usadas no processo de pipeline. Se deixado em branco, a análise do projeto é ignorada.
  • PularValidação - Permite que você ignore a validação antes de criar o pacote. Esse valor fica desabilitado por padrão.
  • UrlDoOrchestrator - O URL para o Orchestrator em que o pacote criado é publicado.
  • PastaDoOrchestrator - A pasta do Orchestrator na qual o pacote criado é publicado.
• Copy.package.between.environments
  • NomeDoPacote — o nome do pacote a ser copiado.
  • ÉLibrária - Define se o pacote é uma biblioteca ou não.
  • VersãoDoPacote — a versão do pacote a ser copiada.
  • PastaDoOrchestratorDeOrigem - A pasta do Orchestrator de onde o pacote é copiado.
  • UrlDoOrchestratorDeOrigem - O URL para o Orchestrator de onde o pacote é copiado.
  • UrlDoOrchestratorDeDestino - O URL para o Orchestrator para o qual o pacote é copiado.
  • PastaDoOrchestratorDeDestino - A pasta do Orchestrator para a qual o pacote é copiado.
• Update.process.from.code
  • NomeDoProcesso — o nome do processo a ser atualizado. Usado apenas se o projeto for um processo.
  • AnalisarPolítica - a política de governança que contém as regras do analisador de fluxo de trabalho usadas no processo de pipeline. Se deixado em branco, a análise do projeto é ignorada.
  • PularValidação - Permite que você ignore a validação antes de criar o pacote. Esse valor fica desabilitado por padrão.
  • UrlDoOrchestrator - O URL para o Orchestrator onde o pacote a ser atualizado é encontrado.
  • Pasta do Orchestrator - A pasta do Orchestrator onde o pacote a ser atualizado é encontrado.
• Update.with.tests
  • NomeDoProcesso — o nome do processo a ser atualizado. Usado apenas se o projeto for um processo.
  • AnalisarPolítica - a política de governança que contém as regras do analisador de fluxo de trabalho usadas no processo de pipeline. Se deixado em branco, a análise do projeto é ignorada.
  • PularTestes - Permite ignorar testes antes de criar o pacote. Esse valor fica desabilitado por padrão.
  • UrlDoOrchestrator - O URL para o Orchestrator onde o pacote a ser atualizado é encontrado.
  • Pasta do Orchestrator - A pasta do Orchestrator onde o pacote a ser atualizado é encontrado.
  • PastaDeTestesDoOrchestrator - A pasta do Orchestrator na qual os testes usados no pipeline são encontrados.

Observação:

Há um requisito de compatibilidade entre os projetos de automação que você pretende criar e a máquina que executa o processo de pipeline.

O mapeamento correto é:

• Projeto Windows-Legado → Sistema operacional de compilação: somente Windows
• Projeto do Windows→ Compilar sistema operacional: somente Windows
• Projeto multiplataforma→ Sistema operacional: Windows ou Linux

Argumentos padrão do processo de pipeline

O Automation Ops™ fornece um conjunto de argumentos padrão para o processo Pipeline, apresentado na tabela a seguir:

Name	Direction	Tipo de argumento	Description
NúmeroDaCompilação	Em	String	Um número exclusivo para cada execução de trabalho do pipeline.
URL de repositório	Em	String	URL do repositório. Normalmente usado pela atividade Clone.
Confirmar SHA	Em	String	Identificador de confirmação.
Caminho do projeto	Em	String	O caminho para o arquivo project.json. Útil para a atividade Build.
Nome de Usuário do Remetente	Em	String	O nome de usuário da pessoa que dispara a confirmação.
RepositoryType	Em	String	O tipo do repositório (como git).
RepositoryBranch	Em	String	A ramificação de repositório usada.

Visualização de logs de pipelines

Os logs são gerados para cada execução do pipeline. Você pode visualizar os logs no Automation Ops™ e, como cada execução de pipeline cria um trabalho no Orchestrator, você também pode visualizá-los no Orchestrator:

• No Automation Ops™, passe o mouse sobre o lado direito de um pipeline e, no menu contextual, selecione Visualizar logs.

• No Orchestrator, acesse a pasta Pipelines dedicados > Automações > Trabalhos. Na coluna Origem , procure a tag Pipelines e, em seguida, selecione Visualizar logs.

Removendo webhooks manualmente

Se o pipeline tiver sido configurado para ser executado para cada confirmação durante a criação, os webhooks serão criados automaticamente no GitHub/Azure DevOps.

Após excluir a configuração do runtime, você deve remover manualmente os webhooks se o link do Controle de origem com o pipeline já tiver sido removido. Embora não removê-los não afete a funcionalidade do serviço de CI/CD, recomendamos essa etapa.

Para cada pipeline que tem um gatilho em confirmação e cuja conexão de Controle de Origem foi removida, você deve acessar o repositório do GitHub/Azure DevOps e excluir os webhooks após excluir o ambiente de runtime.

Importante:

Se a conexão de Controle de Origem já tiver sido removida em sua organização e esse repositório estiver atualmente conectado a outra organização da UiPath, você pode excluir webhooks válidos da segunda organização. Eles não devem ser excluídos, caso contrário os pipelines não serão disparados na confirmação.

Portanto, antes de excluir webhooks, certifique-se de que o repositório atual não tenha uma conexão válida dentro de uma configuração de runtime de CI/CD válida em uma organização UiPath.

Remover webhooks do repositório do GitHub

Para excluir os webhooks do repositório do GitHub:

1. Acesse o repositório do Github e selecione Configurações > Webhooks.

   

2. Exclua todas as URLs de webhook que terminam com /roboticsops_/cicd_/api/webhooks/github/pipeline.

   

Removendo webhooks do repositório do Azure DevOps

Para excluir os webhooks do repositório do Azure DevOps:

1. Acesse o repositório do Azure DevOps e selecione Configurações do projeto > Gatilhos de serviço.

2. No webhook a excluir, selecione Editar.

   

3. Certifique-se de que a URL do webhook termine com /roboticsops_/cicd_/api/webhooks/azure/pipeline.

   

   

4. Exclua o URL do webhook.