Passer au contenu principal

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

Activer le bouton bascule

Activez le bouton bascule Differential builds. 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.
Le premier build après l’activation des builds différentiels sera toujours un build complet — le système a besoin d’un snapshot de référence réussi pour effectuer la comparaison. Les builds suivants seront différentiels tant qu’un parent valide existe.

​
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) à 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, les secrets et l’ordre des dépôts — 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 :
ActionCe qui se passeQuand elle est utilisée
RebuildCloner le repo et exécuter toutes les étapes du blueprint (initialize + maintenance) depuis le débutLe blueprint a changé depuis le build parent
InheritRécupérer le code le plus récent et exécuter uniquement les étapes maintenanceLe blueprint est inchangé — réutiliser la configuration du parent
RemoveSupprimer l’espace de travail du snapshotL’espace de travail a été supprimé de la configuration
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 est lancé à la place

Même lorsque les builds différentiels sont activés, le système revient à un build complet dans certaines situations :
  • Aucun build parent n’existe — premier build, ou tous les builds précédents ont échoué
  • Le blueprint de l’organisation ou le blueprint d’entreprise a changé — les modifications globales affectent tous les espaces de travail, donc un rebuild propre est plus sûr
  • L’ordre des repositories a changé — comme les dépôts peuvent dépendre de la configuration les uns des autres, un réordonnancement déclenche un rebuild complet
  • Le build parent est trop ancien ou incompatible — le système vérifie que le parent est compatible
Lorsqu’un tel basculement se produit, la page de détails du build affiche la raison sous le badge du type de build.

​
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

AvantageDescription
Builds plus rapidesSeuls les espaces de travail modifiés passent par le processus complet de configuration. Les espaces de travail hérités n’exécutent pas du tout initialize.
Moins de trafic réseauLes espaces de travail inchangés ne retéléchargent pas les outils, les environnements d’exécution ni les dépendances volumineuses.
Itération plus rapideLorsque vous itérez sur le blueprint d’un seul dépôt, les autres dépôts ne ralentissent pas le build.
Même fiabilitéSi quelque chose semble incorrect, le système bascule automatiquement sur un build complet. Vous pouvez aussi déclencher manuellement un build complet à tout moment.

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