A regra prática, de antemão: blueprints de repositório instalam dependências do projeto, blueprints da organização instalam tudo o que é compartilhado por mais de um repositório, e blueprints Enterprise instalam tudo o que toda organização precisa ter. Os níveis são aditivos e são executados de cima para baixo: enterprise → organização → clonar os repositórios → repositório.
Etapa 1: um repositório
acme-web, uma aplicação em Rails com Postgres e Redis. Dois engenheiros, um repositório. Ainda não há nada para compartilhar, então tudo fica no blueprint de repositório.
Eles adicionam o repositório em Configurações > Ambiente > Blueprints > Adicionar, abrem o editor dele e escrevem:
acme-web (repository blueprint)
Dois anos depois, a ACME tem cinco repositórios:
Este é o caso interessante, porque os repositórios não são independentes: não é possível fazer nenhum trabalho útil em
acme-portal a menos que acme-devtools esteja instalado e acme-sso esteja em execução. Surgem duas perguntas.
”Um blueprint por aplicação ou apenas um para a CLI de desenvolvimento?”
- Adicione os cinco repositórios ao ambiente para que todos sejam clonados no snapshot.
- Coloque a configuração compartilhada entre repositórios uma única vez no blueprint da organização: runtimes de linguagem, Docker, nomes de host locais e credenciais para o registro interno.
- Dê a cada repositório seu próprio blueprint de repositório para suas dependências e suas entradas de
knowledge(comandos de lint, teste e inicialização).
acme-devtools: os blueprints de repositório são executados depois que todos os repositórios são clonados, mas suas etapas são executadas no diretório desse repositório, e suas entradas de knowledge são carregadas somente quando o Devin está trabalhando nesse repositório. Se acme-devtools instalasse tudo, uma sessão em acme-portal não veria nenhum dos comandos de lint e teste do portal, e uma única etapa com falha em acme-devtools deixaria os outros quatro repositórios com aparência de saudáveis, mas inutilizáveis.
O blueprint da organização
Organization-wide setup
-
initializeversusmaintenance. Docker, runtime e hostnames são configurações únicas do sistema, então pertencem ainitialize. As credenciais do registro devem ser atualizadas a cada build periódica, então pertencem amaintenance. A própria CLIacmeestá deliberadamente ausente aqui. Ela fica dentro deacme-devtools, e as etapas da organização são executadas antes de qualquer repositório ser clonado, então sua instalação vem do blueprint desse próprio repositório (mostrado abaixo). Essa instalação é executada durante a build e persiste no snapshot, de onde todos os outros repositórios podem usá-la. -
post-buildé a grande vantagem das configurações com vários repositórios. Ele é executado depois que todos os repositórios foram clonados e configurados, então é o único lugar em que você pode validar se a stack inteira sobe corretamente. Um código de saída diferente de zero faz a build falhar, então você descobre uma stack quebrada no momento da build, e não no meio da sessão. Vejapost-build. -
Os segredos pertencem à organização, não a cada repositório. Um único
ACME_REGISTRY_TOKENna aba Segredos do blueprint da organização atende aobundle installe aonpm installde todos os repositórios.
Os blueprints de repositório
acme-devtools (repository blueprint)
acme-portal (repository blueprint)
acme-web, acme-sso e acme-events seguem o mesmo padrão: uma etapa maintenance para as próprias dependências e entradas de knowledge para os próprios comandos de lint, teste e inicialização.
O Knowledge é específico de cada repositório. Com cinco repositórios configurados, uma sessão trabalhando em
acme-portal vê as entradas de Knowledge do portal, além do Knowledge da organização e do Enterprise — ela não vê as entradas de acme-web. É por isso que cada repositório merece seu próprio blueprint, mesmo quando sua seção maintenance tem apenas uma linha.Se, em vez disso, seus serviços estiverem em um monorepo
Etapa 3: várias organizações — o blueprint Enterprise
- Todo o tráfego passa por um proxy corporativo, com uma autoridade certificadora interna.
- Todos os pacotes vêm do Artifactory, nunca de registros públicos.
- Todo ambiente deve ter instaladas as ferramentas da empresa de varredura de dependências e segredos.
- Python é 3.12 e Node.js é 20 em toda a empresa, sem exceções.
Devin's base environment (enterprise blueprint)
ARTIFACTORY_TOKEN é um segredo Enterprise, definido uma única vez em Configurações > ambiente base do Devin > Segredos e disponível em todas as builds e sessões de todas as organizações. O certificado é um arquivo anexado, exposto à build como $FILE_ACME_CA_CERT.
Do que cada nível é responsável agora
O blueprint da organização Payments da Etapa 2 continua funcionando sem alterações. Ele simplesmente não precisa mais instalar Python nem configurar registros, porque o nível Enterprise já fez isso. O blueprint da organização Data instala Spark e um JDK, que Payments nunca vê. Os blueprints de repositório permanecem inalterados.
Operando
- Fazer upgrade do Python da 3.12 para a 3.13 exige editar uma única linha mais um rebuild em todo o Enterprise, que se propaga para todas as organizações.
- Quando uma equipe precisa de uma credencial diferente — por exemplo, se a organização Data tem seu próprio realm no Artifactory — essa equipe define um segredo da organização com o mesmo nome, e ele faz override do segredo do Enterprise.
- Para fazer esse rollout gradualmente entre as organizações, consulte Migrando seu Enterprise.
Decidindo onde algo deve ficar
1
Todas as organizações da empresa precisam disso?
→ Enterprise blueprint. Certificados, proxies, registros internos, runtimes obrigatórios, ferramentas de segurança e segredos válidos para toda a empresa.
2
Dois ou mais repositórios nesta organização precisam disso?
→ Blueprint da organização. Docker, CLIs de desenvolvimento compartilhadas, hostnames locais, orquestração de serviços entre repositórios e credenciais de registro. Valide a stack resultante em
post-build.3
Só este repositório precisa disso?
→ Blueprint de repositório. Instalação de dependências, migrações e as entradas de
Knowledge para seus comandos de lint, teste e inicialização.4
Isso é um fato, e não um comando para executar?
→
knowledge, no nível ao qual se aplica. Ele nunca é executado; é carregado no contexto do Devin.- Colocar tudo no blueprint de um único repositório. Os outros repositórios não recebem entradas de
Knowledge, e uma etapa com falha faz toda a configuração parecer comprometida. - Duplicar ferramentas compartilhadas em cada repositório. Quando dois repositórios instalam versões diferentes da mesma ferramenta global, a última a ser executada prevalece. Em vez disso, coloque a ferramenta no blueprint da organização.
- Pular a verificação entre repositórios. Quando seus repositórios só funcionam em conjunto,
post-buildé o único lugar que comprova isso — antes de uma sessão começar, e não durante ela.
- Configuração declarativa — ordem de build, snapshots e solução de problemas
- Referência de blueprints — todos os campos, incluindo
post-buildeclone - Biblioteca de templates — blueprints para copiar e colar por linguagem e registro
- Workspaces e monorepos — o equivalente em monorepo à Etapa 2
- Visão geral do ambiente Enterprise — Etapa 3 em todos os detalhes

