Discussion :

[Patrick Ruiz]

Une startup propose un plugin pour Visual Studio qui montre en temps réel sur quels fichiers des coéquipiers travaillent
Pour éviter des conflits

Le nom de l’outil est révélateur du but pour lequel il a été mis sur pied : Coactive. Le plugin nécessite la présence de Visual Studio 2017 ou 2019 sur le système sur lequel on veut en faire usage. En sus, l’équipe de développement souligne qu’il faut que le système de contrôle de version distribué – Git – soit installé.

De façon brossée, Coactive permet de faire du contrôle de versions de logiciel. « Coactive est une extension Visual Studio qui fournit aux développeurs un aperçu unique de ce sur quoi leurs coéquipiers travaillent en temps réel, prévient les conflits avant qu'ils ne surviennent, et identifie les opportunités de collaboration », écrivent les concepteurs.

Coactive est, au niveau de l’interface, architecturé autour d’un navigateur d’activités – Coactive Activity Browser. C’est par ce biais que l’utilisateur a un visuel de l’activité des intervenants au sein d’un même dépôt.

« Lorsqu'un conflit est susceptible de se produire, Coactive vous le fait savoir immédiatement. Vous pouvez voir la version du fichier de votre coéquipier, passer en revue un diff de vos deux fichiers et même initier des fusions. Vous pouvez faire tout cela sans déranger votre coéquipier. Si vous le souhaitez, vous pouvez ouvrir un chat, et résoudre le conflit ensemble, à partir de l'EDI », indiquent les têtes derrière l’outil pour ce qui est des fonctionnalités offertes. En résumé, Coactive permet de : visualiser l’activité d’un coéquipier qui intervient sur le même dépôt, voir sa version de fichier, passer en revue un diff de fichiers, initier des fusions et ouvrir un chat pour, le cas échéant, résoudre des conflits à partir de l’environnement de développement intégré.

En sus, l’équipe de développement annonce la compatibilité de Coactive avec Visual Studio Live Share de Microsoft. Mais, ce qu’il faut bien souligner c’est que certaines fonctionnalités annoncées pour Coactive ne sont pas encore implémentées. Il sera intéressant de voir comment Coactive s’intègre avec Visual Studio Live Share.

« Live Share permet à votre équipe de collaborer rapidement sur la même base de code sans devoir synchroniser le code ou configurer les mêmes outils de développement, paramètres ou environnement », explique Microsoft à propos du service annoncé pour la première fois en fin d’année 2017. D’après la firme de Redmond, lors du partage d’une session collaborative, l’utilisateur dispose d’un aperçu du contexte de travail au sein de l’éditeur. Il peut lire le code partagé par son coéquipier sans avoir à cloner un dépôt ou installer les dépendances sur lesquelles repose le code à inspecter. D’après la description de Microsoft, Visual Studio Live Share ne se limite pas à un simple partage d'écran simple. Le service permet aux développeurs de synchroniser les dépôts pour collaborer, mais aussi éditer et déboguer du code en temps réel. Encore une fois, la limite avec Coactive est à définir de façon plus claire.

L’équipe de développement a fait le choix d’Amazon Web Services pour l’hébergement. « Nous conservons vos données tant qu'elles sont pertinentes pour vos coéquipiers. Une fois que vous avez terminé votre travail, nous purgeons toutes les données. Nous nous appuyons sur le protocole HTTPS pour toutes les communications », rassurent les concepteurs de l’outil.

Dans l’esprit, Coactive propose de signaler en temps réel des accès concurrents à des fichiers au sein d’un même dépôt. Sous cet angle, l’outil peut contribuer à diminuer les conflits qui peuvent survenir lors d’opérations de fusions de bases de code. Il y a seulement qu’à date, le plugin génère des signalements sur la base de noms de fichiers, ce, indépendamment de la branche de développement concernée. Cette approche génère des interrogations sur les résultats que l’on pourrait obtenir sur des projets dotés d’un nombre importants de contextes de développement.

Après, il faut même revenir au listing des fonctionnalités proposées. En effet, visualiser l’activité d’un coéquipier qui intervient sur le même dépôt, voir sa version de fichier, passer en revue un diff de fichiers, initier des fusions sont des fonctionnalités accessibles à qui possède une excellente maîtrise des commandes du système de contrôle de version distribué – Git. Coactive semble introduire une plus-value très limitée pour des tiers qui, sous Git, sont habitués à faire usage des commandes pour : créer de multiples branches et des commits, générer des diff, etc. Coactive rend donc accessibles par le biais de clics des fonctions que Git offre déjà – une espèce de réinvention de la roue.

La startup de néo-zélandaise est en phase de collecte des avis du public avant le lancement du produit final. L’accès à ce dernier sera conditionné à la souscription d’un abonnement mensuel.

Source : Coactive

Et vous ?

Qu’en pensez-vous ?

L’équipe Coactive propose-t-elle une solution à un problème qui n’en est pas un au vu des outils déjà disponibles ?

Quels sont pour vous les points de pertinence de l’existence de ce plugin ?

Seriez-vous intéressé par cette solution ?

Voir aussi :

Microsoft lance le nouveau service "Microsoft Teams" pour rivaliser avec le spécialiste du collaboratif en équipe, Slack

Visual Studio Live Share est disponible en préversion, l'extension permet aux développeurs de collaborer en temps réel dans VS 2017 et VS Code

Build 2018 : Microsoft annonce la disponibilité en préversion publique de VS Live Share, son extension de développement collaboratif en temps réel

Visual Studio Live Share désormais installé par défaut dans Visual Studio 2019 et toujours disponible comme extension pour VS Code

[Kulvar]

J'ai un collègue qui rend cette fonctionnalité inutile.
Il a toujours 50 onglets ouvert sur son navigateur et il ne ferme jamais ses onglets de fichiers ouvert dans l'éditeur.
Il tape le nom du fichier dans la barre de recherche quand il a besoin d'un fichier spécifique.

[e-sigmi]

Le fait d'ouvrir / voir un fichier dans son éditeur ne signifier pas forcément que l'utilisateur le modifie.
Sachant que le débogage nous en mène parfois à faire des modifications temporaires dans des fichiers.

[Guntha]

Sortir un front-end pour un système de contrôle de version et faire payer un abonnement mensuel alors qu'il y en a déjà plein de bons, y compris des gratuits, qui existent déjà?

Et que vient faire AWS là-dedans? Que ce soit chez Git, SVN ou Perforce, personne n'a jamais eu besoin d'un hébergeur tiers pour corriger ses conflits.

Et quid de ceux qui n'utilisent pas Visual Studio en tant qu'éditeur de code - en ce moment, on trouve de plus en plus d'éditeurs de code, et certaines personnes préfèrent ça, couplé à leurs propres outils de build et à un débugger externe, plutôt qu'un EDI -, ou, comme le soulignent Kulvar, ceux qui l'utilisent d'une façon "incompatible" avec Coactive?

Nous nous appuyons sur le protocole HTTPS pour toutes les communications

Hum, en 2019, c'est pas quasiment la loi d'utiliser HTTPS?

Au fur et à mesure que je lisais cet article, j'ai eu de plus en plus l'impression que ce n'était pas des ingénieurs qui ont initié le projet, mais des marketeux qui ont eu une fausse bonne idée, ou qui ont voulu justifier un partenariat que leurs anciens collègues chez des GAFA ont conclu avec eux.

[Beowulf59]

De mon point de vue, ce plugin ne sera utile que pour ceux qui ont de mauvaises pratiques à la base.

Lorsqu'un conflit est susceptible de se produire, Coactive vous le fait savoir immédiatement. Vous pouvez voir la version du fichier de votre coéquipier, passer en revue un diff de vos deux fichiers et même initier des fusions.

Sauf que si je développe une fonctionnalité et mon collègue une autre, que je suis encore en phase de développement et que lui a terminé, il pourra initier les fusions d'un travail encore en brouillon ?

Si on travaille avec un système de flux comme GitFlow ou le Github Flow, chacun a sa branche. La discussion et les éventuelles fusions sur une branche principale se font lors de la Pull Request, pas avant. Si on suit ce principe, il n'y a pas de raison de regarder le travail intermédiaire des autres, de savoir s'il va changer tel nom de variable ou refactoriser tel code : si on commence à gérer les conflits à la volée on fera des fusions tout les jours.

Bref, je ne vois pas où ils veulent en venir.