UiPath Automation Ops – Pipelines

Automation Ops - Pipelines fornece uma maneira fácil de configurar um sistema de integração contínua/entrega contínua para gerenciar o código de seus projetos de automação em repositórios externos, como o Github ou 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, utilizam o pacote de atividades Pipelines — do Automation Ops. Para um usuário visualizar 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 do 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 do pipeline do Studio para o Orchestrator, certifique-se de selecionar também Incluir Origens na seção Opções de Publicação . Leia mais sobre a publicação de projetos de automação.

Configuração

O Automation Ops - Os pipelines funcionam executando processos de pipeline usando o Unattended Robot, o que significa que uma configuração específica no Orchestrator é necessária antes de usá-los. Essa configuração é chamada de ambiente de Runtime do pipeline.

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:

The robot account created during the quick setup is essential. All the pipelines (Orchestrator jobs) are ran on its behalf. Deleting the robot account causes an invalid pipeline runtime configuration and the need to rerun the quick setup.

Excluir a pasta de pipelines dedicados no Orchestrator quebra 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 futuros pipelines. Você pode escolher entre usar uma máquina existente do seu ambiente ou criar automaticamente uma nova máquina sem servidor chamada "Pipelines Robot".

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 que seja Automation User, Permitir que seja Automation Publisher
• Pasta de pipelines: função da pasta Pipelines, usuário de automação, editor de automação

Observação:

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

The Run Tests activity runs the tests in the provided Orchestrator folder. The Pipelines robot account publishes the package in the respective folder, but the tests can be run by any robot account in that folder that qualifies for the test run, not only by the Pipelines robot account.

Além disso, os seguintes processos de pipelines predefinidos estão 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

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 escolher 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 ignorar a validação antes de construir o pacote. Esse valor fica desabilitado por padrão.
• Aprovador - O endereço de e-mail do aprovador da tarefa criada no Action Center.
• PrimeiroUrlDoOrchestrator - O URL para o Orchestrator onde o pacote construído é publicado.
• PrimeiraPastaDoOrchestrator - 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.
• TemFeedDoPacoteDoSame - 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 processo.

Importante:

When using the Build activity, validate the compatibility requirements between the automation projects you are building and the machine running the process.

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. Na Automation Cloud, navegue até Automation Ops > Pipelines usando a barra de navegação do lado esquerdo.
2. Selecione Novo pipeline. Se você tiver o repositório externo conectado ao Controle de origem , ele também será automaticamente conectado aqui.
   Observação: Apenas uma organização do UiPath Automation Cloud pode ser conectada a uma organização 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). Clique em Avançar.
   
   
   
   
4. Na guia Definição de pipeline :
   • Selecione o processo do pipeline. Se o processo do seu pipeline tiver argumentos, você poderá adicionar seus valores.
   
   
   
   
   
5. Na aba Salvar e executar , configure os seguintes itens:
   • Nome do projeto - Insira um nome para o projeto de pipeline. Por padrão, o nome é composto a partir do nome do repositório e do nome do projeto de automação do pipeline.
   • Descrição — Opcionalmente, adicione uma descrição.
   • Executar este pipeline - Selecione como você deseja que o pipeline seja executado:
     • For each commit - A automação do pipeline é acionada toda vez que há uma alteração no código no repositório para o projeto selecionado.
     • Executarei manualmente - A automação do pipeline é disparada manualmente.
6. Clique em Salvar para salvar o pipeline ou em Salvar e executar para salvar e também 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 é acionado por qualquer confirmação no repositório.

O argumento ProjectPath é preenchido com o valor selecionado no campo Automation project (optional) da Etapa de Local a partir da configuração do pipeline.

Se o campo for deixado em branco, o argumento do processo ProjectPath permanecerá vazio. Esse cenário pode ser usado para repositórios que têm apenas um projeto de automação.

Execução manual de um pipeline

1. Na Automation Cloud, navegue até o Automation Ops usando a 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 dispara o pipeline para ser executado e é possível ver o progresso de cada etapa em tempo real.

A partir daqui, você também pode editar o pipeline selecionando Configurações de pipeline. Isso exibirá o resumo do pipeline, a partir do qual você pode:

• 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

Os seguintes processos de pipelines predefinidos estão 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

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

• Criar.e.produzir.com.processo de aprovação :
  • NomeDoProcesso — o nome do processo a ser atualizado. Usado apenas se o projeto for processo.
  • Aprovador - O endereço de e-mail do aprovador da tarefa criada no Action Center.
  • PularTestes - Permite escolher 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 ignorar a validação antes de construir o pacote. Esse valor fica desabilitado por padrão.
  • PrimeiraPastaDoOrchestrator - A pasta do Orchestrator na qual o pacote criado é publicado.
  • PrimeiroUrlDoOrchestrator - O URL para o Orchestrator onde o pacote construído é 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.
  • TemFeedDoPacoteDoSame - 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 ignorar a validação antes de construir o pacote. Esse valor fica desabilitado por padrão.
  • UrlDoOrchestrator - O URL para o Orchestrator onde 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.
  • ÉBiblioteca - Define se o pacote é uma biblioteca ou não.
  • VersãoDoPacote - A versão do pacote a ser copiado.
  • PastaDoOrchestratorDeOrigem - A pasta do Orchestrator da qual o pacote é copiado.
  • UrlDoOrchestratorDeOrigem - O URL para o Orchestrator a partir do qual 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 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 ignorar a validação antes de construir o pacote. Esse valor fica desabilitado por padrão.
  • UrlDoOrchestrator - O URL para o Orchestrator em que o pacote a ser atualizado é encontrado.
  • PastaDoOrchestrator — a pasta do Orchestrator na qual o pacote a ser atualizado é encontrado.
• Update.with.tests
  • NomeDoProcesso — o nome do processo a ser atualizado. Usado apenas se o projeto for 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 o teste antes de construir o pacote. Esse valor fica desabilitado por padrão.
  • UrlDoOrchestrator - O URL para o Orchestrator em que o pacote a ser atualizado é encontrado.
  • PastaDoOrchestrator — a pasta do Orchestrator na qual o pacote a ser atualizado é encontrado.
  • PastaDeTesteDoOrchestrator - 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 o seguinte conjunto de argumentos padrão para o processo de Pipeline:

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. É possível 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 Exibir logs.

• No Orchestrator, acesse a pasta de pipelines dedicados > Automações > Trabalhos. Na coluna Origem , procure a tag de Pipelines e 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 > hooks 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.