WPS and AdminStudio... How do you organize your package repository/information?
Hello everyone....
I have been tasked with researching and possibly purchasing licenses for a repackaging suite for my company. After quite a lot of research I've found that AdminStudio 8.6 Enterprise edition is over TWICE the price of WPS Pro. Is this for real (8k - 11k)? I was looking to purchase 3 to 5 licenses for our 6 person team but after seeing these prices I am taken back
Also, the reason I am seriously looking into the enterprise and pro editions of each of these products is to utilize the "application manager" feature in them (the single repository/database of package information). I will have several repackagers on my team so I feel that this is will be a very powerful organization feature. Can anyone share your experience on how you organize your package repository and package information if you do not use this method? Right now our SMS package repository is a share on a file server at our corporate office. There is little to no organization to it and package information is in .txt files if in there at all. Our packaging tools range from SMS Installer to ORCA, a real cluge..
Any information on how you guys/gals are handling this would be GREATLY appriciated. I would like to do this right from the get go so we don't end up in this situation again.
Thanks in advance,
J
I have been tasked with researching and possibly purchasing licenses for a repackaging suite for my company. After quite a lot of research I've found that AdminStudio 8.6 Enterprise edition is over TWICE the price of WPS Pro. Is this for real (8k - 11k)? I was looking to purchase 3 to 5 licenses for our 6 person team but after seeing these prices I am taken back
Also, the reason I am seriously looking into the enterprise and pro editions of each of these products is to utilize the "application manager" feature in them (the single repository/database of package information). I will have several repackagers on my team so I feel that this is will be a very powerful organization feature. Can anyone share your experience on how you organize your package repository and package information if you do not use this method? Right now our SMS package repository is a share on a file server at our corporate office. There is little to no organization to it and package information is in .txt files if in there at all. Our packaging tools range from SMS Installer to ORCA, a real cluge..
Any information on how you guys/gals are handling this would be GREATLY appriciated. I would like to do this right from the get go so we don't end up in this situation again.
Thanks in advance,
J
0 Comments
[ + ] Show comments
Answers (1)
Please log in to answer
Posted by:
anonymous_9363
16 years ago
I think most people will, like my last 3 clients, probably use the Wise share point as the starting point. The applications branch from a 'Projects' folder and are held in folders named to a strict convention. I suspect most use some form of [VendorName][ApplicationName][MajorVersion].[MinorVersion]_[ClientReleaseCode/number] e.g. MicrosoftOffice11.00_01 for that convention.
There's nothing wrong with TXT/DOC/whatever information repositories, provided their use is QA'd. Is there a possibility for one of your packaging team to perform a QA role, or for all to operate that role on a rota basis? At one client, packagers passed their projects to another packager for compliance testing/QA. There's no problem with fear or favour with that approach because, in most environments, any bypass will quickly come to light, with consequences for whoever signed-off. Equally, agreed bypasses are OK provided they're agreed, documented and signed-off. At another client, a script ran through the folder and MSI testing for compliance (property and Custom Action names included!)
There's nothing wrong with TXT/DOC/whatever information repositories, provided their use is QA'd. Is there a possibility for one of your packaging team to perform a QA role, or for all to operate that role on a rota basis? At one client, packagers passed their projects to another packager for compliance testing/QA. There's no problem with fear or favour with that approach because, in most environments, any bypass will quickly come to light, with consequences for whoever signed-off. Equally, agreed bypasses are OK provided they're agreed, documented and signed-off. At another client, a script ran through the folder and MSI testing for compliance (property and Custom Action names included!)
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
