4.4Deployment: installation & automatic update
The essentials in 30 seconds
- The WinDev delivery chain: executable generation (32/64-bit configuration), element library, installation program generated by a wizard (files, shortcuts, prerequisites, database, uninstallation) and automatic update.
- ⚠️ Do not forget anything: the executable alone is not enough — you need the WinDev framework, the native database access, images, reports, resources and configuration files; an incomplete deployment results in errors at startup on the customer's machine.
- ⚠️ Golden rule: test the installation on a CLEAN MACHINE, different from the development workstation; for an update, back up the data first, test on a copy and provide a rollback.
Mini-case thread — Yacine delivers his trading management application to the customer
Yacine, a WinDev developer at an electrical equipment trading SME in Oran, must deliver his management application to the company's workstations. He first generates the executable in the right configuration, then creates the installation program with the wizard: files, shortcuts, prerequisites, database creation, uninstallation. He checks that everything is included — WinDev framework, native database access, images, reports, configuration files. Then he tests the installation on a clean machine, different from his development workstation: that is where he discovers that his own machine 'accidentally' had an element that was missing elsewhere. He also configures automatic update so that the application detects and installs new versions. For the first production update, he backs up the data beforehand, tests the structure conversion on a copy of the real data, schedules the intervention outside critical hours and provides a rollback. He notes the reflex: never send an executable without having installed it on a clean machine.
Standalone case for this section: it returns in the course, the diagram, the script and the 48h challenge of section 4.4.
1. The delivery chain
Developing is one thing, delivering is another. WinDev provides a complete chain. (1) Generation of the executable: the program is produced from the project, choosing the configuration (32/64 bits, options). (2) The library: the project elements (windows, reports, queries) can be packaged into a file accompanying the executable. (3) The installation program: a wizard generates a complete installer (files, shortcuts, prerequisites, database, uninstallation). (4) Automatic update: an integrated mechanism lets the deployed application detect and install a new version — a considerable comfort as soon as there are more than a few workstations.
2. Forget nothing, test on a clean machine
The watch points of a successful deployment. (1) Forget nothing: the executable alone is generally not enough — you need the WinDev framework (runtime libraries), native database access, images and resources, reports, configuration files, special fonts. An incomplete deployment shows up as errors at startup. (2) Test on a clean machine, different from the development workstation: it is the only way to spot what you have 'in excess' on your machine — it is the golden rule of deployment. Your workstation already contains everything, the application necessarily works there, which masks what is missing.
3. Manage data and updates
Data requires particular attention. Distinguish the first installation (create the database) from the update (preserve the data and possibly evolve the structure — a delicate operation). For any production update: back up beforehand, test on a copy of the real data, schedule outside critical hours and provide a rollback. Also think about the necessary rights (installation, writing to certain folders), standard system locations, and inform users of what changes.
🔎 Concrete example — 🔎 Concrete example — The delivery chain
The delivery steps, as Yacine follows them:
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 droitsReading: delivery is not 'copy the executable': it is a chain that goes from generation to automatic update.
Lesson: the clean-machine test is what distinguishes a successful deployment from a failure in front of the user.
Section vocabulary
- Executable generation
- Produce the program from the project, choosing the configuration (32/64 bits, options) — the first delivery step.
Simple example: Yacine generates the executable of his trading application.
What it is not: sending the source project to the customer.
Reflex: produce the program → generation.
- Installation program
- The installer generated by a wizard: it places the files, creates shortcuts, installs prerequisites, prepares the database and handles uninstallation.
Simple example: Yacine generates the installer with the WinDev wizard.
What it is not: copying the files by hand to each workstation.
Reflex: install cleanly → the installation program.
- Automatic update
- Integrated mechanism allowing the deployed application to detect and install a new version.
Simple example: Yacine configures automatic update for the six workstations.
What it is not: manually reinstalling each workstation for every version.
Reflex: distribute a version → automatic update.
- Clean-machine test (⚠️)
- The golden rule: test the installation on a machine different from the development workstation, the only way to spot missing elements (framework, native access, resources).
Simple example: Yacine installs on a clean machine and discovers a forgotten native access.
What it is not: testing only on his development workstation.
Reflex: reveal what is missing → the clean-machine test.
- Data structure evolution
- During an update, existing data must be preserved and its structure possibly modified — a delicate operation, to be backed up and tested.
Simple example: Yacine converts the structure on a copy of the real data before deploying.
What it is not: modifying the structure directly in production without a backup.
Reflex: evolve without losing → the tested structure evolution.
In practice — In practice — Deploy an application
- Generate the executable in the right configuration, then create the installation program with the wizard (files, shortcuts, prerequisites, database), like Yacine.
- Check that everything is included: WinDev framework, native database access, images, reports, resources, configuration files.
- Test the installation on a clean machine, different from your development workstation — the only way to detect what is missing.
- Distinguish first installation (create the database) from update (preserve the data, evolve the structure); back up before any update and provide a rollback.
Step-by-step script — deploy like Yacine (5 min)
1) Generate the executable (32/64-bit configuration). 2) Create the installation program with the wizard (files, shortcuts, prerequisites, database). 3) Check for the presence of the framework, native access, images, reports and configuration files. 4) Install on a clean machine and note everything that is missing. 5) Configure automatic update. 6) For a production update: back up, test the conversion on a copy of the real data, schedule outside critical hours and prepare a rollback.
Never deliver an executable without having installed it on a clean machine: your development workstation masks what is missing.
Copy-paste template — my deployment sheet
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 arriereGenerated installer
Yacine generates a complete installer with the WinDev wizard.
Clean-machine test
Yacine installs on a clean machine and spots a missing framework.
Automatic update
Yacine configures the application to detect and install new versions.
Rollback
Yacine prepares a fallback solution if the new version causes problems.
✓ Best practices
- Check that nothing is missing (framework, native access, resources).
- Test on a clean machine, never only on your own workstation.
- For an update: back up, test on a copy, provide a rollback.
✗ Common pitfalls
- Delivering the executable alone and believing it is enough.
- Testing only on the development workstation.
- Updating without a backup or a test on a copy.
Key takeaways
- The delivery chain: generation, library, installer, automatic update.
- ⚠️ Forget nothing: framework, native access, images, reports, configuration, fonts.
- ⚠️ Golden rule: test the installation on a clean machine.
- Manage data: back up before an update, test on a copy, provide a rollback.
48h challenge — apply it tomorrow
Like Yacine, generate the executable of your application and create its installation program. Install it on a clean machine (or a clean virtual machine) and note everything that is missing: framework, native access, images, reports, fonts. Fix the installer until the installation is clean. Then configure automatic update and, if your database must evolve, test the conversion on a copy of the real data while keeping a rollback.
- I generate the executable and create an installation program.
- I check that nothing is missing and I test on a clean machine.
- I manage data during updates, with backup and rollback.
Frequently asked questions
Why is testing the installation on a clean machine essential?
Because your development workstation already contains everything needed (framework, drivers, native access, fonts, components): the application necessarily works there, which masks everything that will be missing at the customer's site — only a clean-machine test reveals the truth. What the test reveals: missing or incomplete framework, undeployed native access, forgotten resources (images, reports, configuration, templates), absent fonts, insufficient rights, different regional settings, hard-coded paths. It is the no. 1 cause of failed deployments, and it is discovered at the worst moment: delivery day.
How do you manage updates to an application already in production?
With method: back up the data beforehand, test the update on a copy, plan for structure evolution, schedule outside critical hours, inform users and keep a rollback option. The specific challenges of an update: there is real data to preserve, the structure may have evolved (new items, changed types) and a failure is immediately visible. Back up, test on a representative copy (an artificial test set does not reveal accumulated special cases), check that nobody is using the application, deploy, then check the main functions and some known data.
What is the golden rule before delivering a WinDev application?