Aplicação de análise de código

Como administrador, você pode aplicar a análise de código quando os desenvolvedores fizerem o check-in de arquivos de automação no espaço de trabalho público. Você pode restringir os desenvolvedores de RPA ou os Citizen Developers de verificar as automações que contêm violações de análise de código com base nas permissões atribuídas a eles em sua função personalizada.

A aplicação da análise do código é baseada em uma combinação dos seguintes aspectos:
  • Políticas aplicadas a pastas
  • Permissões alocadas aos usuários em suas funções personalizadas
As políticas de análise de código se aplicam a arquivos na guia Automação. Você pode configurar a mesma regra com duas políticas diferentes, mas com níveis de gravidade diferentes; uma com gravidade baixa e outra com gravidade alta. Ao usar políticas com regras configuradas em diferentes níveis de gravidade, você pode concentrar a aplicação em projetos de automação específicos.

aplicar a análise de código

Permissões de aplicação de análise de código

As seguintes permissões de aplicação de análise de código estão disponíveis:

  • Habilitar a aplicação do check-in de bots: Uma permissão padrão para todas as funções que permite ao usuário verificar no arquivo de automação se ele não tem violações de análise de código.
  • Permitir o check-in com violações de baixa gravidade: Essa permissão opcional permite que o usuário verifique no arquivo de automação se ele tem violações de análise de código de baixa gravidade.
  • Permitir o check-in com violações de alta gravidade: Essa permissão opcional permite que o usuário verifique no arquivo de automação se ele tem violações de análise de código de alta gravidade.
Importante: A partir do Automation 360 v.29, todas as funções do sistema (como AAE_Basic ou AAE_Admin) terão apenas as permissões para fazer checkin de arquivos de automação sem violações. Todas as funções personalizadas (funções definidas pelo usuário) são atualizadas para conter as permissões de check-in com violações de baixa e alta gravidade. Se você usar apenas funções definidas pelo sistema para seus usuários, para configurar a aplicação, deverá criar novas funções para atribuir as permissões apropriadas para fazer checkin de arquivos de automação com violações.

Use diferentes funções e permissões para restringir o check-in de arquivos de automação com base no nível de habilidade do desenvolvedor. Por exemplo, você pode ter políticas com violações de gravidade baixa e alta aplicadas a uma pasta. Você pode ter Citizen Developers com permissão para fazer o check-in de arquivos de automação com violações de alta e baixa gravidade, enquanto os desenvolvedores de RPA podem ter permissão para fazer o check-in de arquivos de automação sem violações ou apenas com violações de baixa gravidade.

Você pode usar diferentes políticas em diferentes projetos de automação e definir diferentes níveis de gravidade de regras para diferentes políticas e ambientes. Por exemplo, no ambiente de teste, você pode ter políticas em que todas as regras são definidas como de alta gravidade, e os desenvolvedores de RPA só podem fazer checkin de arquivos de automação com baixa gravidade ou sem violações.

Exemplo

O exemplo a seguir mostra três arquivos de automação com seus resultados de análise de código:
Arquivos de automação Resultados da análise do código
Arquivo 1 10 regras com violação de alta severidade
Arquivo 2 7 regras com violação de alta severidade

20 regras com violação de baixa severidade
Arquivo 3 10 regras com violação de baixa severidade
O exemplo inclui três usuários com funções atribuídas:
Usuário Função atribuída
Alice Função 1
Bob Função 2
Carol Função 1, Função 2
  • Os usuários na função 1 podem fazer checkin de arquivos de automação com resultados de violação de alta gravidade.
  • Os usuários na função 2 podem fazer checkin de arquivos de automação com resultados de violação de baixa gravidade.

A aplicação da análise de código para esses usuários é a seguinte:

  • Alice pode fazer check in do arquivo 1.
  • Bob pode fazer check in do arquivo 3.
  • Carol pode fazer check in do arquivo 1, 2 e 3.