Passer au contenu principal
Prérequis : Ce guide suppose une bonne connaissance de la configuration déclarative des environnements. Consultez Configuration déclarative des environnements pour une introduction.
Avant de configurer des environnements, assurez-vous que votre fournisseur SCM est connecté (Enterprise Settings > Integrations) et que chaque organisation s’est vu accorder l’accès à ses dépôts (Enterprise Settings > Repository Permissions). Les organisations ne peuvent pas ajouter de dépôts à leur environnement tant que cet accès n’a pas été explicitement accordé. Consultez Intégrations Git pour plus de détails.
Les administrateurs Enterprise peuvent définir un environnement de base qui s’applique à chaque organisation de l’entreprise. Cela vous donne un contrôle centralisé sur les outils, les environnements d’exécution et l’infrastructure de sécurité utilisés par Devin, tout en laissant chaque organisation et dépôt personnaliser sa propre configuration.

​
La hiérarchie des blueprints

La configuration de l’environnement de Devin suit une hiérarchie à trois niveaux. Chaque niveau repose sur le précédent : 
+-----------------------------------------+
|  Enterprise Blueprint                   |
|  Python 3.12, Node 20, outils de sécurité |
+-----------------------------------------+
|  Organization Blueprint                 |
|  registre npm privé, linting d'équipe   |
+-----------------------------------------+
|  Repository Blueprint                   |
|  npm install, config spécifique au projet |
+-----------------------------------------+
NiveauQui le gèrePérimètre
EnterpriseAdministrateurs EnterpriseToutes les organisations, tous les dépôts
OrganisationAdministrateurs d’orgTous les dépôts de l’org
DépôtAdministrateurs d’org ou configuration du dépôtUn seul dépôt
La relation est additive : les blueprints d’org et de dépôt s’ajoutent au blueprint Enterprise, ils ne le remplacent pas. À chaque build, le blueprint Enterprise s’exécute en premier et établit la base de référence. Ensuite, le blueprint d’org s’exécute et ajoute la configuration spécifique à l’équipe. Enfin, le blueprint de chaque dépôt s’exécute avec une configuration propre au projet. Voir Périmètre des blueprints pour comprendre comment les blueprints d’org et de dépôt s’articulent.

​
Configuration du blueprint d’entreprise

Accédez à Settings > environnement de base de Devin pour définir le blueprint d’entreprise. Il utilise le même format que les blueprints d’org et de repo, avec les sections initialize, maintenance et knowledge. Le blueprint d’entreprise s’exécute en premier lors de chaque build, avant les blueprints d’org et de repo. Cela signifie que les outils et environnements d’exécution installés au niveau de l’entreprise sont disponibles pour tous les blueprints suivants.

​
Que mettre dans le blueprint d’entreprise

Le blueprint d’entreprise regroupe les outils et la configuration dont chaque organisation a besoin. Cas d’usage courants :

​
Environnements d’exécution standard

Épinglez les versions des langages à l’échelle de l’entreprise afin que chaque équipe utilise la même chaîne d’outils : 
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"

​
Outils de sécurité et vérification de conformité

Installez les outils d’analyse et d’audit que chaque projet doit utiliser : 
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

​
Outils et utilitaires CLI internes

Distribuez des outils propres à l’entreprise sur tous les environnements : 
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

​
Configuration partagée du registre de packages

Configurez les gestionnaires de paquets pour utiliser vos registres internes : 
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/

​
Configuration du proxy d’entreprise et des certificats

Installez les certificats d’autorité de certification d’entreprise et configurez les paramètres du 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

​
Comment les niveaux interagissent

Pendant un build, les étapes de chaque niveau s’exécutent dans un ordre fixe. Le résultat des niveaux précédents est disponible pour les suivants. Les outils installés au niveau Enterprise sont prêts à être utilisés dans les blueprints d’org et de repo sans réinstallation. Un build crée un nouveau snapshot dans cet ordre : 
1. Blueprint Enterprise (s'exécute dans ~) :
   a. initialize
   b. maintenance
2. Blueprint d'organisation (s'exécute dans ~) :
   a. initialize
   b. maintenance
3. Cloner tous les dépôts (jusqu'à 10 simultanément)
4. Pour chaque dépôt configuré, dans l'ordre indiqué dans les Settings
   (s'exécute dans ~/repos/<repo-name>) :
   a. initialize
   b. maintenance
5. Vérification de l'état, puis le snapshot est sauvegardé
Les niveaux sont cumulatifs : les blueprints de repo peuvent utiliser des outils installés par le blueprint d’org ou d’entreprise. Les niveaux inférieurs ne peuvent pas remplacer ce qu’un niveau supérieur a mis en place. Les builds prennent généralement de 5 à 15 minutes. Les commandes individuelles sont interrompues après 1 heure. Les éléments knowledge de tous les niveaux sont regroupés et mis à la disposition de Devin. Si plusieurs niveaux définissent un élément de Knowledge portant le même nom, ils sont tous inclus. Aucun n’écrase les autres.

​
Secrets Enterprise

Les administrateurs Enterprise peuvent définir des secrets au niveau Enterprise. Ces secrets sont disponibles sous forme de variables d’environnement pendant chaque build et chaque session, dans toutes les organisations, aussi bien dans les étapes de blueprint Enterprise, org et repo. Utilisez les secrets Enterprise pour les identifiants partagés à l’échelle de toute l’entreprise :
  • Jetons du registre de packages interne
  • Authentification du proxy d’entreprise
  • Clés API partagées pour les services internes
  • Clés de licence pour les outils d’entreprise
Les secrets Enterprise sont gérés sur la page Configuration à l’échelle de l’entreprise, la même page où vous configurez le blueprint Enterprise. Accédez à Settings > environnement de base de Devin pour gérer à la fois le blueprint et les secrets au même endroit.
La gestion des secrets Enterprise nécessite l’autorisation ManageAccountResources.
Si un secret d’org porte le même nom qu’un secret Enterprise, le secret d’org est prioritaire. Cela permet à chaque organisation de remplacer les valeurs par défaut à l’échelle de l’entreprise lorsque nécessaire.

​
Reconstructions à l’échelle de l’entreprise

Les administrateurs Enterprise peuvent déclencher une reconstruction qui se répercute sur toutes les organisations. Cela est utile lorsque :
  • Vous mettez à jour le blueprint Enterprise (par ex., pour faire passer Python de 3.11 à 3.12)
  • Vous effectuez une rotation d’un secret Enterprise
  • Vous devez actualiser tous les environnements après un correctif de sécurité
Déclenchez une reconstruction à l’échelle de l’entreprise depuis Settings > l’environnement de base de Devin. Le build de chaque organisation s’exécute avec le blueprint Enterprise mis à jour, puis avec ses propres blueprints d’organisation et de repo.
Les reconstructions à l’échelle de l’entreprise respectent la file d’attente de build de chaque organisation. Si une organisation a déjà un build en cours, la reconstruction déclenchée à l’échelle de l’entreprise est placée dans la file d’attente derrière celui-ci. Si un build est déjà en file d’attente, il est annulé et remplacé par celui déclenché à l’échelle de l’entreprise.

​
Gérer le déploiement progressif à l’échelle des organisations

L’administrateur Enterprise détermine quelles organisations utilisent la configuration déclarative plutôt que la configuration classique de l’environnement. La page Rollout offre une vue d’ensemble de l’état d’adoption dans toutes les organisations et permet de les migrer progressivement. Consultez Migrer votre Enterprise pour une présentation détaillée des états du déploiement progressif, des dérogations par organisation et d’un guide de migration par phases.