Discussion :

[mbaum]

Bonjour à la communauté,


Je suis ravi de partager mon nouveau projet open-source, AppWatcher : https://github.com/mbaumsti/Delphi-App-Watcher


Avez-vous déjà rencontré la difficulté de gérer des dizaines d'applications Delphi fonctionnant sur plusieurs machines du réseau ? Trouver un créneau horaire convenable pour remplacer les exécutables peut être un véritable casse-tête. C'est pourquoi j'ai développé AppWatcher.
AppWatcher est un composant Delphi et 2 applications qui vous permettent de contrôler à distance l'arrêt et le redémarrage de vos applications Delphi sur votre réseau.
Voici comment cela fonctionne :

1. Intégrez le composant TAppWatcherClient dans vos applications Delphi.
2. Déployez l'Agent AppWatcher sur vos machines clientes.
3. Utilisez l'application AppWatcher Master pour contrôler à distance toutes vos applications.

Fonctionnalités clés :

• Arrêtez à distance les applications avec des notifications utilisateur.
• Redémarrez automatiquement les applications après les mises à jour.
• Évitez d'utiliser RDP ou d'accéder physiquement à chaque machine.
• Minimisez les temps d'arrêt et rationalisez le processus de déploiement.

Si vous recherchez une solution pour simplifier la gestion d'applications à distance dans votre environnement Delphi, je vous encourage à découvrir AppWatcher. Les contributions et les commentaires sont les bienvenus !

[ShaiLeTroll]

Sinon, il existe des solutions de déploiement comme LANDesk software deployment portal ... normalement, cela devrait l'équipe Cloud Ops et Dev Ops de ta société qui devrait fournir ce genre d'outil avec toutes les sécurités possibles.
Je pense aussi à Ansible ou Jenkinsn idéal pour automatiser compilation, packaging et déploiement vers le Cloud après pour l'agent local, ça tu as un tas de prestataire qui en fournisse pour les sociétés qui investisse dans un gestionnaire d'asset avec outil de RMM Deployment.

Cela fait penser à PAServer sur le fonctionnement Master-Slave et sur l'inversion qui est Client Server lors de la négociation initiale de connexion, tu n'as pas de problème avec les FireWall, proxy voire les réseaux secondaires (plusieurs cartes réseau sur serveur), je déploie pas mal d'application non visible sur le réseau de l'entreprise, mais uniquement visible par des frontaux PHP/NodeJS/Python via un revert proxy NGINX, sinon derrière des fermes CITRIX idem, on déploie sur le master, pas du la prod active (du moins, je l'ai fait mais comme toi, j'ai développé mon outil, plus simpliste puisque LAN accessible)

Comment gères tu la sécurité, il y a des clés validées par des certficats à échanger lors de la communication pour éviter que n'importe qui puisse se connecter au Port et injecter n'importe quelle commande ou forcer un deny de service en saturant le port de données, prévoit éventuellement un throttling.

Comme tu échanges un record, je te recommande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TAppWatcherMessage = packed record

et veiller MINENUMSIZE au TAppWatcherCommand
Faudrait empêcher le code de se compiler en 32Bits aussi, car l'échange de HWnd change de taille entre 32 et 64 bits, sinon il te faut gérer un champ size supplémentaire dans le code pour déterminer quelle version du protocole utiliser.

Petite astuce syntaxique TAppWatcherStrCommand: array[0..10] of string = ... -> APP_WATCHER_COMMAND_STR: array[TAppWatcherCommand] of string = ... cela évite le Ord et en plus cela respecte le nommage conventionnel pour une constante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Function TAppWatcherMessage.CmdName : string;
begin
   Result := APP_WATCHER_COMMAND_STR[Command]; // à la place de // Result:=  TAppWatcherStrCommand[ord(Command)];
end;

On pourrait aussi faire cela sans constante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Function TAppWatcherMessage.CmdName : string;
begin
   Result := Copy(GetEnumName(TypeInfo(TAppWatcherCommand), Ord(Command)), Length('cmd') + 1);
end;

[mbaum]

Bonjour ShaiLeTroll,


Merci pour ton retour détaillé et tes remarques pertinentes !
Effectivement, AppWatcher est une solution très simple, pensée pour un besoin bien précis : gérer proprement le déploiement d'un exécutable sur un réseau local sans avoir à me soucier de sessions ouvertes ou de processus bloquants.

Dans ma boîte (30 personnes, petite structure), je n'ai pas de Cloud Ops / DevOps, ni d’outils comme Ansible ou Jenkins en place. Le but n'est pas de concurrencer des solutions industrielles, mais juste d’avoir un moyen efficace de remplacer une appli sur un partage réseau sans prise de tête.

Cela dit, tes remarques sur la sécurité sont intéressantes ! Même si je suis dans un réseau local derrière un pare-feu, je vais quand même renforcer certains points pour éviter tout risque d’abus. En tout cas certains me paraissent assez facile à mettre en place. Je me les note pour une prochaine mise à jour :

• Clé d’authentification
• Vérification des IP autorisées
• Gestion plus propre du format des messages (packed record, compatibilité 32/64 bits).
• Throttling

Je vais évidemment utiliser ton idée d’utiliser GetEnumName pour simplifier CmdName !
Bon j'ai du travail devant moi...

Encore merci pour ton retour !

[SergioMaster]

Ça me rappelait quelque chose !
J'ai testé, mais jamais "déployé" TWebUpdate de TMSSoftware, ce srait plus ou moins le même esprit ?

P.S. Le dépôt manque peut-être un peu d'images écrans pour appâter le client.
P.P.S je n'ai jamais compris PPrem (Patrick Prémartin) faisait pour mettre ses fichiers Readme en anglais et en français, ce serait un autre plus (ce n'est qu'une suggestion)

[mbaum]

TWebUpdate me semble plutôt conçu pour proposer une mise à jour à l'utilisateur lorsqu'une nouvelle version est disponible, ce qui implique une installation locale sur chaque machine. Ce n'est pas le cas dans mon approche.


De mon côté, je remplace directement l'exécutable sur un disque réseau auquel les utilisateurs accèdent via un lien.


Avantage : Je suis sûr que tout le monde utilise toujours la dernière version, ce qui est crucial dans mon cas, car mes applications sont liées à des bases de données. La moindre différence de version peut entraîner des problèmes graves pour les données.


Inconvénient : Ce type de déploiement impose que personne ne soit en train d'utiliser l'application au moment de la mise à jour, ce qui complique un peu la gestion.

Je note pour les images à ajouter et pour la traduction du readme en Français

[SergioMaster]

TWebUpdate est un composant à inclure directement dans le programme, mais oui ta solution m'aurait intéressé quand j'étais encore en activité, surtout que moi, j'étais en télétravail (et ce depuis 1998)
Longtemps, je demandais aux utilisateurs d'appliquer, via un .bat, les mises à jour en fonction de "l'image" des programmes sur le serveur, puis logmein à changer la donne et j'envoyais directment sur les divers postes les programmes modifiés mais c'était assez fastidieux (surtout avec 2 necessités : poste allumé et programme inutilisé)