Passer au contenu principal
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 de déploiement de l’Enterprise

L’Enterprise comporte trois états de niveau supérieur qui déterminent la disponibilité des blueprints pour les organisations :
StateWhat it meansEffect on organizations
DisabledLes blueprints ne sont pas activés pour l’EnterpriseAucune organisation ne voit les pages d’environnement. Toutes les organisations utilisent la configuration classique.
Default OffLes blueprints sont disponibles, mais ne sont pas activés par défautLes organisations peuvent être activées individuellement par l’administrateur Enterprise. Les nouvelles organisations démarrent avec la configuration classique.
Default OnLes blueprints sont activés par défaut pour toutes les organisationsToutes les organisations utilisent les blueprints, sauf en cas de retour explicite à la configuration classique. Les nouvelles organisations démarrent avec les blueprints.
Les transitions se font dans cet ordre : Disabled → Default Off → Default On. Vous pouvez également revenir en arrière (Default On → Default Off) pour ralentir le déploiement.

​
Détails de Default Off

Dans l’état Default Off, 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 existe un paramètre supplémentaire : Afficher l’incitation à la migration à toutes les organisations. Lorsqu’il est activé, 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 d’activer cette option. Cela permet de sensibiliser les équipes avant de commencer à migrer des orgs. Lorsque ce paramètre est désactivé, les orgs qui n’ont pas été explicitement activées ne voient rien de nouveau. Leur expérience reste inchangée.

​
Dérogations par org

Les administrateurs Enterprise peuvent remplacer l’état de déploiement pour des organisations spécifiques depuis la page Rollout :
  • Avec Default Off : activez les blueprints pour des orgs spécifiques. Ces orgs passent immédiatement de la configuration classique à la configuration déclarative.
  • Avec Default On : 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 même si l’état Enterprise change. Si vous activez les blueprints pour un org pendant la phase Default Off, il reste sur les blueprints lorsque vous passez à Default On.

​
Dérogations automatiques pour la configuration classique

Lors du passage de Default Off à Default On, 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 (Default Off)

Commencez avec l’entreprise en mode Default Off. Les orgs ne peuvent pas l’activer elles-mêmes : vous gardez donc un contrôle total.
  1. Activez les blueprints au niveau de l’entreprise en passant de Disabled à Default Off.
  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

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. Activez l’invite à la migration : basculez l’option “Show migration nudge to all organizations” afin que les administrateurs d’org utilisant la configuration classique voient 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

  1. Passez à Default On lorsque la plupart des organisations utilisent les blueprints. 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 instantanément n’importe quelle organisation sur la configuration classique depuis la page Rollout.

​
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 à l’échelle de l’entreprise

Les administrateurs Enterprise peuvent repasser de Default On à Default Off :
  • Les organisations qui avaient des dérogations explicites aux blueprints les conservent. Elles restent sur les blueprints.
  • Les organisations qui utilisaient les blueprints par défaut (sans dérogation) reviennent à la configuration classique.
  • Il s’agit d’une opération sans risque. Aucune donnée de configuration n’est perdue dans un sens ou dans l’autre.
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 l’un à l’autre 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 de l’état Enterprise (Disabled → Default Off, Default Off → Default On, 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.