Discussion :

[Hervé Saladin]

Bonjour,
je suppose que d'autres se sont déjà confronté à ce problème :

moi et mon autre collègue développeur, on bosse "en direct" sur les sources d'applis/sites en exploitation, ce qui créé quelques problèmes avec les utilisateurs lorsque l'on est en train de faire une modif qui n'est pas finie ou débugguée

Heureusement, j'ai fini par obtenir de mes chefs qu'ils me fournissent un serveur dédié au développement, afin qu'on puisse triturer le code et les données tranquilles sans stresser

Ma question est la suivante :

Quelle méthode ou outil utiliser pour verser les modifs une fois qu'elles sont prêtes ?

L'idéal, ça serait que je puisse transférer les fichiers sources sur le serveur d'exploitation "d'un bloc" et en conservant les mêmes droits sur les fichiers et dossiers que ceux qui étaient positionnés sur le serveur de dev , histoire de ne pas avoir à me taper des chmod à la main dans tous les sens chaque fois que fais un versement, ce qui serait long et source d'erreurs.

De plus, il y a le problème des bases de données : en effet, si mes modifs incluent des changements sur la structure des données, comment appliquer ces modifs de façon propre et sans erreur sur le serv d'exploit' ?
Si mes modifs incluent des changements sur le contenu des données, comment faire pour les appliquer de façon sûre au serv d'exploit sans abimer les données qui doivent rester en place ?

J'ai bien pensé à utiliser un CVS, mais je ne pense pas que ça gère les droits ? me trompe-je ? Et puis pour les BD, je pense que c'est carrément pas adapté, voir impossible de le faire par CVS ...

Voilà, vous avez compris mon problème.
Si vous connaissez des outils logiciels ou même méthodologique (voir simplement des conseils avisés) qui permettent de faire ça de façon propre et sûre, et si possible sans interruption de service lors de l'application des modifs (ou le moins possible), je suis plus que preneur

Merci d'avance et bon week-end !

[_Mac_]

Des méthodos documentées, je sais pas mais on devrait pouvoir te filer des tuyaux

Déjà, une chose à faire avant tout : installer un serveur de versioning genre CVS ou Subversion. Ca vous permettra de travailler à plusieurs sur les mêmes fichiers, de travailler éventuellement en avance de phase et surtout pouvoir établir de manière certaines ce qui va être livré en prod (= versions). L'intérêt des versions c'est qu'en cas de pb, vous êtes capables de revenir en arrière et retrouver exactement le source utilisé à un moment donné sur la prod. Et bien entendu, CVS (ou l'autre outil de versioning) est installé sur un serveur sûr et sauvegardé régulièrement

Logiquement, il serait bien que vous disposiez d'un 2ème environnement dit d'intégration qui soit le plus proche possible (en OS, versions des logiciels, etc.) de la prod : cet environnement vous servira à tester vos dév de prod et surtout vos procédures d'installation en prod. Ainsi, en cas de pb, vous n'avez rien cassé sur la prod et vous pouvez étudier le pb avant de recommencer éventuellement. Quand tout marche bien sur l'intégration (procédure d'installation et sources), passez en prod (voir plus loin).

Une fois que ce serveur est en place, il faut initialiser ce référentiel de source avec ce qui se trouve aujourd'hui en prod puis construire votre environnement de dev à partir de ces sources et d'une extraction des données de prod. Vous construirez donc au besoin des fichiers SQL pour construire la structure de la base de données. L'idée pour récupérer des données de prod c'est de pouvoir évaluer les impacts de vos modifs sur le modèle de données et vos scripts. Si vous ne pouvez pas utiliser des données issues de la prod pour des raisons de confidentialité ou je ne sais quoi d'autre, on peut toujours utiliser un jeu de données bidon mais il faut absolument que ce jeu soit représentatif de la prod en qualité et en volume.

Pour l'installation (en intégration ou prod), l'idéal est d'essayer d'automatiser au maximum les procédures. Pour 3 raisons : éviter les erreurs de manip, assurer un maximum de reproductibilité des procédures (corollaire du précédent) et aussi gagner du temps

Pour l'installation en production, vous avez normalement fait un premier essai sur l'intégration. Il faut que l'intégration soit le plus proche possible de la prod pour pouvoir mesurer les impacts (comme par exemple les chmods à faire ou refaire et à scripter éventuellement pour éviter les erreurs ou les oublis) et évaluer vos procédures d'installation. pour faire les choses bien pour le passage en prod, il faut prévoir une mise en indisponibilité de la plateforme. D'abord, vous prévenez les clients de la date et de la durée de l'indisponibilité. Ensuite, vous mettez en place une procédure ou page qui empêchera les clients d'accéder à l'appli pendant que vous faites vos installations tout en vous permettant de faire des tests. Vous ne rendez l'application disponible que quand vous avez fini et validé vos modifs.

Last but not least : avant d'installer quoi que ce soit, faire un backup pour pouvoir revenir en arrière à tout moment de manière sûre en cas de pb.

Dans le détail :

L'idéal, ça serait que je puisse transférer les fichiers sources sur le serveur d'exploitation "d'un bloc" et en conservant les mêmes droits sur les fichiers et dossiers que ceux qui étaient positionnés sur le serveur de dev , histoire de ne pas avoir à me taper des chmod à la main dans tous les sens chaque fois que fais un versement, ce qui serait long et source d'erreurs.

Ca passe par au moins 2 choses :

• tester sur l'intégration avant de passer en prod afin de voir quels pbs vous pouvez rencontrer
• scripter vos installations pour automatiser les installations et assurer une livraison de qualité
• y en a une 3ème mais j'ai oublié

De plus, il y a le problème des bases de données : en effet, si mes modifs incluent des changements sur la structure des données, comment appliquer ces modifs de façon propre et sans erreur sur le serv d'exploit' ?

Idem précédent : tester sur l'intégration pour voir les impacts de vos modifs et scripter pour traiter les éventuels conversions ou traitements des données.

Si mes modifs incluent des changements sur le contenu des données, comment faire pour les appliquer de façon sûre au serv d'exploit sans abimer les données qui doivent rester en place ?

Déjà, avant toute chose, tu as fait un backup. Comme ça, si jamais y a des gros pépins, tu veux revenir en arrière et limiter la casse vis-à-vis du client Après, tout découle de ce que j'ai déjà dit : tu diposes d'un jeu de données représentatif de la prod donc tu peux évaluer les impacts de tes modifs et donc écrire des scripts de migration des données. Y a pas de recette miracle : faut savoir d'où on part, où on veut arriver et quoi faire pour y arriver Tu éviteras donc judicieusement les drop table sans avoir fait une copie de la table avant, etc.

J'ai bien pensé à utiliser un CVS, mais je ne pense pas que ça gère les droits ? me trompe-je ?

Non, tu ne te trompes pas, c'est pas du tout fait pour ça ! CVS est un outil d'infrastructure je dirais, qui sert à assurer la qualité, la traçabilité, le travail collaboratif et les livraisons du code. C'est totalement indépendant de l'application que tu développes, du langage, de l'OS, etc. Donc pour tout ce qui est droit, c'est à toi de gérer par d'autres moyens comme par exemple des scripts de livraison.

Et puis pour les BD, je pense que c'est carrément pas adapté, voir impossible de le faire par CVS ...

Dans CVS, tu stockeras les fichiers de création des tables etc. et les scripts SQL de migration des données et du modèle. Tout comme le code, tu mettras dans CVS tes scripts de livraison.


Après tout ça, tu vas me dire que c'est le cirque, que ça va faire exploser les temps de développement et de livraison. C'est tout à fait vrai mais c'est le prix à payer pour la qualité, la sécurité et la satisfaction du client

[Hervé Saladin]

ouaouh ! déjà, première chose : MERCI pour ces explication claires et super détaillés, ca fait plaisir
Le coup du serveur d'intégration et des patch scriptés c'est bien vu, on sent l'experience ...
Je comprends parfaitement tout ce que ça peut m'apporter en terme de rigueur et de fiabilité des maj.
Reste deux petits problèmes :

1. Du coup, il faut non pas deux, mais TROIS serveurs en tout ... va falloir que je réussisse à convaincre mes chefs Juste après avoir obtenu le 2e, ca va être un peu délicat à ammener mais bon, qui ne tente rien n'a rien, et puis tes arguments tiennent la route

2. Après tout ça, tu vas me dire que c'est le cirque, que ça va faire exploser les temps de développement et de livraison. C'est tout à fait vrai mais c'est le prix à payer pour la qualité, la sécurité et la satisfaction du client

   mmmh, je n'aurais pas osé te le dire étant donné l'effort que tu as fait pour le répondre, mais puisque c'est toi qui en parle : c'est éxactement ce que je me disais en te lisant. Faut savoir quand même que je ne bosse pas dans une SSII avec des clients, mais pour une administration ... donc niveau "satisfaction du client" c'est un peu moins éxigeant : je me fais harceler quand "ça marche pas" mais ça risque pas de faire couler la boîte. Par contre on me met la pression sur les délais ...
   
   D'ou une autre question : y'a t'il des moyens pour "industrialiser" (au moins en partie) la production de mes patchs de maj ? Par exemple : un outil qui me ferait en trois coup de cuillère à pot un script pour aller positionner mes droits ? un qui serait capable de générer un script SQL des modifs effectuées sur les BD depuis telle date d'apres les logs de mysql ? ou ce genre de trucs, quoi ...
   Bref : comment ne pas perdre trop de temps avec ça en l'automatisant dans la limite du possible ?

Je sais que j'en demande beaucoup, mais bon en même temps je veux être bien au point : si je réussis à avoir un 3e serv, et qu'au final mes devs prennent deux fois plus de temps, ça risque de pas très bien passer
Et puis, quand je serais bien rodé sur ce genre de méthode, ça me servira bien sur le long terme, et ça ça interesse bigrement le p'tit jeunot que je suis ... (au boulot, je peux compter que sur moi-même, j'ai pas de vieux briscard qui peut me transmettre son experience du developpement, alors j'en profite ... )


Merci pour tout

[_Mac_]

Du coup, il faut non pas deux, mais TROIS serveurs en tout ... va falloir que je réussisse à convaincre mes chefs Juste après avoir obtenu le 2e, ca va être un peu délicat à ammener mais bon, qui ne tente rien n'a rien, et puis tes arguments tiennent la route

Le serveur d'intégration, c'est pas nécessairement une machine réservée à cet usage mais plutôt des serveurs Web et de base de données réservés. Donc si tu as ta machine de dev, c'est très bien, tu peux l'utiliser aussi pour l'intégration : installe 2 serveurs Web et 2 bases de données : tu réserves un couple serveur Web + bdd pour le développement et un autre couple serveur Web + bdd pour l'intégration. Ce qu'il faut, c'est 2 choses :

• S'assurer que tu n'utilises pas l'intégration pour autre chose que des tests. Par exemple, tu fais un test d'intégration. Tu t'aperçois qu'il y a un pb, une migration de données qui se passe mal. Qu'est-ce que tu fais ? Surtout tu ne débogues pas sur l'environnement d'intégration pour ne pas le polluer : tu reproduis le pb en dev, tu corriges en dev, tu restaures l'intégration dans son état proche de la prod et tu retestes en intégration. Ca fait des allers et retours compliqués mais c'est ça, la qualité
• Etre capable, au moment d'entrer en phase d'intégration, de restaurer un environnement d'intégration propre, c'est-à-dire propre et le plus proche possible de la prod. Par expérience, les environnements d'intégration se "salissent" au fur et à mesure de leur utilisation (mais moins vite que les environnements de dev), donc faut faire du nettoyage de temps en temps pour toujours respecter ce principe d'avoir un environnement représentatif de la prod.

Et après, un environnement d'intégration, ce n'est pas une obligation. C'est un moyen de s'assurer qu'on ne va pas rencontrer trop de pbs en passant en prod. Si tu utilises bien ton environnement de développement, que tu t'assures, au moment de commencer un nouveau cycle de développement, qu'il est proche de l'environnement de prod, tu peux te contenter de cet unique environnement supplémentaire.

Par contre on me met la pression sur les délais ...

Tout est histoire de compromis par rapport à la criticité des données : si tes clients (même si tu n'es pas en SSII, on peut parler de clients : ce sont les donneurs d'ordre) sont prêt à accepter qu'il peut y avoir des bugs, des régressions et éventuellement qu'on soit obligé de restaurer des données, donc de perdre le travail de 1 ou 2 jours, pourquoi pas zapper la phase d'intégration pour aller plus vite. Mais c'est risqué, je trouve. Et il me semble que dans l'administration, quand on parle de délai, on s'autorise une certaine marge de manoeuvre. Me trompe-je ?

D'ou une autre question : y'a t'il des moyens pour "industrialiser" (au moins en partie) la production de mes patchs de maj ?

Pas à ma connaissance mais je ne connais pas tout et mon expérience en la matière remonte à qq années déjà (oh, le vieux, d'un coup ). D'expérience, tu écris toi-même tes scripts et tu les adaptes d'une livraison à une autre. C'est donc du temps à prévoir en plus de tes développements, malheureusement.

Je sais que j'en demande beaucoup, mais bon en même temps je veux être bien au point : si je réussis à avoir un 3e serv, et qu'au final mes devs prennent deux fois plus de temps, ça risque de pas très bien passer

Comme je te le disais, un 3ème serveur n'est pas obligatoire (tu peux faire tourner dév et intégration sur la même machine), de même qu'un 3ème environnement n'est pas obligatoire. Seulement, faut savoir ce qu'on veut. C'est clair qu'en SSII, un client va s'attendre à un certain niveau de qualité et de fiabilité. Dans ton cas, je ne sais pas, fait transiger.

Et puis tu peux y aller progressivement, plutôt que d'y aller d'un coup CVS + intégration + scripts de déploiement et d'avoir à gérer beaucoup de changements à la fois. Tu peux commencer par mettre en place CVS. Quand tu es familiarisé avec la bête, tu passes aux scripts, mais là, tu verras que pour tester tes scripts, il te faudra un serveur identique à la prod, donc quelque part un environnement d'intégration

[Hervé Saladin]

Encore merci !
Oui, je comprends bien que je ne suis pas obligé d'utiliser un 3e serv, et qu'il faut savoir s'adapter ...
Mais c'est vrai qu'avoir un serveur d'intégration pour tester et appliquer des patches bien propres sur le serveur de production, ça serait quand même le top

Tout est histoire de compromis par rapport à la criticité des données : si tes clients (même si tu n'es pas en SSII, on peut parler de clients : ce sont les donneurs d'ordre) sont prêt à accepter qu'il peut y avoir des bugs, des régressions et éventuellement qu'on soit obligé de restaurer des données, donc de perdre le travail de 1 ou 2 jours, pourquoi pas zapper la phase d'intégration pour aller plus vite. Mais c'est risqué, je trouve.

Je trouve aussi.
Quand à mes "clients" ils veulent que ça aille vite ET que ça ne buggue pas, ET aussi que je devine les besoins qu'ils ne sont pas capables d'exprimer, ET que je sache quoi faire quand ils demande une nouvelle fonctionnalité résumée en une ligne dans un mail ... bref, il faut que ça soit magique ...

Et il me semble que dans l'administration, quand on parle de délai, on s'autorise une certaine marge de manoeuvre. Me trompe-je ?

Non, tu ne te trompes pas. Il est vrai que les retards sur le planning n'ont pas des conséquences dramatiques.
Mais c'est déjà insupportable quand on me reproche les retards dus à l'absence de gestion des projets, au manque d'expression des besoins, ou aux modifs sur le CDC en cours de développement (voire même après) ... mais bon, je suppose qu'on est un peu tous logés à la même enseigne :s

Comme je te le disais, un 3ème serveur n'est pas obligatoire (tu peux faire tourner dév et intégration sur la même machine), de même qu'un 3ème environnement n'est pas obligatoire. Seulement, faut savoir ce qu'on veut.

Mes utilisateurs ne savent pas ce qu'ils veulent, mais ils veulent tout, tout de suite, pour pas un rond, et que ça soit parfait. Si ça n'est pas parfait, ou pas tout de suite, c'est forcément de ma faute ! (après tout, je ne suis qu'un salaud d'informaticien, donc mon unique but dans la vie est de leur pourrir la leure)
Bref, je m'égare un peu !
Pour ce qui est de faire touner dev et intégration sur la même machine, ça vient de me donner une idée : je pense que je vais essayer de faire tourner sur le serv de dev une image du serv de prod sous vmWare qui servira à l'intégration. En ajoutant une petite tâche cron (ou assimilé) qui écrase l'image chaque soir avec une copie toute fraiche du serv de prod, je suis sur d'avoir un serv d'intégration toujours bien propre et bien identique à l'environnement de prod.
En plus, si jamais je foire une maj qui "casse tout" sur le serv d'intégration, ca sera très facile de le restaurer d'après l'image de la veille

Et puis tu peux y aller progressivement, plutôt que d'y aller d'un coup CVS + intégration + scripts de déploiement et d'avoir à gérer beaucoup de changements à la fois. Tu peux commencer par mettre en place CVS. Quand tu es familiarisé avec la bête, tu passes aux scripts

Oui, je pense en effet que c'est mieux d'y aller pas à pas

Bon, et bien merci beaucoup pour tous ces conseils, _Mac_, grâce à toi je commence à avoir une idée plus précise de la façon dont je vais m'organiser

Si d'autres ont des compléments à ajouter, un peu de leur expérience perso de ce genre de problème à me donner, des outils à me conseiller, des astuces etc ... n'hésitez pas !

Encore merci

[_Mac_]

Pour ce qui est de faire touner dev et intégration sur la même machine, ça vient de me donner une idée : je pense que je vais essayer de faire tourner sur le serv de dev une image du serv de prod sous vmWare qui servira à l'intégration.

C'est une excellente idée. Si tu as la possibilité de faire ça, ça serait top

Bon courage en tout cas.