Skip to main content

​
Vue d’ensemble

Par défaut, chaque build du snapshot est un build complet : il démarre à partir d’une image de base propre, clone tous les dépôts et exécute chaque blueprint à partir de zéro. Cela garantit un environnement entièrement reproductible, mais peut être lent lorsque vous n’avez modifié qu’un seul blueprint parmi beaucoup d’autres. Les builds différentiels optimisent ce processus en réutilisant le snapshot du build réussi précédent comme point de départ. Seuls les espaces de travail dont les blueprints ont réellement changé sont reconstruits ; les espaces de travail inchangés sont hérités tels quels du build parent. Cela peut réduire considérablement les temps de build, en particulier pour les organisations ayant de nombreux dépôts.

​
Activer les builds différentiels

1

Accéder aux paramètres de l'environnement

Accédez à Settings > Environment > Avancé.
2

Activer le bouton bascule

Activez le bouton bascule builds différentiels. La description affichée est la suivante : “Builds plus rapides grâce à la réutilisation des espaces de travail inchangés.”
3

Déclencher un build

Enregistrez une modification du blueprint ou cliquez sur Build snapshot. Le build suivant tentera d’être exécuté en mode différentiel si un build parent valide existe.
L’activation des builds différentiels ne force pas un build complet. Si un build précédent réussi ou partiel existe déjà pour la même plateforme et la même Machine Configuration, le build suivant peut l’utiliser comme parent et hériter de son état. Le build suivant s’exécute en build complet uniquement dans les situations répertoriées dans Quand un build complet s’exécute à la place. Pour repartir d’une base vierge, sélectionnez Build complet dans le menu déroulant Build snapshot.

​
Fonctionnement

Lorsqu’un build est déclenché alors que les builds différentiels sont activés, le système suit le processus suivant :

​
1. Trouver un build parent

Le système recherche le build réussi le plus récent (statut success ou partial) disposant d’un snapshot image pour la même plateforme et la même Machine Configuration à utiliser comme parent. S’il n’existe aucun parent admissible, le build bascule automatiquement vers un build complet.

​
2. Comparer les blueprints

La configuration de chaque espace de travail est comparée au build parent. Le système calcule une empreinte des entrées de chaque espace de travail — y compris le contenu du blueprint, les fichiers attachés et les secrets — et vérifie ce qui a changé.

​
3. Attribuer des actions aux espaces de travail

En fonction de la comparaison, chaque espace de travail se voit attribuer l’une des trois actions suivantes :
Pour les espaces de travail hérités, initialize n’est pas exécuté à nouveau. Écrivez maintenance de façon à ce qu’il soit autonome et puisse s’exécuter indépendamment après la récupération du code le plus récent. Il peut utiliser des outils et des environnements d’exécution déjà installés dans le snapshot parent, mais il ne doit pas nécessiter l’exécution préalable immédiate de initialize ni dépendre de variables d’environnement que initialize a précédemment écrites dans $ENVRC.

​
4. Exécuter le build

Le build démarre à partir de l’image snapshot du build parent, plutôt que d’une base vierge. Cela signifie :
  • Les espaces de travail hérités ont déjà leurs outils, environnements d’exécution et dépendances installés. Le système récupère la version la plus récente du code (git pull) et exécute les commandes maintenance pour mettre à jour les dépendances.
  • Les espaces de travail reconstruits sont recréés de zéro — reclonés puis soumis à toute la séquence initialize + maintenance.
  • Les espaces de travail supprimés voient leurs répertoires nettoyés.
Les blueprints d’organisation et d’entreprise ignorent initialize lors des builds différentiels (puisque ces outils sont déjà présents dans l’image parente) et n’exécutent que maintenance.
$ENVRC est réinitialisé au début de chaque build, y compris des builds différentiels. Les variables d’environnement et les entrées PATH écrites dans $ENVRC par un build précédent ne sont pas héritées. Si maintenance en a besoin, il doit les configurer lui-même.

​
Quand un build complet s’exécute à la place

Même lorsque les builds différentiels sont activés, un build s’exécute en build complet dans les situations suivantes :
  • Vous demandez un build complet — vous sélectionnez Build complet dans le menu déroulant Build snapshot
  • Le build complet le plus récent est trop ancien — un build automatique, par exemple déclenché par l’enregistrement d’un blueprint, s’exécute en build complet lorsqu’aucun build complet n’existe pour sa plateforme ou que le plus récent dépasse l’intervalle Full build refresh défini dans Settings > Environment > Advanced (tous les 7 jours par défaut)
  • Aucun build parent réutilisable n’existe — il n’existe aucun build success ou partial doté d’un snapshot image pour la même plateforme et la même Machine Configuration
  • Le build parent est incompatible — la plateforme, la Machine Configuration, l’image de base ou le paramètre Clone repositories on all platforms a changé depuis le build parent, ou le build parent ne dispose d’aucun baseline de secrets servant de point de comparaison
  • La configuration de l’organisation ou de l’entreprise a changé — un blueprint d’organisation ou un blueprint d’entreprise, un fichier blueprint ou un secret a changé depuis le build parent
Les modifications limitées à des repositories individuels préservent le caractère différentiel du build. Les nouveaux repositories, les modifications de blueprint ou de secret pour un repository, ainsi que les repositories ayant échoué lors du build parent sont reconstruits au sein du build différentiel. Réordonner les repositories ne déclenche pas de build complet. Lorsqu’un build demandé en différentiel s’exécute finalement en build complet, l’infobulle type de build de la page de détail du build en indique la raison.

​
Voir le type de build

Une fois le build terminé, vous pouvez voir s’il s’agit d’un build différentiel ou d’un build complet :
  1. Accédez à Settings > Environment > Snapshots
  2. Cliquez sur un build dans l’historique
  3. Le badge Type de build affiche Différentiel (bleu) ou Build complet (par défaut)
Survolez le badge pour afficher une infobulle expliquant la signification de chaque type :
  • Différentiel : “Seuls les espaces de travail modifiés sont reconstruits ; les espaces de travail inchangés sont repris du dernier build réussi avec la même configuration”
  • Build complet : “Tous les espaces de travail sont reconstruits à partir de zéro”

​
Avantages

​
Déclencher manuellement un build complet

Même avec les builds différentiels activés, vous pouvez forcer un build complet depuis le bouton Build snapshot. Utilisez le menu déroulant pour sélectionner build complet au lieu de l’option différentielle par défaut. Nous vous recommandons d’exécuter périodiquement un build complet pour supprimer l’état hérité et vérifier que vos blueprints peuvent toujours créer l’environnement à partir de zéro. Exécutez-en également un après avoir supprimé ou remplacé une configuration qui pourrait avoir laissé des fichiers, outils ou dépendances obsolètes dans le snapshot. Un build complet relance toutes les étapes initialize et maintenance.

​
FAQ

Non. Les sessions démarrent toujours à partir du snapshot final, quelle que soit la manière dont il a été généré. La seule différence concerne la vitesse du build.
Épinglez un build antérieur fiable depuis Settings > Environment > Snapshots, puis déclenchez un build complet pour obtenir un snapshot propre. Vous pouvez aussi désactiver complètement les builds différentiels pour revenir aux builds complets.
Oui. Un build dont le statut est partial (certains espaces de travail ont réussi, d’autres ont échoué) peut servir de parent. Le système n’hérite que des espaces de travail ayant réussi dans le parent.