Lorsque l'on accorde à un agent d'intelligence artificielle l'accès à un environnement isolé (Sandbox), une question fondamentale se pose quant à la manière d'organiser les fichiers sur lesquels l'agent travaillera. La plateforme Docker Sandbox (désignée par sbx) propose trois modèles principaux pour la gestion du code source, chacun ayant un impact direct sur le flux de travail du développeur et son interaction avec l'agent.
1. Montage direct (Shared Mounts)
Cette option permet de partager directement le chemin de travail actuel de la machine hôte avec l'environnement isolé. Lors de l'exécution de sbx run à partir du dossier du projet, le dossier est monté au même chemin absolu à l'intérieur de l'environnement. Ce modèle est idéal pour une collaboration étroite sur une seule tâche, car le développeur peut voir les modifications dans son éditeur local dès qu'elles se produisent, et les serveurs de développement locaux peuvent également capturer les modifications grâce à la fonction de rechargement à chaud (Hot Reload).
Attention : Il convient de se méfier des conflits de dépendances ; les packages contenant des binaires natifs (Native Binaries) peuvent fonctionner dans l'environnement Linux isolé et échouer sur macOS ou Windows. Il est donc recommandé d'unifier l'environnement d'exécution ou de séparer l'installation des dépendances.
2. Utilisation d'arborescences de travail Git (Git Worktrees)
Cette option convient à l'exécution de plusieurs tâches simultanément. Elle attribue à chaque tâche son propre dossier et sa propre branche (Branch), ce qui permet de lier chaque arborescence de travail à un environnement isolé distinct. L'avantage ici est l'isolation totale des tâches, mais une contrainte technique subsiste : le fichier .git pointe vers des métadonnées situées en dehors de la portée du montage, ce qui signifie que des opérations telles que la vérification de l'état (git status) ou le basculement entre les branches doivent être effectuées depuis la machine hôte.
3. Mode clonage (Clone Mode)
Dans ce mode, l'outil sbx crée une copie indépendante du code à l'intérieur de l'environnement isolé, tout en connectant le code de l'hôte en lecture seule. Cela donne à l'agent un accès complet à Git au sein de l'environnement, le rendant totalement indépendant dans la gestion des branches et des validations (Commits). Une fois le travail terminé, le développeur peut récupérer les modifications via un dépôt Git distant (Remote).
Qu'est-ce que cela change dans le flux de travail du développeur ?
Le choix de la méthode appropriée dépend de la nature de la tâche et de votre degré de volonté d'intervention directe :
- Collaboration étroite : utilisez le montage direct si vous souhaitez surveiller le travail de l'agent au moment même où il se produit.
- Indépendance : utilisez le mode clonage ou des environnements entièrement isolés (Mountless) si vous souhaitez donner à l'agent un espace pour gérer les tâches sans affecter votre environnement de travail local.
- Gestion de projets multiples : des outils de gestion d'espaces de travail (Workspace Managers) peuvent être utilisés pour regrouper plusieurs dépôts dans un seul environnement, facilitant ainsi la gestion par l'agent de projets interconnectés (tels qu'une interface front-end et un back-end).
N'oubliez pas que les environnements isolés qui ne reposent pas sur le montage de fichiers hôtes (Mountless) nécessitent une gestion manuelle des ports (Ports) pour accéder aux serveurs de développement depuis votre navigateur local, une pratique qui renforce la sécurité de l'isolation mais ajoute quelques étapes de configuration supplémentaires.