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 à 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. 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 repos 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 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 :

​
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 repo 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 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 d’entreprise, org et dépôt. 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 à Settings > environnement de base de Devin et ouvrez l’onglet Secrets 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.

​
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.