Les Agents Cloud sont plus faciles à paralléliser que les agents locaux, continuent à travailler lorsque votre ordinateur portable est fermé et peuvent fonctionner de manière autonome en réponse à des déclencheurs programmatiques. Mais les agents ne sont efficaces qu’à la hauteur des environnements dans lesquels ils s’exécutent. Un agent qui sait écrire du code, mais ne peut pas exécuter de tests, interroger des services ou appeler des API, ne peut pas mener son travail jusqu’au bout.

Pour mener des tâches d’ingénierie de bout en bout, les Agents Cloud ont besoin d’un environnement de développement similaire à celui de votre ordinateur portable : dépôts clonés, dépendances installées, identifiants pour les chaînes d’outils internes et accès aux systèmes pour créer. Des environnements de développement efficaces donnent aux agents tout le contexte nécessaire sur votre base de code et votre organisation, afin qu’ils puissent tester et vérifier leur travail.

Aujourd’hui, nous livrons de nouveaux outils pour configurer les environnements de développement des Agents Cloud. Cursor peut aussi utiliser ces outils pour configurer et maintenir vos environnements. Ensemble, cette version permet plus facilement aux équipes d’exécuter des flottes d’agents parallélisés qui prennent en charge des tâches de bout en bout, dans des environnements de développement que vous contrôlez entièrement.

#Environnements multi-dépôts

Dans les grandes entreprises, la majeure partie du travail d’ingénierie s’étend sur plusieurs bases de code et dépôts. Les grandes organisations qui exploitent des microservices ont souvent de nombreux dépôts qui doivent évoluer de concert. Un agent limité à un seul dépôt a une utilité réduite, car il ne peut pas prendre en compte l’ensemble du contexte requis.

Les Agents Cloud et les automatisations prennent désormais en charge les environnements multi-dépôts, dans la continuité de nos travaux sur les espaces de travail multi-racines. Vous pouvez configurer un environnement unique avec tous les dépôts dont un agent a besoin pour travailler, et le réutiliser d’une session à l’autre. Avec plusieurs dépôts dans le périmètre, les agents peuvent comprendre comment une modification dans une partie de la base de code affecte les autres, et travailler sur plusieurs dépôts pour livrer, tester et valider les changements.

Écoutez directement certains de nos clients qui utilisent des environnements multi-dépôts :

#Configuration de l’environnement sous forme de code

Pour faciliter la modification, le débogage et l’examen des définitions d’environnement, nous avons amélioré la configuration basée sur des Dockerfiles. Cela inclut la prise en charge des secrets de build, ce qui permet d’accéder en toute sécurité à des registres de paquets privés directement depuis les Dockerfiles. Les secrets de build sont limités à l’étape de build et ne sont pas transmis à l’environnement de l’agent en cours d’exécution.

Nous avons également amélioré la mise en cache des couches, de sorte que seules les couches mises à jour de votre image sont reconstruites lorsque vous modifiez le Dockerfile. Les builds qui utilisent le cache s’exécutent 70 % plus vite.

Pour les équipes qui ne souhaitent pas rédiger de Dockerfile de A à Z, Cursor peut le configurer pour vous. Cursor inspectera vos dépôts, identifiera les outils et les dépendances requis, puis générera une configuration que vous pourrez modifier et versionner. Cette fonctionnalité est actuellement en bêta privée et sera progressivement déployée pour les équipes Enterprise au cours des prochaines semaines.

#Configuration améliorée de l’environnement par l’agent

Lorsque Cursor configure votre environnement, il vous posera des questions, signalera les identifiants manquants et vérifiera que votre environnement est correctement configuré.

Cursor prend également mieux en compte les environnements de développement. Il vous indiquera la version de l’environnement dans lequel votre agent s’exécute. Si la configuration de votre environnement échoue, Cursor utilisera par défaut une image de base avec des avertissements explicites afin que vos Agents Cloud puissent continuer à s’exécuter au lieu d’échouer immédiatement.

#Gouvernance des environnements et contrôles de sécurité

Chaque environnement de développement dispose désormais de son propre historique de versions, que les utilisateurs peuvent consulter et restaurer à une version antérieure. Les administrateurs peuvent également restreindre les autorisations de restauration aux seuls administrateurs. Un journal d’audit consigne chaque action effectuée par les membres de l’équipe sur les environnements afin que les équipes de sécurité puissent voir qui a effectué quelle modification.

Le trafic sortant et les secrets peuvent désormais être définis au niveau de l’environnement de développement. Les équipes peuvent restreindre l’accès réseau sortant à une liste d’autorisation spécifique pour un environnement, tout en laissant un autre environnement plus permissif. De plus, les secrets configurés pour un environnement ne sont accessibles depuis aucun autre.

#Et après

Aujourd’hui, les environnements sont configurés à un instant donné, puis reconstruits lorsqu’ils ne sont plus synchronisés avec la base de code. Nous évoluons vers des configurations d’environnement qui s’adaptent de manière autonome à mesure que votre base de code évolue.

Pour commencer avec les environnements de développement des agents cloud, lisez la documentation ou consultez votre tableau de bord des agents cloud.