Gerencie seus serviços baseados em faturamento, licenciamento e consumo

A conta corporativa é o ponto central para gerenciar todo o faturamento e licenciamento no GitHub Enterprise Cloud (GHEC), incluindo todas as organizações que fazem parte da sua empresa. É importante examinar sua configuração de faturamento como uma das primeiras etapas ao configurar sua conta corporativa. Configurar uma forma de pagamento e confirmar seu limite de gastos garante que você esteja pronto para começar a usar serviços baseados em consumo, como GitHub Actions, Packages e Codespaces imediatamente, de acordo com seus orçamentos e políticas. Você também deve se familiarizar com a forma como funcionam os relatórios da sua conta corporativa sobre o consumo de licenciamento para entender como as licenças do GitHub Enterprise e outros serviços licenciados separadamente são usadas e apresentadas a você.

Neste guia, você aprenderá:

Como o GHEC determina o licenciamento de usuários para fins de faturamento
Como configurar acesso e limites de gastos em serviços baseados em consumo, como o GitHub Actions, Packages e Codespaces
Como gerenciar políticas e licenciamentos em serviços licenciados separadamente, como o GitHub Copilot e o GitHub Advanced Security

Licenças de usuário

O GHEC utiliza um modelo de licenciamento exclusivo para cada usuário. Isso significa que o GitHub conta cada membro ou colaborador externo uma vez para fins de faturamento, mesmo que a conta do usuário esteja associada a várias organizações em uma empresa ou tenha acesso a vários repositórios da organização. As licenças de usuário do GHEC são adicionadas à empresa no momento da compra. A empresa precisa ter licenças de usuário suficientes para continuar convidando ou provisionando usuários adicionais.

Mais especificamente, uma conta em cada um dos seguintes cenários conta como um usuário faturável único:

Proprietário da empresa com papel de membro ou proprietário de pelo menos uma organização da empresa
Membro da organização, incluindo proprietários
Colaborador externo em repositórios internos ou externos de propriedade da organização, exceto forks (colaboradores com acesso apenas a repositórios públicos não consomem licenças)
Usuário inativo
Qualquer pessoa com um convite ativo para se tornar membro ou proprietário da organização (somente em empresas que não usam Enterprise Managed Users [usuários gerenciados pela empresa, EMUs])
Qualquer pessoa com um convite pendente para se tornar um colaborador externo em repositórios privados ou internos da organização, exceto forks (somente em empresas que não usam EMUs)

Por outro lado, uma conta de cada um dos tipos de uso listados a seguir não conta como um usuário único faturável:

Proprietário da empresa ou gerente de cobrança que não é um membro de pelo menos uma organização da empresa
Gerente de cobrança de organizações individuais que não tem outro tipo de uso
Qualquer pessoa com um convite pendente para se tornar gerente de cobrança (somente em empresas que não usam EMUs)
Qualquer pessoa com um convite pendente para se tornar um colaborador externo em repositório público da organização (somente em empresas que não usam EMUs)
Uma conta de usuário gerenciada suspensa (somente em empresas que usam EMUs)

Serviços baseados em consumo

O uso de serviços baseados em consumo, como executores do Actions (Actions runners) hospedados pelo GitHub, armazenamento compartilhado entre o GitHub Actions e o Packages, e o Codespaces, é cobrado por unidade consumida. O consumo de todas as organizações da empresa é agregado em uma única fatura em nível empresarial.

O plano do GHEC inclui uma quantidade mensal fixa de armazenamento e minutos (direitos), que engloba os minutos usados pelo executor do Actions (Actions runner) hospedado pelo GitHub e o armazenamento compartilhado entre o Actions e o Packages. É necessário definir um método de pagamento para cobrança em caso de uso além dos diretos incluídos ou de serviços que não incluem direitos. Também é possível impor limites em cada recurso para controlar os gastos ou definir limites de gastos ilimitados para garantir a continuidade do serviço.

Embora as cobranças da organização sejam agregadas em uma única fatura empresarial, um relatório detalhado de todos os serviços de consumo está disponível.

Direitos incluídos em serviços baseados em consumo

Os direitos estão incluídos nos minutos do executor do Actions (Actions runner) hospedado pelo GitHub e no armazenamento compartilhado entre o Actions e o Packages como parte dos planos do GHEC. Todas as contas corporativas do GHEC recebem um número padrão de direitos a serem compartilhados, independentemente do porte da empresa ou do número de organizações/usuários. Esses serviços incluídos visam ajudar a empresa a começar a usar o GitHub Actions e o Packages, habilitando automação de workflow simples, apoiando atividades piloto, executando testes de varreduras de segurança e outros usos não essenciais aos negócios. Pretende usar o GitHub Actions e/ou o Packages como parte dos pipelines de produção de DevSecOps? Defina um método de pagamento e limites de gastos para garantir o uso contínuo desses serviços além dos direitos mensais incluídos.

Definindo pagamentos para serviços baseados em consumo

É possível conectar um ID de assinatura do Azure à conta corporativa para pagar por quaisquer serviços do GitHub baseados em consumo que excedam os direitos concedidos à empresa. Esta opção está disponível para qualquer pessoa que tenha uma assinatura do Azure e prefira esse método de faturamento.

Qualquer cliente com uma assinatura do Azure pode conectar o ID de assinatura do Azure à conta corporativa e deixar que o faturamento do Azure gerencie as cobranças. A assinatura do Azure é usada apenas para fins de faturamento. Nenhum recurso será criado ou usado na assinatura do Azure.

É necessário ter permissões de proprietário na assinatura do Azure e ser proprietário da empresa no GitHub para conectar a assinatura do Azure.

Definindo limites de gastos para serviços baseados em consumo

Após definir o pagamento para os serviços baseados em consumo, considere configurar limites de gastos para cada serviço. Esses limites permitem controlar o custo por uso. Um limite de custo de US$ 0 evita cobranças adicionais para o serviço, mas permite que o serviço seja utilizado até que os direitos incluídos se esgotem. Também é possível definir o limite como “ilimitado”. Assim, o serviço continuará sendo executado, independentemente do quanto for gasto. O limite de gastos padrão para clientes faturáveis é definido como ilimitado, então é necessário atualizá-lo caso queira definir um limite específico.

É possível definir limites de gastos diferentes por serviço no GitHub Actions, no Packages e no Codespaces.

Relatando uso/faturamento em serviços baseados em consumo

Informações sobre o faturamento dos serviços de consumo são fornecidas tanto no nível de organização quanto no nível empresarial agregado. É possível visualizar o consumo mensal na interface do usuário ou fazer download dos relatórios de uso granular em formato CSV. Esses relatórios servem como ponto de partida para análises adicionais, estornos ou geração de relatórios e análises mais aprofundados.

Semelhante aos limites de gastos, é possível visualizar os detalhes de uso independentes do GitHub Actions, do Packages e do Codespaces.

Políticas do GitHub Actions

Habilite ou desabilite o GitHub Actions por política em todas, algumas ou nenhuma das organizações da empresa. Se o GitHub Actions for habilitado, os administradores podem definir quais ações específicas estarão disponíveis no fluxos de trabalho. Existem três opções disponíveis:

Permitir todas as ações e fluxos de trabalho reutilizáveis (reusable workflows): os usuários podem executar fluxos de trabalhos que contêm qualquer ação do GitHub Marketplace ou que estão definidos em um repositório público. Como é uma opção muito permissiva, ela não é adequada para a maioria das empresas. Nenhuma revisão ou aprovação é necessária para fazer uso de qualquer ação pública.
Permitir ações empresariais e fluxos de trabalho reutilizáveis (reusable workflows): esta configuração é altamente restritiva se comparada com a opção acima, mas ainda assim não é adequada para a maioria das empresas porque exige que todas as ações que serão usadas existam na empresa. Isso significa que os desenvolvedores não conseguem usar ações diretamente do GitHub Marketplace. Também é preciso definir um processo para clonar todas as ações desejadas para a empresa, treinar as equipes para consultar essas ações internas e verificar e incorporar atualizações regularmente.
Permitir ações empresariais, selecionar ações não empresariais e fluxos de trabalho reutilizáveis (reusable workflows): esta é a escolha prudente e gerenciável para a maioria das empresas. Esta opção apresenta uma lista de permissões que os administradores podem usar para autorizar individualmente ações criadas pelo GitHub, ações criadas por criadores verificados pelo GitHub e ações e fluxos de trabalho reutilizáveis (reusable workflows) específicos de terceiros.

Empresas que optam pela terceira opção precisam criar e manter seu próprio processo de solicitação de acesso ao Actions e os administradores terão a opção de consultar as ações aprovadas de quatro maneiras:

O caminho simples do proprietário/repositório para o código-fonte da ação
Um branch específico da ação, referenciado como owner/repo@branch
Uma tag/versão específica da ação, referenciada como owner/repo@tag
Um SHA específico do commit da ação, referenciado como owner/repo@SHA

As empresas que realizam suas próprias revisões de segurança sobre as ações de terceiros devem usar a sintaxe owner/repo@SHA específica da versão da ação aprovada, visto que SHAs de commits são imutáveis, enquanto o código referenciado por nomes e tags de branch pode mudar.

Também é possível executar ações em executores auto-hospedados em vez de em executores hospedados pelo GitHub. Alguns clientes optam por prevenir o uso de executores auto-hospedados no nível de repositório por questões de segurança porque, diferente dos executores hospedados pelo GitHub, não há garantia que os executores auto-hospedados para o GHEC serão hospedados em máquinas virtuais íntegras e efêmeras. Como resultado, um código não confiável em um fluxo de trabalho pode comprometer a empresa. Defina uma política para prevenir o uso de executores auto-hospedados no nível de repositório para se proteger deste possível problema de segurança. Em empresas que usam o modelo Enterprise Managed User (EMU), é possível definir uma política que restringe a criação de executores em repositórios de propriedade do EMU, não organizações.

Políticas do Codespaces

O GitHub Codespaces é um ambiente de desenvolvimento instantâneo baseado em nuvem. Ele fornece aos desenvolvedores linguagens, ferramentas e utilitários comuns para o desenvolvimento, permitindo começar projetos rapidamente, sem precisar instalar diversas ferramentas e dependências no local para começar a contribuir. O GHEC oferece os controles necessários para implementar o Codespaces gradualmente nas organizações. É possível habilitar o Codespaces para todas as organizações, para organizações específicas ou desabilitá-lo completamente.

Como alternativa, se for necessário estar em conformidade com normas de segurança que exigem controle reforçado sobre o código privado na empresa, desabilite o Codespaces em todas as organizações da empresa. É possível definir uma política empresarial para habilitar ou desabilitar o Codespaces nas organizações da empresa.

Serviços licenciados separadamente

GitHub Copilot

As políticas desta seção governam o uso do GitHub Copilot, o auxiliar de programação por IA do GitHub. O GitHub Copilot é licenciado separadamente do GHEC. Se a sua empresa está usando esta ferramenta, use as configurações desta seção para gerenciar quais usuários da organização têm acesso para usar o GitHub Copilot e permitir ou prevenir sugestões do GitHub Copilot que correspondem a código público.

Análise e segurança de código (GitHub Advanced Security)

O GitHub Advanced Security oferece recursos adicionais de segurança da aplicação, como segredos e varredura de código em repositórios privados. Ele é licenciado por committer ativo em repositórios que usam os recursos. Um committer é considerado ativo se foi feito o push de um dos commits para o repositório nos últimos 90 dias, independentemente de quando ele foi originalmente criado.

A seção de análise e segurança de código da guia de políticas da empresa também contém controles do Dependabot, que é um recurso do GHEC incluído para auxiliar no uso de dependências de código aberto no seu código com segurança. O Dependabot notifica você sobre vulnerabilidades nas dependências que você usa, abre pull requests para correções de segurança conforme estão disponíveis e até mesmo lembra você automaticamente de atualizar suas dependências quando novas versões forem lançadas para ficar à frente de quaisquer problemas.

Consulte o Roteiro de aprendizagem sobre segurança para obter mais informações sobre licenciamento, habilitação e definição de políticas para recursos de segurança e sobre o GitHub Advanced Security.

A seguir: Gerencie a visibilidade, as regras e as configurações do seu repositório

Já analisamos algumas questões básicas de configuração e configuramos algumas proteções em torno do faturamento. Agora, examinaremos como configurar repositórios, o componente estrutural sob as organizações, para obter controles mais refinados da visibilidade e da capacidade de fazer o merge de pull requests.