Skip to main content
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 :
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 à Enterprise Settings > Environments et ouvrez l’onglet Blueprint pour définir le blueprint d’entreprise. Il utilise le même format que les blueprints d’org et de dépôt, avec les sections initialize, maintenance et knowledge. Les blueprints d’entreprise et d’org prennent également en charge une section post-build pour les commandes qui s’exécutent une fois que tous les dépôts sont clonés et configurés. Le blueprint d’entreprise s’exécute en premier lors de chaque build, avant les blueprints d’org et de dépôt. Cela signifie que les outils et environnements d’exécution installés au niveau Enterprise 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 :

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

Installez les outils d’analyse et d’audit que chaque projet doit utiliser :

​
Outils et utilitaires CLI internes

Distribuez des outils propres à l’entreprise sur tous les environnements :

​
Configuration partagée du registre de packages

Configurez les gestionnaires de paquets pour utiliser vos registres internes :

​
Configuration du proxy d’entreprise et des certificats

Installez les certificats d’autorité de certification d’entreprise et configurez les paramètres du proxy :

​
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 dépôt sans réinstallation. Un build crée un nouveau snapshot dans cet ordre :
Les étapes post-build s’exécutent une fois que chaque repo a été cloné et configuré, afin de pouvoir valider l’environnement entièrement assemblé. Un code de sortie non nul lors d’une étape post-build fait échouer le build et aucun snapshot n’est produit. Consultez post-build dans la référence Blueprint. Les niveaux sont cumulatifs : les blueprints de dépôt 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 3 heures. 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 d’entreprise, org et dépôt, sauf s’ils sont marqués Build only. 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 dans l’onglet Secrets de l’éditeur de blueprint d’entreprise. Accédez à Enterprise Settings > Environments > Blueprint et ouvrez l’onglet Secrets (lien direct) pour gérer les secrets à l’échelle de l’entreprise aux côtés de la configuration de votre blueprint.
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.

​
Enterprise secrets réservés au build

Lorsque vous ajoutez un secret Enterprise, activez Build only pour le limiter à l’environment setup. Un secret réservé au build n’est accessible qu’aux steps des blueprints enterprise et org pendant les builds du snapshot. Il est supprimé avant le clonage des repositories : les steps de repo blueprint et les steps post-build ne peuvent donc pas le lire, et il n’est jamais disponible dans les Devin sessions. Les secrets ainsi configurés affichent un badge Build only dans la liste des secrets.

​
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 d’entreprise (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 en enregistrant le blueprint d’entreprise dans Enterprise Settings > Environments > Blueprint. Le build de chaque organisation s’exécute avec le blueprint d’entreprise mis à jour, puis avec ses propres blueprints d’organisation et de dépôt.
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 dans les organisations

La page Déploiement offre une visibilité à l’échelle de l’entreprise sur l’état des environnements et la couverture des blueprints par organisation. Utilisez-la pour identifier les organisations sans blueprint ou dont les builds échouent ou sont obsolètes. Consultez État du déploiement pour découvrir le playbook d’adoption progressive des blueprints et les recommandations sur l’état des builds.