[Alexandre]

Hello

Je l’ai testé avec un collègue et je suis plus que sceptique : il est à mon avis trop risqué de travailler à plusieurs sur la même app avec le coAuthoring. En effet le système de merge va conserver en cas de conflit la dernière version enregistrée. Ainsi si vous ajoutez un bouton (quelque soit l’écran) il prendra par défaut le nom dispo suivant par exemple Button2 (car le button1 était déjà pris). Si votre collègue ajoute lui aussi un bouton sur un autre écran, il aura aussi le Button2… Maintenant vous enregistrer le bouton avec un super code bien léché, des boucles forall avec des filters et des lookup imbriqués, quelques addColumn pour les traitements…. dans l’instant qui suit, votre collègue enregistre son petit test sur le bouton Button2 : Notify(“hello world”). Puis il enregistre… Il arrive le dernier, il a donc raison, et du coup vous perdez tout votre travail sans ne jamais en être averti….

Dites moi si je me trompe et/ou si cela a été réparé, amélioré… Car en l’état c’est juste inutilisable AMHA…

CommentID=oBg6K8Pn5Uyc7jr, PostID=s8oDE2N11Ua6Shy

[R3dKap]

Bonjour @Alexandre,

Merci pour ce retour très intéressant. Je n’ai pas encore eu l’occasion de l’utiliser moi-même mais j’en ai discuté avec des personnes pour qui c’était le cas. A mon avis, le comportement que tu décris est effectivement celui “attendu”.

Cependant, je voudrais apporter quelques éléments qui, je l’espère, t’aideront à mieux comprendre et à mieux utiliser cette fonctionnalité.

C’est expérimental !

Cette fonctionnalité est expérimentale :

• Nous disposons donc du minimum pour l’instant et la fonctionnalité sera probablement amenée à évoluer. Et du coup, en effet, pour l’instant il n’y a pas de gestion de conflits.

• L’équipe Power Apps de Microsoft va analyser l’utilisation qui est faite de la fonctionnalité afin d’estimer l’intérêt de la communauté des créateurs d’applications lui porte. Et à un moment donné il y aura arbitrage…

Il faut s’organiser !

Pour une bonne utilisation de cette fonctionnalité (et éviter ainsi les écueils que tu as rencontré), il est absolument capital de s’organiser :

👉 1 écran = 1 développeur

👉 1 composant = 1 développeur ; encore que là, une meilleure solution consisterait à créer les composants dans une bibliothèque de composants plutôt que directement dans l’application.

👉 Objet App = 1 développeur

👉 Renommer un contrôle immédiatement après l’avoir ajouté à un écran et surtout, surtout, respecter les conventions de nommage (https://pahandsonlab.blob.core.windows.net/documents/PowerApps%20canvas%20app%20coding%20standards%20and%20guidelines.pdf, page 5), à savoir :

• xxxMonContrôleYYY (attention à respecter les majuscules/minuscules pour plus de lisibilité) où :

  • xxx = trigramme représentant le type de contrôle

  • YYY = acronyme qui représente l’écran où se trouve le contrôle

👉 Je n’enregistre mon travail qu’après avoir correctement nommé mes contrôles

👉 Je n’enregistre mon travail que lorsque je n’ai plus d’erreurs dans mon code

👉 Il faut un pilote qui chapeaute tout ça : c’est lui qui décide à qui chaque élément de réalisation est attribué et c’est lui qui pilote la gestion des écrans (nouveaux écrans à créer, etc.).

En respectant ces règles, tu ne devrais plus être confronté aux problèmes que tu as rencontré lors de tes tests.

Il me semble que dans ce cadre-là, cette fonctionnalité offre quand même la possibilité non négligeable de réduire le temps de développement d’une application.

Mais je serais très intéressé d’avoir des retours d’expériences avec ce mode de fonctionnement… 😉

CommentID=Fqrf5oPe9S02UIq, PostID=s8oDE2N11Ua6Shy

[Alexandre]

Si Microsoft tire des enseignements sur les bases actuelles auxquelles je pense de nombreux dev au sein de gros SI, ne pourront adhérer alors ça va mourir dans l’oeuf …

J’ai déjà songé à toutes les règles que tu mentionnes pour que ça se passe bien, mais pour moi GIT est là pour palier aux défaillances humaines (conflits de nommages, erreurs induites par des evos sur lesquelles on doit revenir en arrière etc….) Toutes ces règles sont donc bien trop dépendantes de l’humain pour qu’elles deviennent intéressantes. (quand la machine ne peut pas aider l’humain a ne pas commettre de bêtises alors quel est son intérêt ? Et le but de GIT est bien d’empêcher les conflits de code)

Si la solution repose sur l’humain et que d’autres humains doivent à tel point s’assurer que tout va bien alors autant mettre uniquement de l’humain pour planifier les interventions des différents développeurs sur des moments différents de la journée de travail ou alors sur des copies de l’appli en attendant qu’une fonctionnalité soit terminée pour ensuite l’intégrer dans l’App principale etc…

Alors qu’en fait, je pense qu’à moindre coût Microsoft pourrait largement améliorer l’usage :

Le dernier qui enregistre pourrait avoir un retour comme quoi le bouton qu’il vient d’ajouter a déjà été ajouté entre temps et qu’il faut qu’il le renommer…. Microsoft pourrait bloquer l’enregistrement et/ou la fusion tant que les conflits ne sont pas résolus (donc pas de conflits au sens GIT puisque la nouvelle version ne serait pas encore fusionnée.)

CommentID=LBzaG670I1NPBr0, PostID=s8oDE2N11Ua6Shy

[R3dKap]

Alors je pourrais pas challenger la partie Git que je ne maîtrise pas du tout… Mais je te suis sur l’idée de bloquer l’enregistrement lors de conflits… 🙂

CommentID=ooTVV8A1Cl0NBR7, PostID=s8oDE2N11Ua6Shy