Application naming conventions and other stuff
I'm essentially looking for new ideas or maybe a twist on some old ones. So here are a few questions for some of you.
I'll throw out what I've used with the formats, feel free to add to them.
Package naming conventions:
Typical: Vendor-AppName-Version-Revision
At what points does your revision get bumped up to a new one? Does it get bumped up after failed QA, UAT, etc...?
Package updates:
This is an interesting one and I see that so many people do this differently. Most companies I've worked for uninstall the previous version then install the new version. One company I worked for compiles the .msi, keeping ALL files outside the .msi and when a .dll or .exe or whatever needs to be updated, they replace the file or files with the new source, recompile the .msi, and reinstall. This replaces the files that currently exist on the machine with newer files. I would ask myself, "Self... Why bother with a package at all in this case, use robocopy!?!?!"
Package regionalization:
It's interesting that many companies just hard code so much information into a package such as IP Address's, DSN's, etc... I've seen 10 of the same package out on a server somewhere labeled with Prod/Dev/UAT/US/NY/LON/SIN, etc... Having 10 200 megabyte packages out on servers because of a change in an IP address or something simple like that. Rather than this, why not regionalize? Have your .msi read (via custom action) an external .ini file which houses all of this information. Now you need 1 package which will read either an AD group or region (system properties???), etc... Or take this 1 step further. Deploy your package and have the shortcuts run a script that reads out of a regional .ini file from a server. Now when you need to make a change to an IP address or DSN or whatever, change the .ini file. The shortcut will read the .ini file and make the changes to your system before the application even runs. This of course eliminates the need to create a new package everytime something changes. Is it foolproof? No. But for the most part, this has worked for me in the past.
Now with many companies moving to application virtualization, how will you handle this?
Some developers seem to think it's ok to make a guess as to where certain pieces of information should be stored on your systems. Instead of allowing you to make the choices, they will hardcode something to read a registry key such as "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders". Maybe we want this to point somewhere else! It's my opinion that developers need to understand that their way is not necessarily everyones way and that their coding should be a bit more flexible.
Validation Utility:
Useful or useless? I find it extremely useful but when I asked one company how they handle various ICE issues, they looked at me like I was nuts and said, "What's an ICE issue?" :)
Everyone has their way of doing things. I'm just looking for some ideas as to how some of you handle what I've described and maybe if you had it your way, how you would change things around.
Looking forward to your comments! Have a nice weekend.
I'll throw out what I've used with the formats, feel free to add to them.
Package naming conventions:
Typical: Vendor-AppName-Version-Revision
At what points does your revision get bumped up to a new one? Does it get bumped up after failed QA, UAT, etc...?
Package updates:
This is an interesting one and I see that so many people do this differently. Most companies I've worked for uninstall the previous version then install the new version. One company I worked for compiles the .msi, keeping ALL files outside the .msi and when a .dll or .exe or whatever needs to be updated, they replace the file or files with the new source, recompile the .msi, and reinstall. This replaces the files that currently exist on the machine with newer files. I would ask myself, "Self... Why bother with a package at all in this case, use robocopy!?!?!"
Package regionalization:
It's interesting that many companies just hard code so much information into a package such as IP Address's, DSN's, etc... I've seen 10 of the same package out on a server somewhere labeled with Prod/Dev/UAT/US/NY/LON/SIN, etc... Having 10 200 megabyte packages out on servers because of a change in an IP address or something simple like that. Rather than this, why not regionalize? Have your .msi read (via custom action) an external .ini file which houses all of this information. Now you need 1 package which will read either an AD group or region (system properties???), etc... Or take this 1 step further. Deploy your package and have the shortcuts run a script that reads out of a regional .ini file from a server. Now when you need to make a change to an IP address or DSN or whatever, change the .ini file. The shortcut will read the .ini file and make the changes to your system before the application even runs. This of course eliminates the need to create a new package everytime something changes. Is it foolproof? No. But for the most part, this has worked for me in the past.
Now with many companies moving to application virtualization, how will you handle this?
Some developers seem to think it's ok to make a guess as to where certain pieces of information should be stored on your systems. Instead of allowing you to make the choices, they will hardcode something to read a registry key such as "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders". Maybe we want this to point somewhere else! It's my opinion that developers need to understand that their way is not necessarily everyones way and that their coding should be a bit more flexible.
Validation Utility:
Useful or useless? I find it extremely useful but when I asked one company how they handle various ICE issues, they looked at me like I was nuts and said, "What's an ICE issue?" :)
Everyone has their way of doing things. I'm just looking for some ideas as to how some of you handle what I've described and maybe if you had it your way, how you would change things around.
Looking forward to your comments! Have a nice weekend.
0 Comments
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
jmcfadyen
13 years ago
Package naming conventions:
Typical: Vendor-AppName-Version-Revision
At what points does your revision get bumped up to a new one? Does it get bumped up after failed QA, UAT, etc...?
I only update the revision after a production release, you can change the package between QA / UAT as many times as you like with little impact on the revision. The revision comes into play when you have distributed the app widely and need to deploy a fix, you cannot remove the original package folder until the original machines have been uninstalled / upgraded as they will require the source folder for self repair reasons.
Package updates:
I guess this depends on site specific items. Files outside the msi is great if your a packager, not so good on the network. Makes for simple updates uncompressed distribution is network intensive but allows simpler patching / package changes. not much argument either way for compressed vs uncompressed
Package regionalization:
I use xml in a similar scenario to what you suggest with your ini files. I find xml is much simpler than ini and caters for more complex solutions.
Now with many companies moving to application virtualization, how will you handle this?
post deploy scripts, seems like the virtual world has some catching up on the msi world here. I would think the day someone creates virtual implementation that consumes and msi would be a good day.
Some developers seem to think it's ok to make a guess as to where certain pieces of information should be stored on your systems. Instead of
agreed devs need to think outside the box a little more. not something you or I will fix any time soon
Validation Utility:
Useful or useless? I find it extremely useful but when I asked one company how they handle various ICE issues, they looked at me like I was nuts and said, "What's an ICE issue?" :)
funny isn't it. Its even worse when it comes from a packaging vendor which I have seen many suggest to do. I guess again site specific rules apply. If you don't want the apps to work for all users then sure ignore validation. If your goal is quick crap deployment why validate. If you after clean solutions that work for more than one user then it is probably more important. At the end of the day analysis of the client requirements can help you decide to do this or not. I personally think its nuts not to validate but at the end of the day it depends on what the client wants to pay for.
Typical: Vendor-AppName-Version-Revision
At what points does your revision get bumped up to a new one? Does it get bumped up after failed QA, UAT, etc...?
I only update the revision after a production release, you can change the package between QA / UAT as many times as you like with little impact on the revision. The revision comes into play when you have distributed the app widely and need to deploy a fix, you cannot remove the original package folder until the original machines have been uninstalled / upgraded as they will require the source folder for self repair reasons.
Package updates:
I guess this depends on site specific items. Files outside the msi is great if your a packager, not so good on the network. Makes for simple updates uncompressed distribution is network intensive but allows simpler patching / package changes. not much argument either way for compressed vs uncompressed
Package regionalization:
I use xml in a similar scenario to what you suggest with your ini files. I find xml is much simpler than ini and caters for more complex solutions.
Now with many companies moving to application virtualization, how will you handle this?
post deploy scripts, seems like the virtual world has some catching up on the msi world here. I would think the day someone creates virtual implementation that consumes and msi would be a good day.
Some developers seem to think it's ok to make a guess as to where certain pieces of information should be stored on your systems. Instead of
agreed devs need to think outside the box a little more. not something you or I will fix any time soon
Validation Utility:
Useful or useless? I find it extremely useful but when I asked one company how they handle various ICE issues, they looked at me like I was nuts and said, "What's an ICE issue?" :)
funny isn't it. Its even worse when it comes from a packaging vendor which I have seen many suggest to do. I guess again site specific rules apply. If you don't want the apps to work for all users then sure ignore validation. If your goal is quick crap deployment why validate. If you after clean solutions that work for more than one user then it is probably more important. At the end of the day analysis of the client requirements can help you decide to do this or not. I personally think its nuts not to validate but at the end of the day it depends on what the client wants to pay for.
Posted by:
Secondlaw
13 years ago
Package regionalization:
I use xml in a similar scenario to what you suggest with your ini files. I find xml is much simpler than ini and caters for more complex solutions.
Just wondering if there is any documentation resources for this. Sounds interesting. I've always used the .ini file method but XML might be a better way to go.
I use xml in a similar scenario to what you suggest with your ini files. I find xml is much simpler than ini and caters for more complex solutions.
Just wondering if there is any documentation resources for this. Sounds interesting. I've always used the .ini file method but XML might be a better way to go.
Posted by:
jmcfadyen
13 years ago
http://installpac.wordpress.com/2008/04/28/using-custom-xml-based-transforms/
this is pretty crap code if you want deeper examples give me a shout.
The WiXCA is great for doing this, supports sequencing of updates, rollback / commit blah blah you get the idea.
Can also target any xml anywhere you like with some imaginative xpath lookups
stuff like
//blah/blah[@attribute='xxxxx']/blah
this is pretty crap code if you want deeper examples give me a shout.
The WiXCA is great for doing this, supports sequencing of updates, rollback / commit blah blah you get the idea.
Can also target any xml anywhere you like with some imaginative xpath lookups
stuff like
//blah/blah[@attribute='xxxxx']/blah
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.