4.4Déploiement : installation & mise à jour automatique
L'essentiel en 30 secondes
- La chaîne de livraison WinDev : génération de l'exécutable (configuration 32/64 bits), bibliothèque des éléments, programme d'installation généré par assistant (fichiers, raccourcis, prérequis, base, désinstallation) et mise à jour automatique.
- ⚠️ N'oubliez rien : l'exécutable seul ne suffit pas — il faut le framework WinDev, les accès natifs à la base, les images, états, ressources et fichiers de configuration ; un déploiement incomplet se traduit par des erreurs au démarrage chez le client.
- ⚠️ Règle d'or : tester l'installation sur une MACHINE VIERGE, différente du poste de développement ; pour une mise à jour, sauvegarder les données avant, tester sur une copie et prévoir un retour arrière.
Mini-cas filé — Yacine livre sa gestion de négoce chez le client
Yacine, développeur WinDev dans une PME de négoce de matériel électrique à Oran, doit livrer son application de gestion sur les postes de l'entreprise. Il génère d'abord l'exécutable dans la bonne configuration, puis crée le programme d'installation avec l'assistant : fichiers, raccourcis, prérequis, création de la base, désinstallation. Il vérifie que tout est inclus — framework WinDev, accès natifs à la base, images, états, fichiers de configuration. Puis il teste l'installation sur une machine vierge, différente de son poste de développement : c'est là qu'il découvre que son poste possédait « par accident » un élément qui manquait ailleurs. Il configure aussi la mise à jour automatique pour que l'application détecte et installe les nouvelles versions. Pour la première mise à jour en production, il sauvegarde les données avant, teste la conversion de structure sur une copie des données réelles, planifie l'intervention hors des heures critiques et prévoit un retour arrière. Il note le réflexe : ne jamais envoyer un exécutable sans l'avoir installé sur une machine vierge.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 4.4.
1. La chaîne de livraison
Développer est une chose, livrer en est une autre. WinDev fournit une chaîne complète. (1) La génération de l'exécutable : on produit le programme à partir du projet, en choisissant la configuration (32/64 bits, options). (2) La bibliothèque : les éléments du projet (fenêtres, états, requêtes) peuvent être empaquetés dans un fichier accompagnant l'exécutable. (3) Le programme d'installation : un assistant génère un installeur complet (fichiers, raccourcis, prérequis, base de données, désinstallation). (4) La mise à jour automatique : un mécanisme intégré permet à l'application déployée de détecter et d'installer une nouvelle version — un confort considérable dès qu'il y a plus de quelques postes.
2. N'oubliez rien, testez sur machine vierge
Les points de vigilance d'un déploiement réussi. (1) N'oubliez rien : l'exécutable seul ne suffit généralement pas — il faut le framework WinDev (les bibliothèques d'exécution), les accès natifs à la base, les images et ressources, les états, les fichiers de configuration, les polices particulières. Un déploiement incomplet se manifeste par des erreurs au démarrage. (2) Testez sur une machine vierge, différente du poste de développement : c'est la seule façon de repérer ce que vous avez « en trop » sur votre machine — c'est la règle d'or du déploiement. Votre poste contient déjà tout, l'application y fonctionne forcément, ce qui masque les manques.
3. Gérer les données et les mises à jour
Les données demandent une attention particulière. Distinguez la première installation (créer la base) de la mise à jour (préserver les données et éventuellement faire évoluer la structure — opération délicate). Pour toute mise à jour en production : sauvegardez avant, testez sur une copie des données réelles, planifiez hors des heures critiques et prévoyez un retour arrière. Pensez aussi aux droits nécessaires (installation, écriture dans certains dossiers), aux emplacements standards du système, et informez les utilisateurs de ce qui change.
🔎 Exemple concret — 🔎 Exemple concret — La chaîne de livraison
Les étapes de la livraison, comme les suit Yacine :
Chaine de livraison WinDev :
1) Generer l'executable (configuration 32/64 bits)
2) Bibliotheque : fenetres, etats, requetes empaquetes
3) Programme d'installation (assistant) : fichiers, raccourcis,
prerequis, base, desinstallation
4) Mise a jour automatique : l'application detecte et installe
la nouvelle version
REGLE D'OR : tester l'installation sur une MACHINE VIERGE
-> revele le framework manquant, les acces natifs,
les ressources, les polices, les droitsLecture : la livraison n'est pas « copier l'exécutable » : c'est une chaîne qui va de la génération à la mise à jour automatique.
Leçon : le test sur machine vierge est ce qui distingue un déploiement réussi d'un échec devant l'utilisateur.
Vocabulaire de la section
- Génération de l'exécutable
- Produire le programme à partir du projet, en choisissant la configuration (32/64 bits, options) — première étape de la livraison.
Exemple simple : Yacine génère l'exécutable de son application de négoce.
Ce que ce n'est pas : envoyer le projet source au client.
Réflexe : produire le programme → la génération.
- Programme d'installation
- L'installeur généré par assistant : il pose les fichiers, crée les raccourcis, installe les prérequis, prépare la base et gère la désinstallation.
Exemple simple : Yacine génère l'installeur avec l'assistant de WinDev.
Ce que ce n'est pas : copier les fichiers à la main sur chaque poste.
Réflexe : installer proprement → le programme d'installation.
- Mise à jour automatique
- Mécanisme intégré permettant à l'application déployée de détecter et d'installer une nouvelle version.
Exemple simple : Yacine configure la MAJ automatique pour les six postes.
Ce que ce n'est pas : réinstaller manuellement chaque poste à chaque version.
Réflexe : diffuser une version → la mise à jour automatique.
- Test sur machine vierge (⚠️)
- La règle d'or : tester l'installation sur une machine différente du poste de développement, seule façon de repérer les éléments manquants (framework, accès natifs, ressources).
Exemple simple : Yacine installe sur une machine propre et découvre un accès natif oublié.
Ce que ce n'est pas : tester uniquement sur son poste de développement.
Réflexe : révéler les manques → le test sur machine vierge.
- Évolution de la structure de données
- Lors d'une mise à jour, les données existantes doivent être préservées et leur structure éventuellement modifiée — opération délicate, à sauvegarder et tester.
Exemple simple : Yacine convertit la structure sur une copie des données réelles avant de déployer.
Ce que ce n'est pas : modifier la structure directement en production sans sauvegarde.
Réflexe : faire évoluer sans perdre → l'évolution de structure testée.
En pratique — En pratique — Déployer une application
- Générez l'exécutable dans la bonne configuration, puis créez le programme d'installation avec l'assistant (fichiers, raccourcis, prérequis, base), comme Yacine.
- Vérifiez que tout est inclus : framework WinDev, accès natifs à la base, images, états, ressources, fichiers de configuration.
- Testez l'installation sur une machine vierge, différente de votre poste de développement — la seule façon de détecter ce qui manque.
- Distinguez première installation (créer la base) et mise à jour (préserver les données, faire évoluer la structure) ; sauvegardez avant toute mise à jour et prévoyez un retour arrière.
Script pas-à-pas — déployer comme Yacine (5 min)
1) Générez l'exécutable (configuration 32/64 bits). 2) Créez le programme d'installation avec l'assistant (fichiers, raccourcis, prérequis, base). 3) Vérifiez la présence du framework, des accès natifs, des images, états et fichiers de configuration. 4) Installez sur une machine vierge et notez tout ce qui manque. 5) Configurez la mise à jour automatique. 6) Pour une mise à jour en production : sauvegardez, testez la conversion sur une copie des données réelles, planifiez hors heures critiques et préparez un retour arrière.
Ne livrez jamais un exécutable sans l'avoir installé sur une machine vierge : votre poste de développement masque les manques.
Modèle copier-coller — ma fiche déploiement
Generation : executable (configuration 32/64 bits)
Bibliotheque: fenetres, etats, requetes empaquetes
Installeur : assistant (fichiers, raccourcis, prerequis, base)
MAJ auto : l'application detecte et installe la nouvelle version
Ne rien oublier : framework, acces natifs, images, etats, config, polices
REGLE D'OR : test sur MACHINE VIERGE (jamais le poste de dev)
Mise a jour : sauvegarder AVANT, tester sur COPIE, retour arriereInstalleur généré
Yacine génère un installeur complet avec l'assistant de WinDev.
Test machine vierge
Yacine installe sur une machine propre et repère un framework manquant.
Mise à jour automatique
Yacine configure l'application pour détecter et installer les nouvelles versions.
Retour arrière
Yacine prépare une solution de repli si la nouvelle version pose problème.
✓ Bonnes pratiques
- Vérifier que rien ne manque (framework, accès natifs, ressources).
- Tester sur une machine vierge, jamais seulement sur son poste.
- Pour une MAJ : sauvegarder, tester sur une copie, prévoir un retour arrière.
✗ Pièges fréquents
- Livrer l'exécutable seul en croyant que cela suffit.
- Tester uniquement sur le poste de développement.
- Mettre à jour sans sauvegarde ni test sur copie.
Points clés à retenir
- La chaîne de livraison : génération, bibliothèque, installeur, mise à jour automatique.
- ⚠️ N'oubliez rien : framework, accès natifs, images, états, configuration, polices.
- ⚠️ Règle d'or : tester l'installation sur une machine vierge.
- Gérer les données : sauvegarder avant une MAJ, tester sur une copie, prévoir un retour arrière.
Défi 48h — appliquez demain
Comme Yacine, générez l'exécutable de votre application et créez son programme d'installation. Installez-le sur une machine vierge (ou une machine virtuelle propre) et notez tout ce qui manque : framework, accès natifs, images, états, polices. Corrigez l'installeur jusqu'à ce que l'installation soit propre. Configurez ensuite la mise à jour automatique et, si votre base doit évoluer, testez la conversion sur une copie des données réelles en gardant un retour arrière.
- Je génère l'exécutable et crée un programme d'installation.
- Je vérifie que rien ne manque et je teste sur machine vierge.
- Je gère les données en mise à jour, avec sauvegarde et retour arrière.
Questions fréquentes
Pourquoi tester l'installation sur une machine vierge est-il indispensable ?
Parce que votre poste de développement contient déjà tout ce qu'il faut (framework, pilotes, accès natifs, polices, composants) : l'application y fonctionne forcément, ce qui masque tout ce qui manquera chez le client — seul un test sur machine vierge révèle la vérité. Ce que le test révèle : framework manquant ou incomplet, accès natifs non déployés, ressources oubliées (images, états, configuration, modèles), polices absentes, droits insuffisants, paramètres régionaux différents, chemins codés en dur. C'est la cause n°1 des déploiements ratés, et elle se découvre au pire moment : le jour de la livraison.
Comment gérer les mises à jour d'une application déjà en production ?
Avec méthode : sauvegarder les données avant, tester la mise à jour sur une copie, prévoir l'évolution de la structure, planifier hors des heures critiques, informer les utilisateurs et garder une possibilité de retour arrière. Les enjeux spécifiques d'une mise à jour : il existe des données réelles à préserver, la structure a peut-être évolué (nouvelles rubriques, types modifiés) et un échec est visible immédiatement. Sauvegardez, testez sur une copie représentative (un jeu de test artificiel ne révèle pas les cas particuliers accumulés), vérifiez que personne n'utilise l'application, déployez, puis contrôlez les fonctions principales et quelques données connues.
Quelle est la règle d'or avant de livrer une application WinDev ?