Implantações e ambientes

Regras de proteção de implantação

As normas de proteção de implantação exigem a aprovação de condições específicas antes que um trabalho que faz referência ao ambiente possa prosseguir. Você pode usar regras de proteção de implantação para exigir uma aprovação manual, atrasar um trabalho ou restringir o ambiente a certos branches. Você também pode criar e implementar regras de proteção personalizadas da plataforma GitHub Apps para usar sistemas de terceiros para controlar implantações referenciando ambientes configurados no GitHub.

Os sistemas de terceiros podem ser sistemas de observabilidade, sistemas de gerenciamento de alterações, sistemas de qualidade de código ou outras configurações manuais que você usa para avaliar a prontidão antes que as implantações sejam implementadas com segurança nos ambientes.

Revisores necessários

Use os revisores necessários para exigir que uma pessoa ou equipe específica aprove os trabalhos do fluxo de trabalho que fazem referência ao ambiente. Você pode listar até seis usuários ou equipes como revisores. Os revisores devem ter, pelo menos, acesso de leitura ao repositório. Apenas um dos revisores precisam aprovar o trabalho para que prossiga.

Você também tem a opção de impedir auto-revisões para implantações em ambientes protegidos. Se você habilitar essa configuração, os usuários que iniciarem uma implantação não poderão aprovar o trabalho de implantação, mesmo que sejam revisores obrigatórios. Isso garante que as implantações em ambientes protegidos sejam sempre revisadas por mais de uma pessoa.

Para obter mais informações sobre como revisar trabalhos que referenciam um ambiente com revisores obrigatórios, confira Revisar implantações.

Temporizador de espera

Use o temporizador de espera para atrasar o trabalho por um período específico de tempo depois que o trabalho for inicialmente acionado. O tempo (em minutos) deve ser um número inteiro entre 1 e 43.200 (30 dias). O tempo de espera não será contabilizado no tempo de cobrança.

Branches e tags de implantação

Use branches e tags de implantação para restringir quais branches e tags podem ser implantados no ambiente. Confira abaixo as opções de branches e tags de implantação para um ambiente:

• Sem restrição: nenhuma restrição sobre qual ramificação ou marca pode ser implantada no ambiente.

• Protected branches only: somente os branches com regras de proteção de branch habilitadas podem ser implantados no ambiente. Se nenhuma regra de proteção de branch for definida para qualquer branch no repositório, todos os branches poderão implantar. Para obter mais informações sobre as regras de proteção do branch, confira Sobre branches protegidos.

  Observação

  As execuções de fluxo de trabalho de implantação disparadas por tags com o mesmo nome de uma branch protegida e forks com branches que correspondem ao nome da branch protegida não podem ser implantadas no ambiente.

• Selected branches and tags: somente os branches e as tags que correspondem aos seus padrões de nome especificados podem ser implantados no ambiente.

  Se você especificar releases/* como uma regra de branch ou tag de implantação, somente os branches ou as tags cujos nomes começam com releases/ podem ser implantados no ambiente. (Os caracteres curinga não corresponderão a /. Para encontrar a correspondência de branches ou tags que começam com release/ e contêm uma barra adicional, use release/*/*). Se você adicionar main como uma regra de branch, um branch chamado main também poderá ser implantado no ambiente. Para obter mais informações sobre opções de sintaxe para ramificações de implantação, consulte a documentação do Ruby File.fnmatch.

  Observação

  Os padrões de nomes devem ser configurados individualmente para branches ou rótulos.

Permitir que os administradores ignorem as regras de proteção configuradas

Por padrão, os administradores podem ignorar as regras de proteção e forçar implantações para ambientes específicos. Para saber mais, confira Revisar implantações.

Como alternativa, você pode configurar ambientes para não permitir ignorar as regras de proteção para todas as implantações no ambiente.

Regras de proteção de implantação personalizadas

Você pode habilitar suas próprias regras de proteção personalizadas para bloquear implantações com serviços de terceiros. Por exemplo, você pode usar serviços como Datadog, Honeycomb e ServiceNow para fornecer aprovações automatizadas para implantações no GitHub. Para obter mais informações, confira Creating custom deployment protection rules.

Depois que as regras de proteção de implantação personalizadas forem criadas e instaladas em um repositório, você poderá habilitar a regra de proteção de implantação personalizada para qualquer ambiente no repositório. Para obter mais informações sobre como configurar e habilitar regras de proteção de implantação personalizadas, confira Configurar regras de proteção de implantação personalizadas.

Segredos do ambiente

Os segredos armazenados em um ambiente só estão disponíveis para trabalhos de fluxo de trabalho que fazem referência ao ambiente. Se o ambiente exigir aprovação, um trabalho não poderá acessar segredos de ambiente até que um dos revisores necessários o aprove. Para saber mais sobre segredos, confira Segredos.

Variáveis de ambiente

As variáveis armazenadas em um ambiente só ficam disponíveis para trabalhos de fluxos de trabalho que fazem referência ao ambiente. Essas variáveis só podem ser acessadas usando o contexto vars. Para saber mais, confira Armazenar informações em variáveis.