Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://docs.devin.ai/llms.txt

Use this file to discover all available pages before exploring further.

Faire passer une entreprise d’une configuration d’environnement classique à une configuration déclarative constitue un changement important. La page Rollout donne aux administrateurs Enterprise un contrôle fin sur cette transition. Vous pouvez activer les blueprints pour quelques organisations pilotes, étendre le déploiement à votre rythme et revenir en arrière immédiatement en cas de problème.

​
États du déploiement d’entreprise

La page Rollout présente un sélecteur Rollout mode qui contrôle la façon dont les blueprints sont mis à la disposition des organisations. Il existe trois modes, ainsi qu’un état initial avant l’activation des environnements déclaratifs :
ÉtatSignificationEffet sur les organisations
Non activéLes environnements déclaratifs n’ont pas encore été activés pour l’entrepriseAucune organisation ne voit les pages d’environnement. Toutes les organisations utilisent la configuration classique. Contactez votre administrateur Cognition pour l’activer.
TestingSeules les organisations activées manuellement utilisent les environnements déclaratifsUn administrateur Enterprise active les organisations individuellement depuis la page Rollout. Toutes les autres organisations restent sur la configuration classique et ne voient aucun changement.
AvailableLes administrateurs d’organisation voient un prompt de migration et peuvent activer la migration eux-mêmesLes administrateurs d’organisation qui utilisent la configuration classique voient un encart de migration sur leur page Machine Configuration. Ils peuvent migrer en libre-service, sans intervention d’un administrateur Enterprise.
Enabled by defaultLes nouvelles organisations utilisent les environnements déclaratifs par défautToutes les nouvelles organisations démarrent avec des blueprints. Les organisations existantes qui étaient sur la configuration classique avec des repos reçoivent automatiquement des dérogations classiques.
La progression est la suivante : Testing → Available → Enabled by default. Vous pouvez passer librement de Testing à Available à l’aide de la liste déroulante Rollout mode. En revanche, Enabled by default est une action permanente qui ne peut pas être annulée sans l’intervention d’un administrateur Cognition.
Enabled by default est permanent. Une fois ce mode activé, il n’est pas possible de revenir à Testing ou Available sans contacter votre administrateur Cognition. Assurez-vous que votre blueprint d’entreprise est entièrement validé et que la plupart des organisations utilisent déjà des blueprints avant d’activer ce mode.

​
Détails de Testing mode

Dans l’état Testing mode, les organisations qui n’ont pas activé cette option continuent d’utiliser la configuration classique et ne constatent aucun changement dans leur expérience. L’administrateur Enterprise peut activer des orgs individuellement depuis la page Rollout. Seules ces orgs passent à la configuration déclarative. Il s’agit du mode de référence lorsque les environnements déclaratifs sont activés pour la première fois pour une entreprise.

​
Détails du mode Available

Le mode Available ajoute une incitation à la migration : les administrateurs d’org qui utilisent encore la configuration classique voient un encart sur leur page Machine Configuration les encourageant à migrer vers la configuration déclarative. Cela ne modifie pas leur configuration et ne leur donne pas accès à l’ensemble des pages de configuration de l’environnement. Cela leur indique simplement que les blueprints sont disponibles et leur offre un moyen en libre-service d’activer cette option. Cela permet de sensibiliser les équipes et de laisser les administrateurs d’org migrer à leur propre rythme.

​
Dérogations par org

Les administrateurs Enterprise peuvent remplacer l’état de déploiement pour des organisations spécifiques directement dans le tableau par org de la page Rollout :
  • Avec le mode Testing ou Available : activez les blueprints pour des orgs spécifiques. Ces orgs passent immédiatement de la configuration classique à la configuration déclarative.
  • Avec le mode Enabled by default : désactivez les blueprints pour des orgs spécifiques afin de revenir à la configuration classique. Ces orgs continuent d’utiliser leur configuration classique.
Les dérogations sont persistantes. Elles restent en place malgré les changements de mode. Si vous activez les blueprints pour un org pendant le mode Testing, il reste sur les blueprints lorsque vous passez à Available ou Enabled by default.

​
Dérogations automatiques pour la configuration classique

Lors de l’activation de Enabled by default, un mécanisme de sécurité évite toute perturbation : toute organisation qui utilise actuellement la configuration classique et qui a des dépôts configurés reçoit automatiquement une dérogation explicite pour la configuration classique. Cela signifie que cette transition ne change rien pour les organisations qui utilisent activement la configuration classique. Elles continuent donc en l’état jusqu’à ce que vous les migriez explicitement. Les organisations sans dépôts (ou celles qui utilisent déjà les blueprints) ne sont pas affectées par cette protection. La meilleure approche consiste à mettre en place et à valider votre configuration de manière isolée avant de la rendre accessible aux administrateurs de l’organisation. N’effectuez pas une migration d’un seul coup. Commencez de manière contrôlée, vérifiez, puis élargissez progressivement.

​
Phase 1 : créer et vérifier de manière isolée (Testing)

Commencez avec l’entreprise en mode Testing. Les orgs ne peuvent pas l’activer elles-mêmes : vous gardez donc un contrôle total.
  1. Activez les environnements déclaratifs pour l’entreprise. Votre administrateur Cognition active la fonctionnalité, ce qui place l’entreprise en mode Testing.
  2. Créez une org de test dédiée pour tester la configuration de l’environnement. Cette org sert uniquement à valider vos blueprints.
  3. Activez la configuration déclarative uniquement pour cette org de test (via une dérogation par org sur la page Rollout).
  4. Configurez le blueprint de votre entreprise : installez tous les environnements d’exécution partagés, les outils de sécurité, les certificats d’entreprise, les CLI internes, les paramètres de proxy et l’authentification au registre. Il s’agit de votre couche de base, dont chaque org héritera.
  5. Configurez un blueprint d’org pour l’org de test avec les outils au niveau de l’org ou la configuration du registre nécessaires.
  6. Ajoutez des blueprints de dépôt pour un ensemble représentatif de dépôts. Choisissez des repos qui couvrent vos stacks technologiques les plus courantes.
  7. Vérifiez de bout en bout : démarrez des sessions Devin sur ces repos et confirmez que tout fonctionne. Les repos doivent être clonés, les dépendances installées, les commandes de lint/test/build correctement exécutées, et tous les outils doivent être aux versions attendues.
Ne vous contentez pas de vérifier que les builds réussissent. Un build au vert ne signifie pas toujours que l’environnement fonctionne. Une entrée PATH manquante, une mauvaise version d’outil ou une authentification au registre absente peuvent passer inaperçues. Vérifiez toujours en lançant une véritable session Devin.

​
Phase 2 : Activer l’opt-in pour les administrateurs d’org (Disponible)

Une fois que vous avez confirmé que votre pile de blueprints enterprise → org → repo s’articule correctement et produit des environnements fonctionnels :
  1. Communiquez en interne aux administrateurs d’org que la configuration déclarative est disponible et prête à l’emploi.
  2. Passez au mode Available : modifiez le menu déroulant Rollout mode de Testing à Available. Les administrateurs d’org utilisant la configuration classique voient désormais un message les encourageant à migrer.
  3. Les administrateurs d’org peuvent maintenant migrer leurs propres organisations. Comme le blueprint enterprise fournit déjà la couche de base (environnements d’exécution, outils, certificats, registres), les administrateurs d’org n’ont plus qu’à configurer ce qui est spécifique à leur équipe et à leurs dépôts.
Chaque administrateur d’org peut utiliser l’assistant de migration pour simplifier cette étape. Devin peut examiner le snapshot existant de l’org et générer automatiquement une configuration de blueprint équivalente. Consultez Migrer vers la configuration déclarative pour suivre la procédure pas à pas. Constituez une bibliothèque de blueprints modèles pour vos piles technologiques les plus courantes (Node.js, Python, Java, Go, monorepos multilingues) et partagez-les en interne afin que les administrateurs d’org ne partent pas de zéro. La Bibliothèque de modèles constitue une bonne base.

​
Phase 3 : Étendre et nettoyer (Enabled by default)

  1. Activez Enabled by default lorsque la plupart des organisations utilisent les blueprints. Il s’agit d’une action permanente — les organisations qui étaient sur la configuration classique avec des repos reçoivent automatiquement des dérogations classiques ; rien ne change donc pour elles.
  2. Les nouvelles organisations créées à partir de ce moment utilisent les blueprints par défaut.
  3. Surveillez la page Rollout pour vérifier l’état des builds dans toutes les organisations. Filtrez par “Classic” pour voir qui n’a pas encore migré.
  4. Travaillez avec les administrateurs des organisations restantes pour migrer les retardataires. L’assistant de migration simplifie cette opération.
  5. Supprimez les dérogations classiques une fois que toutes les organisations ont été validées sur les blueprints.
La configuration classique est toujours conservée. Rien n’est supprimé lorsqu’une organisation passe aux blueprints. En cas de problème, les administrateurs Enterprise peuvent rétablir n’importe quelle organisation sur la configuration classique depuis la page Rollout à l’aide de dérogations par org.

​
Stratégie de migration accélérée

Pour les entreprises qui souhaitent avancer rapidement, voici une approche qui minimise la charge de migration pour chaque organisation :
  1. Commencez en mode Testing (afin que chaque organisation puisse être activée individuellement).
  2. Configurez d’abord le blueprint d’entreprise. Demandez aux admins de configurer le blueprint d’entreprise avec les runtimes, outils, certificats et la configuration du registre partagés. C’est la couche de base dont hériteront toutes les organisations.
  3. Passez en mode Available. Cela active l’invite à la migration, afin que les admins d’organisation voient un encadré sur leur page Machine Configuration et puissent lancer eux-mêmes la migration.
  4. Diffusez largement la documentation via les canaux internes existants (Slack, e-mail, wiki) et encouragez les admins d’organisation à s’inscrire d’eux-mêmes. L’assistant de migration leur permet d’effectuer cette opération en libre-service.
  5. Activez automatiquement les organisations pour lesquelles 0 dépôt est actuellement configuré. Ces organisations n’ont rien à migrer — il n’y a donc aucun risque à les faire passer aux blueprints, puisqu’elles n’ont pas de configuration classique existante à conserver.
  6. Migrez progressivement les organisations restantes, une par une. Une fois le blueprint d’entreprise configuré, chaque migration d’organisation consiste simplement à ajouter par-dessus une configuration spécifique à l’organisation et au dépôt. C’est bien plus simple qu’une migration depuis zéro.
  7. Activez Enabled by default une fois que la plupart des organisations ont migré. Les nouvelles organisations créées ensuite démarrent avec les blueprints activés.
Cette approche consiste d’abord à configurer le blueprint d’entreprise (le travail le plus rentable), puis à laisser chaque organisation migrer à son propre rythme avec un effort minimal.

​
Retour arrière

Tout ne se passe pas toujours sans accroc. Le système de déploiement prend en charge le retour arrière à tous les niveaux.

​
Retour arrière par org

Les administrateurs Enterprise peuvent faire revenir n’importe quelle org à la configuration classique depuis la page Rollout :
  • L’org revient immédiatement à son snapshot de configuration classique.
  • La configuration classique est conservée. Rien n’est perdu lorsqu’une org passe aux blueprints, donc revenir en arrière est sans risque.
  • Les sessions actives ne sont pas affectées. Le changement prend effet à la session suivante.

​
Retour en arrière du mode

Les administrateurs Enterprise peuvent basculer librement entre Testing et Available à l’aide du menu déroulant du Rollout mode. C’est utile si vous souhaitez mettre en pause la migration en libre-service pendant que vous examinez un problème.
Enabled by default ne peut pas être annulé par l’administrateur Enterprise. Si vous devez revenir en arrière depuis Enabled by default, contactez votre administrateur Cognition. Les dérogations par organisation peuvent toujours être utilisées pour ramener des organisations individuelles à la configuration classique à tout moment.
Le retour en arrière ne supprime ni les blueprints ni les configurations classiques. Les deux sont conservés, quel que soit le mode actif, vous pouvez donc passer de Testing à Available et inversement sans perdre votre travail.

​
Suivi de l’état du déploiement

La page Rollout fournit un tableau de bord pour suivre la progression de la migration dans votre entreprise.

​
Ligne des KPI

En haut de la page, des métriques de synthèse vous donnent un aperçu rapide de l’état du déploiement :
  • Organisations utilisant des blueprints : nombre d’organisations utilisant actuellement des blueprints
  • Pourcentage de déploiement : pourcentage d’orgs utilisant des blueprints par rapport au total
  • Santé des builds : état global des builds pour l’ensemble des organisations utilisant des blueprints

​
Tableau par organisation

Sous les KPI, un tableau détaillé affiche chaque organisation :
ColonneDescription
OrganisationNom de l’org
ÉtatMode actuel : Blueprints ou Classic
DérogationIndique si l’état de l’org est une dérogation explicite ou la valeur par défaut au niveau de l’entreprise
Repos ClassicNombre de repos avec une configuration Classic
Repos BlueprintsNombre de repos avec des blueprints
Dernier buildStatut du build le plus récent (réussi, partiel, échoué, etc.)

​
Filtrage

Filtrez le tableau par :
  • Tous : toutes les organisations de l’entreprise
  • Blueprints : organisations utilisant actuellement Blueprints
  • Classic : organisations utilisant actuellement la configuration classique
  • Dérogations : organisations avec une dérogation explicite de l’état (dans un sens comme dans l’autre)

​
Sécurité des accès concurrents

Les transitions d’état sont protégées contre les modifications simultanées. Si un autre administrateur modifie l’état de l’entreprise entre le moment où vous avez chargé la page et celui où vous soumettez votre modification, la requête est rejetée avec une erreur de conflit. Cela évite les écrasements accidentels lorsque plusieurs administrateurs de l’entreprise agissent en même temps. Si votre modification est rejetée, actualisez la page pour voir l’état actuel et soumettez-la à nouveau si cela reste pertinent.

​
Journalisation d’audit

Tous les changements d’état du déploiement progressif sont consignés dans les journaux d’audit :
  • Modifications du mode Enterprise (Testing → Available, activation de Enabled by default, etc.)
  • Modifications des dérogations par org (org activée, org désactivée, dérogation supprimée)
  • Quel admin a effectué la modification, et à quel moment
Ces logs sont disponibles via l’interface standard des journaux d’audit de votre Enterprise.