> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Visão geral do ambiente Enterprise

> Gerenciamento de ambientes em todo o Enterprise: hierarquia de blueprints, configuração de blueprint do Enterprise, segredos e rebuilds em todo o Enterprise.

<Info>
  **Pré-requisitos:** Este guia pressupõe familiaridade com a configuração declarativa de ambientes. Consulte [Configuração declarativa de ambiente](/pt-BR/onboard-devin/environment/blueprints) para uma introdução.
</Info>

<Warning>
  **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](/pt-BR/enterprise/integrations/git-integrations) para mais detalhes.
</Warning>

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.

<div id="the-blueprint-hierarchy">
  ## A hierarquia do blueprint
</div>

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ível           | Quem gerencia                                        | Escopo                                       |
| --------------- | ---------------------------------------------------- | -------------------------------------------- |
| **Enterprise**  | admins do Enterprise                                 | Todas as organizações, todos os repositórios |
| **Organização** | admins da organização                                | Todos os repositórios da organização         |
| **Repositório** | admins da organização ou configuração do repositório | Um ú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](/pt-BR/onboard-devin/environment/blueprints#blueprint-scope) para entender como os blueprints da organização e do repositório se relacionam.

<div id="configuring-the-enterprise-blueprint">
  ## Configurando o blueprint Enterprise
</div>

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`. Os blueprints Enterprise e de org também oferecem suporte a uma seção [`post-build`](/pt-BR/onboard-devin/environment/blueprint-reference#post-build) para comandos executados após todos os repos serem clonados e configurados.

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.

<div id="what-to-put-in-the-enterprise-blueprint">
  ## O que incluir no blueprint Enterprise
</div>

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

<div id="standard-language-runtimes">
  ### Runtime padrão para linguagens
</div>

Fixe versões de linguagens em toda a organização para que cada equipe trabalhe com o mesmo conjunto de ferramentas:

```yaml theme={null}
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"
```

<div id="security-tools-and-compliance-scanning">
  ### Ferramentas de segurança e varredura de conformidade
</div>

Instale ferramentas de varredura e de auditoria que todo projeto deve usar:

```yaml theme={null}
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
```

<div id="internal-cli-tools-and-utilities">
  ### Ferramentas e utilitários internos de linha de comando
</div>

Distribua ferramentas próprias da empresa para cada ambiente:

```yaml theme={null}
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
```

<div id="shared-package-registry-configuration">
  ### Configuração compartilhada do registro de pacotes
</div>

Configure os gerenciadores de pacotes para usar seus registros internos:

```yaml theme={null}
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/
```

<div id="corporate-proxy-and-certificate-setup">
  ### Configuração de proxy e certificados corporativos
</div>

Instale os certificados de CA corporativa e configure o proxy:

```yaml theme={null}
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
```

<div id="how-tiers-interact">
  ## Como os níveis interagem
</div>

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. post-build (org- and enterprise-level; runs in ~)
6. Health check, then snapshot is saved
```

As etapas de `post-build` são executadas depois que todos os repos forem clonados e configurados, para que possam validar o ambiente completamente montado. Um código de saída diferente de zero em uma etapa de `post-build` faz a build falhar, e nenhum snapshot é gerado. Consulte [`post-build`](/pt-BR/onboard-devin/environment/blueprint-reference#post-build) na Referência de blueprints.

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.

<div id="enterprise-secrets">
  ## Segredos do Enterprise
</div>

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 aba **Secrets** dentro do editor de blueprint do Enterprise. Acesse **Configurações > Ambiente base do Devin** e mude para a aba **Secrets** para gerenciar segredos em todo o Enterprise junto com a configuração do seu blueprint.

<Info>
  Gerenciar segredos do Enterprise requer a permissão **ManageAccountResources**.
</Info>

<Warning>
  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.
</Warning>

<div id="enterprise-wide-rebuilds">
  ## Rebuilds em todo o Enterprise
</div>

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.

<Info>
  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.
</Info>

<div id="managing-rollout-across-organizations">
  ## Gerenciando o rollout entre organizações
</div>

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](/pt-BR/enterprise/environment-management/rollout) para ver uma explicação detalhada dos estados de rollout, das substituições por org e de um playbook de migração em fases.

<div id="related-pages">
  ## Páginas relacionadas
</div>

* [Migração da sua Enterprise](/pt-BR/enterprise/environment-management/rollout)
* [Boas práticas](/pt-BR/enterprise/environment-management/best-practices)
* [Referência do blueprint](/pt-BR/onboard-devin/environment/blueprint-reference)
* [Configuração declarativa de ambiente](/pt-BR/onboard-devin/environment/blueprints)