Deploying frequent changes of a software
Hi,
I have an inhouse developed application which changes frequently (say once in couple of days). Most of the time the changes contain 1-2 file changes or a bunch of reigistry key changes. I have the initial version deployed as an msi using Managesoft (software dist tool). What is the best method to push the new changes thereafter?
Example:
I have software called MyApp 1.2 which I installed on all desktops using a software dist tool using an msi. The application is changed after couple of days to fix/enhance a feature. The changes involve only a file change and a set of registry key changes. Is there any way to push these changes with out uninstalling and installing the application. These type of changes happen frequently say every 3-4 days. So I don't want to uninstall and install the appm rather want just deploy the changes.
Thanks.
I have an inhouse developed application which changes frequently (say once in couple of days). Most of the time the changes contain 1-2 file changes or a bunch of reigistry key changes. I have the initial version deployed as an msi using Managesoft (software dist tool). What is the best method to push the new changes thereafter?
Example:
I have software called MyApp 1.2 which I installed on all desktops using a software dist tool using an msi. The application is changed after couple of days to fix/enhance a feature. The changes involve only a file change and a set of registry key changes. Is there any way to push these changes with out uninstalling and installing the application. These type of changes happen frequently say every 3-4 days. So I don't want to uninstall and install the appm rather want just deploy the changes.
Thanks.
0 Comments
[ + ] Show comments
Answers (7)
Please log in to answer
Posted by:
aogilmor
16 years ago
NVD,
Consider an admnistrative installation:
msiexec /a myapp.msi \\server\share\appfolder
For subsequent updates, use patches
msiexec /update patch.msp /package <path to original package>
If your installation is set up right, and component rules are observed you should be able to have users launch and Windows Installer would update the app. I've actually tried this with some MS Office products and it worked, but testing and confirming takes a while.
The other alternative is just get a process down where you have users run standalone updates at logon
Consider an admnistrative installation:
msiexec /a myapp.msi \\server\share\appfolder
For subsequent updates, use patches
msiexec /update patch.msp /package <path to original package>
If your installation is set up right, and component rules are observed you should be able to have users launch and Windows Installer would update the app. I've actually tried this with some MS Office products and it worked, but testing and confirming takes a while.
The other alternative is just get a process down where you have users run standalone updates at logon
Posted by:
AngelD
16 years ago
Sounds to be a workload to have to update the installation each 3-4 days.
Why not build in this update functionality in the application insteas as it's developed inhouse?
Is the users non-admin users?
If you want to manage the life-cycle of this application through you deployment tool then maybe Owen's patch suggestion would be more appropriate. If Managesoft supports to deploy standalone patches then why not take that approach instead.
Why not build in this update functionality in the application insteas as it's developed inhouse?
Is the users non-admin users?
If you want to manage the life-cycle of this application through you deployment tool then maybe Owen's patch suggestion would be more appropriate. If Managesoft supports to deploy standalone patches then why not take that approach instead.
Posted by:
aogilmor
16 years ago
AngelD makes a very good point: app updates every 3-4 days surely sounds like data or configuration updates, not actual program updates?
If that is the case you could have the app update itself (user wouldn't have to be an admin if you copied data locally to a separate data directory and made that writeable to the users).
If that is the case you could have the app update itself (user wouldn't have to be an admin if you copied data locally to a separate data directory and made that writeable to the users).
Posted by:
nvdpraveen
16 years ago
Yeah, the changes will be configuration changes not the actual application functionality changes.
Using patches seem to be an overkill. Say there are 10 changes in a month, I'll end up having 10 msp files which adds extra maintenance overhead.
Is there any way I can have the changes in a mst and update the mst for future changes and install the app in repair mode?
Using patches seem to be an overkill. Say there are 10 changes in a month, I'll end up having 10 msp files which adds extra maintenance overhead.
Is there any way I can have the changes in a mst and update the mst for future changes and install the app in repair mode?
Posted by:
AngelD
16 years ago
If you add the changes to a transform each time you would need to reinstall the package with the updated MST.
Posted by:
aogilmor
16 years ago
ORIGINAL: nvdpraveen
Yeah, the changes will be configuration changes not the actual application functionality changes.
Using patches seem to be an overkill. Say there are 10 changes in a month, I'll end up having 10 msp files which adds extra maintenance overhead.
Is there any way I can have the changes in a mst and update the mst for future changes and install the app in repair mode?
I think the better method is to have the app update itself - talk to the developers and reach an agreement on how this may be accomplished, maybe have them put the network source/local dest. in an INI file so that you can see it and (if necessary) change it at some later date. In that case, it should work for as long as the network location (source) stays the same and no further MST/MSP updates would be necessary.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.