Traduzido do Inglês para o Português - www.onlinedoctranslator.

com

Bem-vindo a este curso da Atlassian University sobre o Jira Automation for Admins.

Aqui, você entenderá como esse poderoso recurso do Jira Cloud pode tornar seus projetos
do Jira mais eficientes e simplificados.
E aqui está o que você vai aprender:
• Primeiro, abordaremos os fundamentos da automação do Jira e compararemos e contrastaremos as
regras de automação com o fluxo de trabalho e outras formas de automatizar o Jira
• Aprenderemos a configurar todas as várias configurações de regras
• Explore muitos casos de uso de regras que atendem a requisitos de negócios complexos e
diversos.
• Ao longo do caminho, aprenderemos muitas dicas e truques para configurar regras e
solucionar erros de tempo de execução.
• E, finalmente, revisaremos as configurações globais de automação.
Para obter sucesso neste treinamento e entender os casos de uso apresentados, você precisará do
seguinte:
• Experiência prática em administração de projetos
• E principalmente, um bom entendimento das permissões do projeto.
• E você precisa ter domínio do JQL, já que algumas áreas de automação dependem dele.
Aqui está a nossa agenda.
Vamos começar com a visão geral da automação no contexto do Jira.
Automação é um construtor de regras “se-isto-então-aquilo” sem código que complementa outras formas
de automatizar o Jira para tornar seus projetos e equipes mais poderosos e eficientes.
Mas não temos várias maneiras de automatizar vários bits de funcionalidade no Jira? Sim nós
fazemos.
Primeiro, temos fluxos de trabalho, é claro. Com pós-funções,
• você pode atribuir um problema ao usuário ou relator atual, por exemplo.
• E você pode definir, atualizar ou limpar vários campos do sistema e personalizados.
E há operações em massa:
• Incluindo problemas de edição em massa
• problemas de movimentação em massa
• e problemas de transição em massa
Você também pode automatizar com vários aplicativos do Marketplace que
• fornecem pós-funções adicionais para estender fluxos de trabalho, bem como scripts prontos.
E finalmente,
• você pode fazer alguns scripts personalizados por meio da API do Jira.
• Também existem assinaturas de e-mail que executam os resultados de um filtro salvo em alguma
programação definida e enviam e-mails aos usuários ou grupos inscritos.
Um dos grandes aplicativos relacionados à automação no Atlassian Marketplace era, e ainda é,
o Automation for Jira do fornecedor Code Barrel.
O aplicativo estava originalmente disponível para Cloud, Data Center e Server.
Então, quando a Atlassian adquiriu a empresa, a automação ficou disponível como um recurso
nativo do Jira Cloud para a família de produtos Jira.
E o aplicativo original permanece e continua sendo vendido como um aplicativo no Atlassian
Marketplace para Jira Data Center and Server.

E observe que o Jira Service Management também possui Legacy Automation. Na nuvem, as regras de
automação herdadas serão eventualmente migradas para o Automation for Jira.
Existem vários elementos para configurar em uma regra de automação. Vamos analisá-los brevemente
neste módulo e, em seguida, nos aprofundar no próximo.
A seção de detalhes da regra inclui configurações como:
• o nome
• e seu escopo – por exemplo, a regra é executada em um único projeto ou globalmente.
Os gatilhos iniciam a execução de uma regra. Os gatilhos podem escutar eventos ou ser programados para serem

executados. Os eventos incluem:

• Problema criado
• e Work Logged, entre outros.
As condições garantem que as ações serão executadas apenas se todas as condições anteriores forem aprovadas.
Exemplos incluem:
• Condição de campos de problema que verifica se o campo de um problema atende a determinados critérios
• E Condição do usuário que compara um usuário com critérios especificados. E há
mais.
As ações realizam alterações em um sistema, como:
• Faz a transição de um problema de um status para outro
• Ou atribua um problema ao usuário selecionado. E há muito mais ações.
Você também pode criar uma seção separada de uma regra e executar ações e condições em outros
problemas relacionados. Isso inclui:
• Subtarefas do problema que acionou a regra ou
• Problemas vinculados do problema que acionou a regra.
E há uma configuração de alternância liga/desliga que é útil durante o desenvolvimento e teste. Uma regra
pode ser
• ativado ou
• Desabilitado
Aqui está um exemplo de uma regra configurada:
1. O evento acionador é quando um problema é transferido para Concluído.
2. A condição verifica se há problemas vinculados.
3. Em caso afirmativo, uma ramificação é criada para esses problemas vinculados

4. E então a regra executa uma ação em cada questão vinculada; ou seja, adiciona um comentário.
5. A regra está habilitada
6. E podemos ver a seção Detalhes da regra.
“Santa cavala! A automação do Jira vai substituir meu trabalho?”, pergunta Tim, o recém-certificado
Jira Cloud Administrator. Não, companheiro. Você pode manter seu emprego. Isso só vai facilitar o
seu trabalho.
As regras podem:

• Amplie a funcionalidade de fluxo de trabalho pronto para uso

• Alivie a carga administrativa de criação, teste e manutenção de fluxos de trabalho para que você gaste
menos tempo no editor de fluxo de trabalho.
• E capacite os administradores de projeto para atender às suas próprias necessidades de negócios
Mas a automação não pode substituir totalmente os fluxos de trabalho. Eles continuam sendo o principal mecanismo que

alimenta o Jira.

Você precisa de fluxos de trabalho para definir o fluxo do processo pelo qual os problemas se movem da criação à
conclusão, seja por meio da visualização do problema ou por arrastar e soltar em quadros ágeis ou por meio de
automação.
Os fluxos de trabalho permitem que você configure as condições. Por exemplo, o usuário deve ser membro de
um grupo ou função para ver e executar transições de fluxo de trabalho específicas.
E os fluxos de trabalho também possuem validadores que determinam se uma transição será executada
com sucesso, como verificar se o valor correto foi inserido em uma tela de transição. As regras de
automação não podem atender aos requisitos que exigem o uso de validadores ou condições de fluxo
de trabalho.
Agora vamos ver o primeiro caso de uso; escolhendo maneiras de automatizar o Jira.

Ted diz que está gastando muito tempo (1) atualizando os problemas manualmente, (2) escalonando-os e (3)
procurando por eles posteriormente para acompanhamento.

Ele pede sua ajuda para automatizar seus processos. Dependendo de alguns fatores e requisitos
adicionais, você precisa escolher o método certo ou a combinação de métodos para automatizar o
Jira.
Resumindo, Ted poderia usar uma função de postagem de fluxo de trabalho para atualizar campos durante uma transição.
Ou ele pode usar operações em massa para atualizar ou fazer a transição de problemas em massa. Ou ele pode criar uma
regra de automação para atualizar e fazer a transição de problemas com base em vários outros gatilhos e condições ou
em um cronograma definido. Ele pode criar um gadget em um painel ou, melhor ainda, uma assinatura de filtro para
enviar por e-mail a ele uma lista de problemas escalados para acompanhamento posterior.

Para obter mais detalhes sobre as considerações e a solução proposta, você pode ler o guia de
solução em PDF que fornecemos.
Agora, uma rápida verificação de conhecimento.

Você recebeu vários requisitos de negócios. Qual requisito definitivamente deve ser satisfeito com uma
alteração no fluxo de trabalho versus uma regra de automação?
A. liberar o responsável ao reabrir um problema
B. notificar o scrum master ao fazer a transição para Bloqueado
C. evitar que o relator encaminhe problemas
D. atualize o épico quando todas as histórias estiverem concluídas
Vamos olhar mais de perto.
R. Incorreto. Você pode usar o gatilho “Transição de problema” e a ação “Editar problema” em uma regra de
automação para atender a esse requisito. Você também pode usar uma função de postagem de fluxo de
trabalho.
B. Incorreto. Você pode usar o gatilho “Problema com transição” e a ação “Enviar e-mail” em uma regra de
automação para atender a esse requisito. Você também pode usar uma função de postagem de fluxo de
trabalho com um sistema ou evento de notificação personalizado.
C. Correto.Para evitar que um usuário use uma transição de fluxo de trabalho (para escalar um problema), você deve usar
uma condição de fluxo de trabalho. As regras de automação não são usadas para essa finalidade.

D. Incorreto. Você pode usar o gatilho “Problema com transição”, uma regra de ramificação em Histórias (ou outros
problemas na Epic) e a ação “Editar problema” em uma regra de automação para atender a esse requisito.
Vamos agora examinar mais detalhadamente cada uma das áreas de configuração, incluindo detalhes de regras de
automação, componentes e valores inteligentes.
A seção Detalhes da regra contém várias configurações importantes.
• Onomede uma regra deve ser descritivo como “Fechar solicitações duplicadas no projeto ITHD” versus
apenas “Regra Jake nº 5”. Isso ajuda outras pessoas a verificar rapidamente as regras e entender o que
podem estar fazendo. Isso é especialmente apreciado pelos administradores do Jira, que podem ter centenas
de regras de automação configuradas em sua instância.
• Apesar dedescriçãocampo é opcional, também é uma boa prática inserir mais detalhes aqui
sobre o que a automação faz; especialmente para regras mais complexas com muitos
componentes.
• ONotificar sobre erroconfiguração é uma escolha suspensa de três opções. Sua seleção
provavelmente dependerá se você ainda está desenvolvendo e testando a regra ou se ela já
está em produção.
• OProprietárioé a pessoa que receberá e-mails quando a regra falhar.
• OPermitir gatilho de regraconfiguração está marcada para permitir que outras ações de regra
acionem esta regra. Ative isso apenas se precisar que essa regra seja executada em resposta a outra
regra. Voltaremos a isso no módulo final.
• Oescopoda regra é onde a regra está sendo executada.
• E finalmente, oAtoré a pessoa que estará “executando” as ações dentro da regra. Vamos
expandir mais sobre escopo e ator em um momento.
• Como acabamos de aprender, cada regra tem um escopo
• que especifica onde a regra está sendo executada.
• “Em execução" significa que a regra está ouvindo acionadores e executando ações dentro
o projeto ou projetos listados no escopo.
• O escopo também está relacionado aos limites de execução da regra de automação, conforme definido no plano de preços.
O escopo de uma regra pode ser um único projeto. Isso é mais comum e é uma das razões pelas quais a
automação é tão poderosa. Ele capacita os administradores de projeto a criar e manter suas próprias
regras para executar ações apenas em seus próprios projetos, sem afetar negativamente os outros.
Digamos que uma regra atribua todos os bugs recém-criados a um indivíduo chamado Angie. Você deseja
que esta regra seja executada em todos os projetos do Jira ou apenas naquele em que Angie é responsável
por corrigir bugs?

Regras de projeto único também não são contadas para os limites de execução de regra aplicados, com base no
plano de preços.
As regras também podem ser executadas em vários projetos em sua instância, por exemplo, projetos que compartilham

os mesmos fluxos de trabalho.

As regras também podem ter o tipo de projeto como escopo. Isso significa que eles são executados em todos
os projetos de um tipo específico, como negócios, software ou projetos de gerenciamento de serviços.
E, finalmente, você pode escrever regras que sejam executadas em todos os projetos em sua instância.

As regras executadas em mais de um projeto, e especialmente essas regras globais, são muito
poderosas, mas também potencialmente muito destrutivas. É por isso que apenas os administradores
do Jira podem criar e manter regras com escopo além de um único projeto.

Regras globais estão disponíveis em qualquer projeto. Se um administrador de projeto recebeu direitos para
gerenciar regras de automação, ele pode visualizar regras globais e fazer uma cópia de uma regra global para
executar e manter em seus próprios projetos.
• Actor é outra configuração muito importante na seção Rule Details. As ações definidas em uma
regra de automação são executadas em nome do usuário selecionado como ator.
• As regras não podem executar nenhuma ação que o usuário Ator não possa executar. Jira
os administradores podem modificar o esquema de permissões de um projeto para impedir que o ator
execute determinadas ações. Isso permite um controle mais refinado sobre o que as regras podem fazer.

• O ator é exibido na guia do histórico de problemas como se a ação fosse executada manualmente. Por
exemplo, se uma regra de automação estiver configurada para editar cada problema em um sprint, a
guia Histórico desses problemas mostrará o ator da regra como tendo feito essas atualizações.
• E o Ator receberá e-mails para cada ação realizada em seu nome.
Por padrão, todas as ações executadas pela automação do Jira são vistas como sendo executadas pelo
“usuário” chamado Automation for Jira. E, por padrão, o Automation for Jira tem as permissões necessárias
para executar todas as ações necessárias em um projeto.
Ao configurar uma regra, você tem a opção de alterar o ator da regra, para que as regras de automação
possam ser vistas como sendo executadas por um usuário nomeado real, um membro real da equipe. Por
exemplo, se uma regra de automação adiciona um comentário a todos os problemas em um sprint, Anne pode
querer configurar a regra para que o comentário seja adicionado por ela, em vez do usuário do Automation
for Jira.

As ações definidas na regra serão executadas pelo usuário que você escolher – portanto, você deve
garantir que ele tenha as permissões necessárias para executar essas ações.

Se Anne não tiver permissão para “Adicionar comentário”, essa ação em sua regra não será executada.
Outras ações ainda podem ser executadas, se Anne tiver as outras permissões necessárias.
Você também pode definir o Ator para ser o usuário que acionou o evento, em vez do
mesmo usuário nomeado. A regra executará ações em nome da pessoa que executou a
ação que acionou a regra.

Por exemplo, digamos que haja uma regra que adiciona um comentário “Data de vencimento foi alterada”
sempre que um usuário modifica a Data de vencimento. Em seguida, Cindy modifica a data de vencimento em
um de seus problemas atribuídos. O comentário que é adicionado ao seu problema quando a regra é executada
mostrará que ela fez o comentário, ao contrário da Automação para Jira, por exemplo. Mais uma vez, você
precisa garantir que todos que possam acionar a regra tenham as permissões apropriadas.