Pular para o conteúdo principal
Pré-requisitos: Este guia pressupõe familiaridade com a configuração declarativa de ambientes. Consulte Configuração declarativa de ambiente para uma introdução.
Antes de configurar ambientes, certifique-se de que seu provedor de SCM esteja conectado (Configurações do Enterprise > Integrações) e de que cada organização tenha recebido acesso aos seus repositórios (Configurações do Enterprise > Permissões de Repositório). As orgs não podem adicionar repositórios ao ambiente até que esse acesso seja concedido explicitamente. Consulte Integrações com Git para mais detalhes.
Os admins do Enterprise podem definir um ambiente base que se aplica a todas as organizações do Enterprise. Isso dá a você controle centralizado sobre as ferramentas, runtimes e a infraestrutura de segurança que o Devin usa, sem deixar de permitir que orgs e repositórios individuais personalizem sua própria configuração sobre essa base.

A hierarquia do blueprint

A configuração do ambiente do Devin segue uma hierarquia de três níveis. Cada nível se baseia no anterior:
+-----------------------------------------+
|  Enterprise Blueprint                   |
|  Python 3.12, Node 20, security tools   |
+-----------------------------------------+
|  Organization Blueprint                 |
|  private npm registry, team linting     |
+-----------------------------------------+
|  Repository Blueprint                   |
|  npm install, project-specific config   |
+-----------------------------------------+
NívelQuem gerenciaEscopo
Enterpriseadmins do EnterpriseTodas as organizações, todos os repositórios
Organizaçãoadmins da organizaçãoTodos os repositórios da organização
Repositórioadmins da organização ou configuração do repositórioUm único repositório
A relação é aditiva: os blueprints da organização e do repositório se somam ao blueprint Enterprise; eles não o substituem. Durante cada build, o blueprint Enterprise é executado primeiro, estabelecendo a base. Em seguida, o blueprint da organização é executado, adicionando configurações específicas da equipe. Por fim, o blueprint de cada repositório é executado com a configuração específica do projeto. Consulte Escopo do blueprint para entender como os blueprints da organização e do repositório se relacionam.

Configurando o blueprint Enterprise

Navegue até Configurações > ambiente base do Devin para definir o blueprint Enterprise. Ele segue o mesmo formato dos blueprints de org e repo, com as seções initialize, maintenance e knowledge. O blueprint Enterprise é executado primeiro em cada build, antes dos blueprints de org e repo. Isso significa que as ferramentas e os runtimes instalados no nível Enterprise ficam disponíveis para todos os blueprints posteriores.

O que incluir no blueprint Enterprise

O blueprint Enterprise serve para ferramentas e configurações de que toda organização precisa. Casos de uso comuns:

Runtime padrão para linguagens

Fixe versões de linguagens em toda a organização para que cada equipe trabalhe com o mesmo conjunto de ferramentas:
initialize:
  - name: "Install Python 3.12"
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

  - name: "Install Node.js 20"
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"

  - name: "Install Go 1.22"
    uses: github.com/actions/setup-go@v5
    with:
      go-version: "1.22"

Ferramentas de segurança e varredura de conformidade

Instale ferramentas de varredura e de auditoria que todo projeto deve usar:
initialize:
  - name: "Install security tools"
    run: |
      npm install -g snyk
      pip install safety bandit
      curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

Ferramentas e utilitários internos de linha de comando

Distribua ferramentas próprias da empresa para cada ambiente:
initialize:
  - name: "Install internal CLI"
    run: |
      curl -L https://internal.example.com/cli/latest/linux-amd64 \
        -o /usr/local/bin/internal-cli
      chmod +x /usr/local/bin/internal-cli

Configuração compartilhada do registro de pacotes

Configure os gerenciadores de pacotes para usar seus registros internos:
initialize:
  - name: "Configure internal registries"
    run: |
      npm config set registry https://npm.internal.example.com/
      pip config set global.index-url https://pypi.internal.example.com/simple/

Configuração de proxy e certificados corporativos

Instale os certificados de CA corporativa e configure o proxy:
initialize:
  - name: "Install corporate certificates"
    run: |
      cp "$FILE_CORPORATE_CA_CERT" /usr/local/share/ca-certificates/corporate-ca.crt
      update-ca-certificates
      echo 'export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/corporate-ca.crt' >> ~/.bashrc

Como os níveis interagem

Durante uma build, as etapas de cada nível são executadas em uma sequência fixa. O resultado dos níveis anteriores fica disponível para os seguintes. As ferramentas instaladas no nível Enterprise ficam prontas para uso nos blueprints de org e repo sem precisar ser reinstaladas. Uma build cria um novo snapshot nesta ordem:
1. Enterprise blueprint (runs in ~):
   a. initialize
   b. maintenance
2. Organization blueprint (runs in ~):
   a. initialize
   b. maintenance
3. Clone all repositories (up to 10 concurrent)
4. For each configured repo, in the order shown in Settings
   (runs in ~/repos/<repo-name>):
   a. initialize
   b. maintenance
5. Health check, then snapshot is saved
Os níveis são aditivos: blueprints de repositório podem usar ferramentas instaladas pelo blueprint da organização ou da Enterprise. Níveis inferiores não podem sobrescrever o que um nível superior configurou. Builds normalmente levam de 5 a 15 minutos. Comandos individuais atingem o tempo limite após 1 hora. Os itens de knowledge de todos os níveis são coletados e disponibilizados ao Devin. Se vários níveis definirem um item de knowledge com o mesmo nome, todos eles serão incluídos. Eles não sobrescrevem uns aos outros.

Segredos do Enterprise

Os admins do Enterprise podem definir segredos no nível Enterprise. Esses segredos ficam disponíveis como variáveis de ambiente durante cada build e cada sessão em todas as organizações, inclusive em etapas de blueprint do Enterprise, da org e do repo. Use segredos do Enterprise para credenciais compartilhadas em toda a empresa:
  • Tokens de registros de pacotes internos
  • Autenticação de proxy corporativo
  • Chaves de API compartilhadas para serviços internos
  • Chaves de licença para ferramentas Enterprise
Os segredos do Enterprise são gerenciados na página Configuração em todo o Enterprise, a mesma página em que você configura o blueprint do Enterprise. Acesse Configurações > Ambiente base do Devin para gerenciar o blueprint e os segredos em um só lugar.
Gerenciar segredos do Enterprise requer a permissão ManageAccountResources.
Se um segredo da org tiver o mesmo nome que um segredo do Enterprise, o segredo da org terá precedência. Isso permite que organizações individuais substituam os padrões definidos para todo o Enterprise quando necessário.

Rebuilds em todo o Enterprise

Os admins do Enterprise podem acionar um rebuild em cascata para todas as organizações. Isso é útil quando:
  • Você atualiza o blueprint do Enterprise (por exemplo, faz upgrade do Python da versão 3.11 para 3.12)
  • Você rotaciona um segredo do Enterprise
  • Você precisa atualizar todos os ambientes após um patch de segurança
Acione um rebuild em todo o Enterprise em Configurações > ambiente base do Devin. O build de cada organização é executado com o blueprint atualizado do Enterprise, seguido pelos blueprints da própria organização e do repositório.
Os rebuilds em todo o Enterprise respeitam a fila de builds de cada organização. Se uma organização já tiver um build em andamento, o rebuild acionado pelo Enterprise entra na fila atrás dele. Se já houver um build na fila, ele será cancelado e substituído pelo acionado pelo Enterprise.

Gerenciando o rollout entre organizações

O administrador do Enterprise controla quais organizações usam a configuração declarativa em vez da configuração clássica de ambiente. A página Rollout oferece visibilidade sobre o status de adoção em todas as orgs e permite migrar organizações de forma progressiva. Consulte Migrando seu Enterprise para ver uma explicação detalhada dos estados de rollout, das substituições por org e de um playbook de migração em fases.