Jump to content

Dév FileMaker en équipe


Loraga
 Share

Recommended Posts

Bonjour à tous,

Cette question est plutôt destinée à ceux qui développent des solutions FileMaker à plusieurs, aux pros, et c'est surtout de la curiosité 😊

Comment faites-vous pour travailler à plusieurs sur une même solution ? J'ai déjà eu l'occasion de travailler à deux développeurs sur le même fichier ; il y a des fois ou c'est assez frustrant de devoir attendre que l'autre valide ses modifications, autant du côté des bases que des modèles entre autre. De mon côté, à deux, ça demandait un peu d'organisation en amont mais si on est plus, ça doit être plus compliqué.
• Comment gérez-vous cela ?

J'imagine que, comme les agences web par exemple, chacun à son rôle et son domaine d'expertise : l'un gère le backend (bases de données, liens, scripts serveur, etc), l'autre le frontend (interfaces, fonctionnalités utilisateur, etc)...
• De manière générale, quels sont les rôles principaux dans une équipe de développeurs FileMaker ?

Et enfin, dernière question : le versionnage
• Comment gérez-vous les versions des fichiers pendant son développement ? Dans le web, on utilise un gestionnaire de version comme Git, existe-t-il des solutions similaires pour FileMaker ?
De mon côté, étant seul, c'est assez simple : j'ai toujours une fonction perso nommée sobrement "__version" qui a pour seul but de renvoyer le N° de version en texte (ça permet de l'afficher discrètement en bas de chaque modèle...). Ensuite, régulièrement et surtout avant de bosser sur une solution, je la sauvegarde en double (sur mon ordi+un serveur de stockage) en la renommant en incluant son N° de version. Et c'est tout ^^

Je n'arrive pas à savoir s'il y a la possibilité, avec FileMaker, que chacun bosse de son côté sur sa propre partie, puis en fin de journée, tout compiler pour en faire une version.

Merci d'avance pour vos lumières ! J'espère avoir un jour l'opportunité de travailler en équipe sur des projets intéressants et de plus grande envergure 😊 c'est donc toujours intéressant de savoir comment ça se passe côté organisation et fonctionnement.

Bonne semaine à tous 😊

Link to comment
Share on other sites

Bonjour,

c'est un vrai sujet car en effet on peut vite se marcher dessus en travaillant à plusieurs.

Le fait de devoir travailler à plusieurs va même parfois déterminer l'architecture d'un projet. Par exemple une interface qui aurait pu être constituée de plusieurs onglets sur un modèle, on aura tendance à créer autant de modèles pour limiter les "conflits". On peut également opter pour plusieurs fichiers de données (toutefois nous n'utilisons cela que si le volume de données justifie également cette répartition, et ce en raison, notamment, de la problématique de version et d'identifiants de fichier. (une petite idée pour laquelle voter sur Community https://community.claris.com/en/s/idea/0873w000001DZZ6AAO/detail

Les équipes qui optent pour une stratégie "tout script" (par opposition à "tout auto-entrée) sont également moins exposées à ces conflits entre développeurs, de même que celles qui optent pour le "tout sql". Chez 1-more-thing nous n'entrons dans aucune de ces catégorie par choix (pour des raisons de qualité de la donnée pour le premier cas, et de performance pour le second). L'utilisation de web services et d'OData est un facteur qui pourrait nous faire changer pour certains projets)

Autres astuces : utiliser le "field picker" du mode modèle pour rapidement modifier les options d'auto-entrée ou les calculs en limitant le temps d'intervention dans la base de données, bien tester un calcul dans le visualiseur de données avant de l'intégrer dans la base de données, ne pas hésiter à créer des fonctions personnalisées pour abstraire le code contenu dans les calculs...

Sur la gestion des versions. Git permet de gérer des fichiers binaires, et FileMaker peut désormais -mais c'est encore trop fragile- sauver une copie en xml. Il y a également un outil permettant de créer des patch, mais pour une utilisation au quotidien c'est encore trop compliqué.

Le Data Migration Tool a en revanche changé nos vies, même s'il lui manque quelques options (le maintien des file ID comme dit plus haut, le choix des locales indépendamment du système, ou la pré-population des nouvelles rubriques).

Link to comment
Share on other sites

Bonjour Fabrice et merci pour votre réponse détaillée !

Il y a 1 heure, fabriceN a dit :

Le fait de devoir travailler à plusieurs va même parfois déterminer l'architecture d'un projet. Par exemple une interface qui aurait pu être constituée de plusieurs onglets sur un modèle, on aura tendance à créer autant de modèles pour limiter les "conflits". On peut également opter pour plusieurs fichiers de données (toutefois nous n'utilisons cela que si le volume de données justifie également cette répartition, et ce en raison, notamment, de la problématique de version et d'identifiants de fichier. (une petite idée pour laquelle voter sur Community https://community.claris.com/en/s/idea/0873w000001DZZ6AAO/detail

Je vois, c'est intéressant ! Ça demande effectivement pas mal d'organisation. Côté interface et modèles, la maintenabilité doit cependant être un peu plus compliquée. Je ne connais absolument pas les ID de fichiers, je vais me renseigner là-dessus pour comprendre la problématique. J'imagine que c'est un peu comme les identifiants de rubriques internes à FileMaker, on n’a pas vraiment de contrôle là-dessus

 

Il y a 2 heures, fabriceN a dit :

Les équipes qui optent pour une stratégie "tout script" (par opposition à "tout auto-entrée) sont également moins exposées à ces conflits entre développeurs, de même que celles qui optent pour le "tout sql"

J'ai tendance moi-même à faire le plus possible de tâches par script (ça dépend évidement du contexte), mais je ne savais pas qu'on pouvait opter pour du "tout script" ou "tout en auto entrée". D'ailleurs, tout faire en auto entrée, je ne pensais pas cela possible ! (Et en tout SQL, ça doit se défendre, mais à première vue je trouve ça affreux de ne faire que du SQL avec FileMaker 😂)

Il y a 2 heures, fabriceN a dit :

Autres astuces : utiliser le "field picker" du mode modèle pour rapidement modifier les options d'auto-entrée ou les calculs en limitant le temps d'intervention dans la base de données, bien tester un calcul dans le visualiseur de données avant de l'intégrer dans la base de données, ne pas hésiter à créer des fonctions personnalisées pour abstraire le code contenu dans les calculs...

Si j'ai bien compris, intervenir dans la base depuis le volet de gauche du mode modèle peut permettre à plusieurs personnes d'intervenir sur la même base en même temps, où c'est juste plus rapide de faire comme ça ?
Le visualiseur, c'est clairement un atout considérable & simplissime dans FileMaker.

Et du coup, quelle est votre méthode pour la gestion des versions ?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...