Melhores práticas para controle de versões

Este documento fornece práticas recomendadas de controle de versão a serem consideradas ao usar o Terraform para Google Cloud.

Assim como em outras formas de código, armazene o código da infraestrutura no controle de versões para preservar o histórico e permitir reversões fáceis.

Este guia não é uma introdução ao Terraform. Para uma introdução ao uso do Terraform com o Google Cloud, consulte Primeiros passos com o Terraform.

Usar uma estratégia de ramificação padrão

Para todos os repositórios que contêm o código do Terraform, use a seguinte estratégia por padrão:

  • main é a ramificação de desenvolvimento principal e representa o código aprovado mais recente. A ramificação main é protegida.
  • O desenvolvimento ocorre em ramificações de recursos e correções de bugs que se ramificam da ramificação main.
    • Nomeie as ramificações de recursos feature/$feature_name.
    • Nomeie as ramificações de correção de bugs fix/$bugfix_name.
  • Quando um recurso ou uma correção de bug for concluído, mescle-o novamente na ramificação main com uma solicitação de envio.
  • Para evitar conflitos, realoque as ramificações antes de mesclá-las.

Use ramificações do ambiente para configurações raiz

Para repositórios que incluem configurações raiz implantadas diretamente no Google Cloud, uma estratégia de lançamento segura é necessária. Recomendamos que você tenha uma ramificação separada para cada ambiente. Assim, as alterações na configuração do Terraform podem ser promovidas com a combinação de alterações entre as diferentes ramificações.

Ramificação separada para cada ambiente

Permitir ampla visibilidade

Torne o código-fonte e os repositórios do Terraform amplamente visíveis e acessíveis em todas as organizações de engenharia para os proprietários da infraestrutura (por exemplo, SREs) e as partes interessadas da infraestrutura (por exemplo, desenvolvedores). Isso garante que as partes interessadas na infraestrutura possam entender melhor a infraestrutura de que dependem.

Incentivar as partes interessadas da infraestrutura a enviar solicitações de integração como parte do processo de solicitação de mudança.

Nunca confirme secrets

Nunca confirme secrets para controle de origem, incluindo na configuração do Terraform. Em vez disso, faça o upload deles para um sistema como o Secret Manager e referencie-os usando fontes de dados.

Lembre-se de que esses valores confidenciais ainda podem acabar no arquivo de estado e também ser expostos como saídas.

Organizar repositórios de acordo com os limites das equipes

Embora seja possível usar diretórios separados para gerenciar limites lógicos entre recursos, os limites organizacionais e a logística determinam a estrutura do repositório. Em geral, use o princípio de design no qual configurações com diferentes requisitos de aprovação e gerenciamento são separados em diferentes repositórios de controle de origem. Para ilustrar esse princípio, veja algumas configurações de repositório possíveis:

  • Um repositório central: neste modelo, todo o código do Terraform é gerenciado centralmente por uma única equipe de plataforma. Esse modelo funciona melhor quando há uma equipe de infraestrutura dedicada responsável por todo o gerenciamento de nuvem e aprova as alterações solicitadas por outras equipes.

  • Repositórios de equipe:nesse modelo, cada equipe é responsável pelo próprio repositório do Terraform, em que ela gerencia tudo relacionado à infraestrutura própria. Por exemplo, a equipe de segurança pode ter um repositório em que todos os controles de segurança são gerenciados, e as equipes de aplicativos têm o próprio repositório do Terraform para implantar e gerenciar o aplicativo.

    Organizar repositórios nos limites da equipe é a melhor estrutura para a maioria dos cenários corporativos.

  • Repositórios desacoplados: neste modelo, cada componente lógico do Terraform é dividido em um repositório próprio. Por exemplo, a rede pode ter um repositório dedicado e pode haver um repositório de fábrica de projetos separado para criação e gerenciamento de projetos. Isso funciona melhor em ambientes altamente descentralizados em que as responsabilidades alternam com frequência entre as equipes.

Exemplo de estrutura do repositório

É possível combinar esses princípios para dividir a configuração do Terraform em diferentes tipos de repositório:

  • Básico
  • Específico para a equipe e o app

Repositório básico

Um repositório fundamental que contém os principais componentes central, como pastas ou IAM da organização. Esse repositório pode ser gerenciado pela equipe central do Cloud.

  • Nesse repositório, inclua um diretório para cada componente principal (por exemplo, pastas, redes e assim por diante).
  • Nos diretórios de componentes, inclua uma pasta separada para cada ambiente (refletindo a orientação da estrutura de diretórios mencionada anteriormente).

Estrutura do repositório básico

Repositórios específicos de aplicativos e equipes

Implante repositórios de aplicativos específicos e de equipe separadamente para que cada equipe gerencie a configuração exclusiva do Terraform específica para cada aplicativo.

Estrutura de repositório específica de aplicativos e equipes

A seguir