Passer au contenu principal
Déployer Devin à l’échelle d’une entreprise implique de gérer des environnements pour des dizaines d’organisations et des centaines de dépôts. Cette page présente les approches qui fonctionnent bien à grande échelle, ainsi que les erreurs à éviter.

​
Organiser les blueprints entre les différents niveaux

La question que les administrateurs Enterprise posent le plus souvent : « Où faut-il placer cette configuration ? » La réponse est simple : placez-la par défaut dans le blueprint Enterprise. Le blueprint Enterprise est l’endroit approprié pour tout ce qui s’applique (ou pourrait s’appliquer) à toutes les organisations. Cela inclut les environnements d’exécution, les outils de sécurité, les certificats d’entreprise, les CLI internes, la configuration du proxy et l’authentification partagée au registre. Il est tout à fait acceptable d’y installer plusieurs langages et outils, même si toutes les orgs ne les utilisent pas.
Blueprint tierQuand l’utiliserExemples
EnterprisePar défaut pour toute configuration partagéePython 3.12, Node 20, Go 1.22, Rust, scanners de sécurité, certificats d’autorité de certification d’entreprise, CLI internes, configuration du proxy, jetons de registre partagés
OrganizationUniquement lorsqu’un élément ne doit pas s’appliquer à toutes les orgsUn registre privé propre à une équipe, des outils réservés à certaines équipes, une configuration de linting spécifique à l’org
RepositoryConfiguration par repo qui s’exécute dans le répertoire du reponpm install, uv sync, éléments de Knowledge spécifiques au repo, fichiers .envrc au niveau du repo
La seule raison d’utiliser un blueprint d’org au lieu du blueprint Enterprise est lorsque vous ne voulez explicitement pas qu’un élément s’applique à toutes les organisations. Par exemple, si une équipe utilise un registre npm privé auquel les autres équipes ne doivent pas avoir accès, cette configuration de registre doit être placée dans le blueprint d’org de cette équipe, et non dans le blueprint Enterprise. Si quelque chose s’applique à toutes les orgs, cela va dans Enterprise. Si c’est spécifique au repo, cela va dans le blueprint du repo. Le niveau org n’existe que pour les exceptions intermédiaires.
Ne placez pas de commandes spécifiques au repo (comme npm install) dans le blueprint Enterprise ou le blueprint d’org. Ces niveaux s’exécutent dans le répertoire personnel, et non dans le répertoire du repo, donc les commandes spécifiques au repo échoueront ou s’installeront au mauvais endroit.

​
Utilisez les éléments de Knowledge au bon niveau

Les éléments de Knowledge se cumulent d’un niveau à l’autre. Devin les prend tous en compte. Servez-vous-en pour structurer les consignes :
  • Knowledge d’entreprise : normes de code à l’échelle de l’entreprise, exigences de revue de sécurité, liens vers la documentation interne.
  • Knowledge de l’organisation : conventions de la Team, modèles d’utilisation des bibliothèques partagées, procédures de déploiement propres à l’équipe.
  • Knowledge du repo : commandes de lint, de test et de build pour le projet spécifique.

​
Gestion des secrets à grande échelle

Les secrets se propagent selon la même hiérarchie de niveaux que les blueprints, les secrets les plus spécifiques prévalant.

​
Où définir les secrets

Secret scopeÀ utiliser pourExemples
EntrepriseIdentifiants partagés entre toutes les organisationsTokens de registre internes, authentification au proxy d’entreprise, clés d’API partagées pour les services internes
OrganisationIdentifiants propres à la TeamClés de déploiement de la Team, tokens d’API pour les services de la Team, authentification au registre propre à la Team
DépôtIdentifiants propres au dépôtClés d’API par projet, comptes de service propres au projet
Placez les secrets au niveau le plus élevé pertinent. Si chaque organisation doit accéder au registre npm interne, définissez le token une seule fois comme secret d’entreprise. Ne le dupliquez pas dans 50 configurations d’organisation.

​
Hygiène des secrets

  • Ne mettez jamais de secrets dans le YAML. Utilisez toujours l’interface de gestion des secrets. Les secrets placés dans le YAML se retrouvent dans les logs, les artefacts de build et les journaux d’audit.
  • Renouvelez régulièrement les secrets. Lorsque vous renouvelez un secret dans l’interface, la nouvelle valeur prend effet au build suivant. Aucune modification du blueprint n’est nécessaire.
  • Utilisez des noms explicites. INTERNAL_NPM_TOKEN est préférable à TOKEN_1. Les autres administrateurs (et vous-même plus tard) doivent comprendre à quoi sert chaque secret.
  • Auditez l’utilisation des secrets. Passez régulièrement en revue les secrets existants et vérifiez s’ils sont toujours nécessaires. Supprimez les secrets inutilisés pour réduire votre surface d’attaque.
Si un secret d’org et un secret Enterprise portent le même nom, le secret d’org l’emporte. Il en va de même pour les secrets de repo qui remplacent les secrets d’org. Utilisez ce mécanisme en connaissance de cause. Par exemple, une org peut remplacer le token de registre Enterprise par un token spécifique à une équipe disposant d’autorisations différentes.

​
Suivi de l’état des builds

À l’échelle d’une grande entreprise, les échecs de build sont inévitables. L’essentiel est de les détecter tôt et de les résoudre rapidement.

​
Établir un rythme de revue

Vérifiez chaque semaine l’état des builds dans l’ensemble des orgs. Repérez notamment :
  • Builds en échec : échecs critiques dans des blueprints Enterprise ou d’org qui bloquent tous les repos.
  • Builds partiels : certains repos échouent. C’est souvent le signe d’un problème de dépendance ou d’un blueprint obsolète.
  • Builds obsolètes : orgs dont le build le plus récent est anormalement ancien, ce qui peut indiquer une file d’attente des builds bloquée.

​
Réagir aux échecs du blueprint Enterprise

Si une modification du blueprint Enterprise provoque des échecs généralisés :
  1. Évaluez l’ampleur de l’impact. Vérifiez combien d’orgs sont affectées sur la page Rollout.
  2. Rétablissez le blueprint Enterprise au dernier blueprint connu comme fonctionnel. Enregistrez immédiatement. Cela active des rebuilds sur toutes les orgs affectées.
  3. Isolez l’investigation. Testez vos modifications sur une seule org pilote avant de les redéployer.
Ne laissez pas un blueprint Enterprise défectueux en place pendant le débogage. Chaque minute où il reste défectueux, des orgs continuent d’avoir des builds en échec.

​
Les builds partiels sont un indicateur

Un build partiel signifie que certains repos d’une org ont réussi, tandis que d’autres ont échoué. C’est généralement dû à :
  • Un problème de dépendance spécifique à un repo (fichier de verrouillage corrompu, package supprimé)
  • Une bibliothèque système manquante dont un seul projet a besoin
  • Un blueprint obsolète qui n’a pas été mis à jour pour refléter les modifications du repo
Les builds partiels produisent tout de même des snapshots exploitables pour les repos qui ont réussi. Mais examinez les échecs. Ils ont tendance à s’accumuler s’ils sont ignorés.

​
Quand épingler des builds

L’épinglage des builds fige l’environnement d’une org sur un snapshot spécifique. Utilisez-le avec discernement.

​
Bonnes raisons d’épingler

  • Livraison critique en cours. Vous avez besoin d’un environnement stable, dont le bon fonctionnement est confirmé, pour les 48 prochaines heures pendant le déploiement d’une version.
  • Débogage actif. Vous enquêtez sur un problème de build et ne voulez pas que des mises à jour automatiques modifient votre environnement.
  • Retour à la version précédente. Un nouveau build a introduit une régression et vous devez revenir immédiatement à la version précédente le temps de corriger le blueprint.

​
Mauvaises raisons d’épingler

  • Éviter de corriger le problème. Si un build est cassé, corrigez le blueprint. L’épinglage masque le problème et, comme il n’expire pas automatiquement, un épinglage oublié peut vous laisser sur un environnement obsolète indéfiniment.
  • « Au cas où. » Les mises à jour automatiques gardent les dépendances à jour et détectent les problèmes rapidement. Les désactiver sans raison spécifique ne fait que retarder les problèmes.
Vous ne pouvez épingler que des builds de moins de 7 jours. Une fois un build épinglé, l’épinglage reste actif jusqu’à sa suppression manuelle. Il n’expire pas. Un épinglage oublié signifie que votre Team tourne sur un snapshot de plus en plus obsolète.

​
Migration de votre entreprise

Pour le playbook de migration progressive recommandé (des tests initiaux au déploiement complet), consultez Migration de votre entreprise.

​
Modèles d’architecture courants

Différentes structures d’entreprise appellent différentes approches d’architecture.

​
Organisations en monorepo

Configuration : une org avec un seul grand dépôt contenant plusieurs projets. Approche : le blueprint Enterprise gère tout l’outillage partagé (runtimes, outils CLI globaux, registres). Placez la configuration spécifique à chaque projet (npm install dans le répertoire frontend, uv sync dans le répertoire backend) dans le blueprint du repo. Le blueprint de l’org n’est nécessaire que si cette org a des outils ou une configuration qui ne doivent pas s’appliquer aux autres orgs. 
# Blueprint de repo pour un monorepo
maintenance:
  - name: "Frontend dependencies"
    run: (cd frontend && npm install)

  - name: "Backend dependencies"
    run: (cd backend && uv sync)

knowledge:
  - name: lint
    contents: |
      Frontend: cd frontend && npm run lint
      Backend: cd backend && uv run ruff check .

​
Organisations multi-repos

Configuration : une org avec plusieurs dépôts associés (p. ex., une équipe de microservices). Approche : placez les outils partagés et la configuration du registre dans le blueprint de l’org. Chaque repo a son propre blueprint, qui ne contient que maintenance et knowledge. Cela évite de dupliquer les commandes de configuration d’un repo à l’autre.

​
Org d’infrastructure partagée

Configuration : une org de plateforme ou DevOps qui fournit des services partagés utilisés par d’autres équipes. Approche : le blueprint Enterprise couvre la base commune. Le blueprint de l’org d’infrastructure partagée installe les outils spécifiques à la plateforme (Terraform, kubectl, CLI cloud) dont ses repos ont besoin. Les autres orgs n’ont pas ces outils. Elles reçoivent uniquement ce qui se trouve dans le blueprint Enterprise, ainsi que leur propre configuration d’org.

​
Orgs de projet isolées

Configuration : équipes indépendantes sans outils partagés au-delà de l’essentiel. Approche : le blueprint Enterprise continue de gérer le socle commun : tous vos environnements d’exécution standard, vos outils de sécurité et votre infrastructure d’entreprise. Chaque org n’utilise son propre blueprint que pour les outils ou la configuration réellement propres à cette équipe et qui ne doivent pas être partagés avec les autres. Les blueprints de repo gèrent la configuration propre à chaque projet.
En cas de doute, placez-le dans le blueprint Enterprise. Si une org a une raison spécifique d’exclure quelque chose (versions d’outils incompatibles, accès restreint), elle peut le remplacer au niveau de l’org. Il est plus simple d’avoir un socle d’entreprise complet que de dupliquer la configuration dans de nombreux blueprints d’org.