> ## 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.
# Builds différentiels
> Accélérez les builds du snapshot en ne reconstruisant que les espaces de travail dont les blueprints ont changé. Les espaces de travail inchangés sont repris du build précédent réussi.
## 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
Accédez à **Settings > Environment > Avancé**.
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."*
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 :
| Action | Ce qui se passe | Quand elle est utilisée |
| ----------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| **Rebuild** | Cloner le repo et exécuter toutes les étapes du blueprint (`initialize` + `maintenance`) depuis le début | Le blueprint a changé depuis le build parent |
| **Inherit** | Récupérer le code le plus récent et exécuter uniquement les étapes `maintenance` | Le blueprint est inchangé — réutiliser la configuration du parent |
| **Remove** | Supprimer l'espace de travail du snapshot | L'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
| Avantage | Description |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Builds plus rapides** | Seuls 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éseau** | Les 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 rapide** | Lorsque 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.