Discussion :

[grinder59]

Bonjour,

tout d'abord désolé si je ne poste pas dans la bonne catégorie, mais je ne savais pas trop où le faire.

Voici ma problématique.

j'ai 1 application en version DEV, DEMO et PROD.
Cette application est composée d'un index et de sous applications indépendantes organisées en dossier (1 dossier = 1 application). C'est en PHP4, donc pas d'objet, mais quelques fichiers communs (paramètres, fonction essentiellement) aux sous applications.

Actuellement, je développement en DEV, passe en DEMO pour que le client y ait accès et met en PROD après validation client. J'ai aussi en DEV des parties de codes isolées dans des répertoires identifiés à ne pas mettre en prod.
Parfois, je fais des modif directement en prod (c'est mal, mais c'est le client qui demande et je peux pas toujours dire non). Les 3 environnements sont sur le même serveur (pas le choix).
Enfin, le tout repose sur une base de données MySQL.

Actuellement, je perds un temps fou à réconcilier mes versions d'applications car je compare mes dossiers (100 dossiers environ) directement avec WinMerge.

Je voudrais savoir si SVN était une solution pour optimiser le versioning de mon application ? Je ne connais le produit que de très loin et avant de l'installer sur mon serveur et d'apprendre à l'utiliser, je souhaiterai savoir si il serait adapté dans mon cas.

Merci de vos conseils !

[tse_jc]

Bonjour,

Avant de vous répondre et de vous donner mon point de vue, je vous dirais de faire attention à la dénomination de vos version. En effet une version DEMO n'est pas forcément une version de PREPROD, mais peut être une déclinaison de la version de PROD. Si l'on veut faire les choses correctement, chaque version de PROD doit avoir sa PREPROD associée, et pourquoi pas sa DEMO associée.
Si vous ne voyez pas la différence entre une PREPROD et une DEMO, la PREPROD sert à valider et déboguer une nouvelle fonctionnalité dans un environnement technique identique à la PROD, pour ensuite la basculer en PROD. Une version DEMO est particulière dans le sens où elle sert à ce qu'un client puisse évaluer l'application pour l'acheter ou s'y abonner. L'environnement de DEMO n'est donc pas similaire à l'environnement de PROD dans le sens qu'il y rajoute des fonctionnalités spécifiques à une DEMO (comptes temporaires / compte unique vs multi comptes, etc...), mais doit rester similiaire au niveau fonctionnalités métier présentes dans la PROD qu'elle représente.

L'intérêt dans un tel contexte de développer en SGBDR épais est qu'il est possible d'avoir un code identique (PHP/Js) quasiment dans les trois distributions d'une même version. Certaines différences demeurent cependant comme la couche de connexion à la BD, car il est important de le rappeler, elles doivent fonctionner chacune sur leur propre base de données pour préserver la cohérence et l'intégrité des données de production, et l'isolation des données / jeux de tests de la PREPROD de la PROD.

Quand on se place comme vous dans un contexte où l'application est pilotée coté objet, le multi versionning PROD/PREPROD est à éviter humainement parlant d'autant plus dans un contexte complexe, sauf à avoir une équipe dédiée pour la gestion et la maintenance d'une version applicative, car seul, sauf à mettre en place doc technique complète sur chaque version, je vous défie de rester productif sur la mise en place d'une mise à jour pour une version X ou Y, 6 mois plus tard, winmerge ou non.

Quand à savoir pour SVN, tout dépends si l'essentiel de votre paramétrage est inclus dynamiquement côté SGBDR ou côté PHP (méthode des applis compilées), dans lequel les paramétres de configurations applicatives peuvent changer d'une version à l'autre.

Ensuite, pour chaque version validée en production, un backup archive de l'application + modèle de données associé est également une méthode efficace, ainsi cela permet de travailler toujours sur une seule version, et de pouvoir revenir à la précédente sans perte de temps, et laisse le loisir d'extraire une partie du code que l'on souhaite conserver dans le code qui sera supprimé.

++

EDIT: Ensuite le versionning géré par GIT ou SVN, sont plus là à la base pour gérer les mises à jour concurrentielles sur une version en cours dans un cadre de développement par une équipe que pour gérer le multi versionning applicatif dans un contexte ou les modifications concurrentielles sont absentes.

[Philippe Bastiani]

Je voudrais savoir si SVN était une solution pour optimiser le versioning de mon application ? Je ne connais le produit que de très loin et avant de l'installer sur mon serveur et d'apprendre à l'utiliser, je souhaiterai savoir si il serait adapté dans mon cas.

La réponse est clairement OUI pour l'utilisation d'un SCM quelqu'il soit !

A un instant T, si je comprend bien tu es susceptible d'avoir 3 versions
- une version en prod buguée mais qui doit continuer à tourner en l'état jusqu'au fix
- une version de maintenance sur laquelle tu fais ton fix
- une version de travail
=> ces 2 dernières peuvent donc, avoir des éventuels conflits.
=> tu dois pouvoir passer d'une version à l'autre à tout instant

Une façon de travailler avec svn (ou autre), est de considérer le trunk comme ta version de travail. Lorsque ton travail doit être livré, tu poses un tag sur le trunk et tu ouvres un branches de maintenance à partir de ce tag. Lors de tes fix tu travailles sur la version de maintenance sur laquelles tu vas poser un ou plusieurs tags de sous-livraison; et , pour chaque sous-livraison tu peux choisir (ou pas) de reporter le fix sur le trunk...

Maintenant: est-ce que svn est l'outil le plus adapté !
- oui : c'est un outil simple
- non: il n'est pas 'adapté' au travail en branches simultannées... Bien que des outils comme Jigomerge facilitent le travail... Un petit billet sur le sujet !
De mon point de vue, il vaut mieux s'orienter vers un DVCS tel que Mercurial ou Git: le premier à l'avantage d'être plus simple (admin/usage); le, second est devenu un standard...

a+
Philippe