PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WEBDEV 2024 → Qui utilise le déploiement à chaud
Qui utilise le déploiement à chaud
Débuté par Roumegou, 30 mar. 2020 18:13 - 6 réponses
Posté le 30 mars 2020 - 18:13
Bonjour

tout est dans le sujet ?

car je suis persuadé que c'est inutilisable.
donc qui l'utilise avec succès dans la vraie vie ?

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Membre enregistré
59 messages
Popularité : +3 (3 votes)
Posté le 31 mars 2020 - 10:42
Bonjour Mr. Roumegou,

(nous sommes en 24, on ne passera pas en 25).

On l'utilise....avec des pincettes.... en fait non, cela marche bien, a condition de respecter certaines choses.

Si vous décidez d'utiliser a chaud il y a des choses a ne pas faire :
- changer d'avis car il faudra effacer le site a partir du serveur de déploiement et re-installer car les 2 ne cohabitent pas. particulièrement si vous revenez en mode déconnexion , le serveur d'application démarrera a partir de la derniere version.
- ne mettez pas votre ini dans votre repertoire : fRepWeb car cela vous obligerait a le copier dans la nouvelle version a chaque fois... ( ini ou tout fichier image, etc... Utilisez Fdatadir plutot.

Cela marche bien pour des deploiements reguliers. Bien sur si vous faites un changement de structure de bases de donnees, analyse il faudra déconnecter les employées mais c est normal, cela fait parti des maintenances lourdes.
Sinon corrections bugs, ameliorations etc., ca marche pour nous.

Cordialement,
Xavier
Membre enregistré
1 623 messages
Popularité : +100 (114 votes)
Posté le 31 mars 2020 - 11:10
Hello,

Moi je ne l'utilise pas mais j'utilise une methode "perso" qui fonctionne dans CERTAINS cas :
Lorsque je modifie UNIQUEMENT le code serveur (ou une procédure serveur LOCALE) d'une ou plusieurs page, je met a jour manuellement uniquement le fichier .awl qui la concerne.

Exemple:
Je change le comportement d'un bouton en code serveur sur la page PAGE_MaPage alors je remplace le fichier PAGE_MaPage.awl sur le serveur.
L'utilsateur, lors de sa prochaine visite (ouverture d'une nouvelle session) aura alors la nouvelle version, sans deconnexion.

Bien entendu, si on modifie une procédure navigateur, une procédure GLOBALE ou la structure visuelle de la page.. çà ne fonctionne pas.

Ca m'aide pas mal lors de petits correctifs.
Membre enregistré
384 messages
Popularité : +13 (13 votes)
Posté le 31 mars 2020 - 12:04
Bonjour,

Je n'ai pas de projets en 23+, donc je ne peux utiliser cette méthode de déploiement.

Mais pour avoir regardé la documentation et ce que ce déploiement à chaud est censé faire, je me suis rendu compte que j'utilisais déjà un système similaire avec un peu de configuration Apache :
- J'ai le même projet installé sous deux noms différents dans l'administrateur WB (SITEA, SITEB)
- Apache est configuré pour servir SITEA quand on accède à "SITE", et met en place un cookie de session "Version: SITEA"
- Quand je dois déployer une nouvelle version, je mets d'abord à jour SITEB
- Grâce à un petit fichier, j'oblige alors Apache à rediriger les nouvelles sessions (celles qui n'ont pas encore de cookie "Version") vers SITEB.
- J'attends que les sessions sur SITEA expirent petit à petit, quand il n'y en a plus je mets à jour SITEA
- J'enlève ensuite le fichier de redirection, et les nouvelles sessions reviennent sur SITEA.

Ca demande un peu de gymnastique (ou de de script pour détecter quand il n'y a plus de sessions sur SITEA et faire la maj automatiquement), mais c'est plutôt efficace pour les mises à jour mineures : ça ne coupe personne en cours de route et pour les utilisateurs qui ont absolument besoin de la mise à jour, il leur suffit de se déconnecter et se reconnecter au site. Pour celles incluant une modif de la base de données par contre, je coupe les deux versions et les met à jour en même temps.

@François

J'ai pas mal utilisé ce type de déploiement "partiel", efficace quand il s'agit d'une toute petite modif de code. J'ai remarqué par contre que certaines fois, même en modifiant un tout petit truc, les alias des chaînes étaient régénérés et la page perdait la moitié de ses traductions (dans le cas d'un projet multilangues). Aussi, cette méthode fait crasher les sessions existantes qui essaieraient d'accéder à la page en question (en tout cas en utilisant les PageAffiche, mais peut-être qu'avec des PageUtilise qui ferment les contextes des pages précédentes, ça marche mieux ? A tester...). Depuis que j'ai mis en place la solution au-dessus, je préfère donc ne plus m'embêter avec cette méthode.
Posté le 01 avril 2020 - 17:21
Merci beaucoup à tous pour vos réponses

oui le coup "je décide au debut du mode et je ne reviens plus dessus"
on l'a subi plus d'une fois depuis la 24 et cela nous a refroidit (pour
le "à chaud" ouarf !)
Et ces répertoires multiples aux vues de tout ce que l'on peut avoir à
administrer y compris en dehors de Webdev sous l'_WEB; cela complique
encore les choses.

Mais le plus embêtant c'est que l'on perd la notion du déploiement "à
la page"

Mais bon je suis content de voir l'expérience de Xavier qui l'utilise
donc avec succès.
Il faudra que l'on se repenche dessus.

Après, gérer soit même la copie des fichiers ... à voir mais je ne me
voit pas utiliser cette méthode sans développer un outil pour le faire.

Mais toutes ces expériences sont interessantes et globalement je pense
que peu d'utilisateurs WB ont adapté le mode "à chaud"
Bonjour,

Je n'ai pas de projets en 23+, donc je ne peux utiliser cette méthode de
déploiement.

Mais pour avoir regardé la documentation et ce que ce déploiement à chaud est
censé faire, je me suis rendu compte que j'utilisais déjà un système
similaire avec un peu de configuration Apache : - J'ai le même projet
installé sous deux noms différents dans l'administrateur WB (SITEA, SITEB)
- Apache est configuré pour servir SITEA quand on accède à "SITE", et met en
place un cookie de session "Version: SITEA"
- Quand je dois déployer une nouvelle version, je mets d'abord à jour SITEB
- Grâce à un petit fichier, j'oblige alors Apache à rediriger les nouvelles
sessions (celles qui n'ont pas encore de cookie "Version") vers SITEB.
- J'attends que les sessions sur SITEA expirent petit à petit, quand il n'y
en a plus je mets à jour SITEA
- J'enlève ensuite le fichier de redirection, et les nouvelles sessions
reviennent sur SITEA.

Ca demande un peu de gymnastique (ou de de script pour détecter quand il n'y
a plus de sessions sur SITEA et faire la maj automatiquement), mais c'est
plutôt efficace pour les mises à jour mineures : ça ne coupe personne en
cours de route et pour les utilisateurs qui ont absolument besoin de la mise
à jour, il leur suffit de se déconnecter et se reconnecter au site. Pour
celles incluant une modif de la base de données par contre, je coupe les deux
versions et les met à jour en même temps.

@François

J'ai pas mal utilisé ce type de déploiement "partiel", efficace quand il
s'agit d'une toute petite modif de code. J'ai remarqué par contre que
certaines fois, même en modifiant un tout petit truc, les alias des chaînes
étaient régénérés et la page perdait la moitié de ses traductions (dans le
cas d'un projet multilangues). Aussi, cette méthode fait crasher les sessions
existantes qui essaieraient d'accéder à la page en question (en tout cas en
utilisant les PageAffiche, mais peut-être qu'avec des PageUtilise qui ferment
les contextes des pages précédentes, ça marche mieux ? A tester...). Depuis
que j'ai mis en place la solution au-dessus, je préfère donc ne plus
m'embêter avec cette méthode.


--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Membre enregistré
384 messages
Popularité : +13 (13 votes)
Posté le 01 avril 2020 - 17:47
Bonjour,

Mais toutes ces expériences sont interessantes et globalement je pense
que peu d'utilisateurs WB ont adapté le mode "à chaud"


Je pense malheureusement qu'il est arrivé un peu "trop tard". Les devs qui en avaient besoin avant (comme moi) ont trouvé d'autres astuces pour gérer cela autrement. Les autres pour qui ça n'embête pas d'avoir une coupure ou des déconnexions se suffisaient déjà de la méthode actuelle. Et obliger à tout réinstaller a dû refroidir une certaine partie des personnes qui s'interrogeaient sur le sujet. Au final ça ne laisse pas grand-monde...
Posté le 01 avril 2020 - 19:53
Bonjour,

Mais toutes ces expériences sont interessantes et globalement je pense
que peu d'utilisateurs WB ont adapté le mode "à chaud"

Je pense malheureusement qu'il est arrivé un peu "trop tard". Les devs qui en
avaient besoin avant (comme moi) ont trouvé d'autres astuces pour gérer cela
autrement. Les autres pour qui ça n'embête pas d'avoir une coupure ou des
déconnexions se suffisaient déjà de la méthode actuelle. Et obliger à tout
réinstaller a dû refroidir une certaine partie des personnes qui
s'interrogeaient sur le sujet. Au final ça ne laisse pas grand-monde...


tout à fait d'accord avec toi
trop clivant par rapport à ce qui se faisait avant

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus