Installer packaging

My biggest peeve with Macromedia products is the install packaging, including the updater. I have often visited the Macromedia forums, and the multitude of talk lists, and there is a common thread concerning just about all of the Macromedia products from MX on back begging for help in getting an application on a server up and running.  As it is, the labor costs are far out of line, when the responsibility should be on Macromedia to make their releases administrator friendly. That common thread is the install packaging, and I am of the opinion that no software package should be so difficult to install and/or configure.   There are repeated multiple requests for assistance in installing and configuring just about every package that MM distributes, and most difficult of all is server applications.    Installs and upgrades should never "break" existing applications, nor require the expense both in Labor costs and hardware to do test installations before moving to a production environment. Current and proposed licensing issues and technical support for installation actually discourages, if not prohibit multiple installations just to get the configuration right before being placed into production.  I do not know if the development and deployment of post-installation wizards for the purpose of configuration would do the trick, because this "feature" is non-existent with MM products.  They seem to forget that not all developers are server administrators, and not all developers even have access to the administration side of production servers. A "friendly" install script will walk the user through just about any configuration options that are available, and will generate whatever configuration files are required for the intended use.  At no time should an administrator be required to search out directories and strangely named configuration files and then have to manually edit them in order to get the application to work for the purpose intended.  Another point of contention is the online documentation that is usually arcane and only understood by the developer as opposed to the end-user. I would like to see this one issue addressed by MM as soon as possible. ====================================== Got DSL?  Check it out! For hosting solutions http://www.clickdoug.com ISP rated: http://www.forta.com/cf/isp/isp.cfm?isp_id=772 ====================================== If you are not satisfied with my service, my job isn't done!

i can pull some general suggestions out of your email below, but do you have any specific suggestions? mike chambers mesh@macromedia.com ----- Excess quoted text cut - see Original Post for more -----

Interesting. I haven't seen these threads myself, Doug, but I know you were having problems. Can you give links to some of these problem-mentioning threads? (I'd like to get an idea that this is as prevalent as you say.) Judith ----- Excess quoted text cut - see Original Post for more -----

On Tuesday, Nov 26, 2002, at 08:48 US/Pacific, clickdoug wrote: > My biggest peeve with Macromedia products is the install packaging, > including > the updater. It's certainly true that there have been a larger number of complaints about the CFMX installation than I would have expected. I have installed the standalone server many dozens of times without incident and I've recently been installing the CFMX for J2EE version, again mostly without incident. I've run the Updater (a couple of times on different servers). I've built clusters, laptops, desktops. All very straightforward and almost never a problem. I say almost because I *have* had a few problems but, to be honest, pretty much only with beta versions of various parts of that puzzle. So, my personal experience is that the various CFMX installers are an absolute breeze and that configuration of the product is really straightforward. Unfortunately, my experience doesn't seem to have been shared by everyone. I saw one user post (on one of the mailing lists) that applying the Updater was an arcane process involving editing files and manually copying things all over the place. At that point, I hadn't tried the Updater. So, in answer to his email, I downloaded and ran the Updater. For me, the entire process took a shade under ten minutes - that included finding the Updater on the website and downloading it! I hope that others (many others!) have found their experience more in line with mine than with those vocal folks on the list who think our installers suck... > I have often visited the Macromedia forums, and the multitude of talk > lists, and > there is a common thread concerning just about all of the Macromedia > products > from MX on back begging for help in getting an application on a server > up and > running. Well, to be fair, people come to the lists when they have a problem so lists are bound to seem full of people who are having problems. Remember that the ColdFusion community is pretty large and that the number of people you are seeing with problems is actually a relatively small percentage. Of course, that doesn't help anyone who *is* having problems and that's why we encourage people to contact Technical Support. In my experience - twenty years of mostly Unix software - I can honestly say that ColdFusion, even in its MX form, is still one of the easiest products to install and configure (in fact, I would say the MX version is actually easier to configure because it has easy-to-read XML text files for its configuration). Someone who is used to Windows software installation may beg to differ of course and I would not counter their argument - I simply don't have enough experience with Windows software. For example, I find IIS to be one of the most frustrating and impenetrable pieces of software in the world yet I can make Apache sing and dance because its configuration is a text file instead of a GUI. Different strokes. Similarly, I use wsconfig in command-line mode, rather than GUI mode. > Installs and upgrades should never "break" existing applications I don't think it's realistic to expect every upgrade to be 100% backward-compatible. That's never been true of *any* server application I've encountered. Improving a product often means breaking some feature in an earlier release in order to move forward. I believe that most of the ColdFusion upgrades prior to MX also broke some old code? At least, that is what several veterans of earlier releases have told me... I think that ColdFusion MX is amazingly compatible with CF5 when you consider that the product is a complete rewrite on a different technology platform. > nor require the expense both in Labor costs and hardware to do > test installations before moving to a production environment. This is something else I would have to disagree with. I can't imagine upgrading any production system without creating a test environment and fully regressing the application on that first. Upgrades should be considered as projects in their own right, evaluating all of the documented changes and the risks associated with them. This is why many production systems depend on older releases of server software - upgrading business-critical production systems is high-risk in most organizations. Consider upgrading an HR or payroll system on which the business depends... why is a company's website any less critical, especially if it is an e-commerce site that brings in substantial revenue? What would a day's downtime cost you? Would that money buy you a server? For a lot of businesses, the answer is yes. > Current and proposed licensing issues and technical support for > installation actually discourages, if not prohibit multiple > installations just to get the > configuration right before being placed into production. I'd be really interested to hear more on this subject. Quite clearly we do not want to discourage people from experimenting with configurations but there is a line that has to be drawn between "can't get the product running" and "can't figure out the best way to configure it for my application". The former is covered under installation support but the latter is going to be different for every application. Can you provide some specific examples of how we seem to discourage this sort of experimentation? > They seem to forget that not all developers are server > administrators, and not all developers even have access to the > administration > side of production servers. Yes, this is definitely an area of concern. I know the product team are interested in feedback from CF developers who are deploying to shared servers such as hosting providers. If anyone is having issues with CFMX and shared servers, please submit those issues to:   http://www.macromedia.com/support/email/wishform/?6213=3 so that the product team know about them. > Another point of contention is > the online documentation that is usually arcane and only understood by > the > developer as opposed to the end-user. Please submit any specific issues to:   http://www.macromedia.com/support/email/wishform/?6213=3 so that we can improve the documentation. Do people think that - in general - the CFMX documentation is better or worse than the CF5 documentation? > I would like to see this one issue addressed by MM as soon as possible. We're listening. Reporting specific issues help us drive future Updaters and Releases. I know that one issue already reported is that of upgrading an installation that hosts multiple sites on IIS - because the install / upgrade documentation for handling multiple sites has several holes in it. That will be fixed now that it has been reported, although I can't say when it will get fixed. It is, at least, in the queue. Sean A Corfield -- Director, Architecture Web Technology Group -- Macromedia, Inc. tel: (415) 252-2287 -- cell: (415) 717-8473 aim: seancorfield -- http://www.macromedia.com An Architect's View -- http://www.corfield.org/blog/ Introducing Macromedia Contribute. Web publishing for everyone. Learn more at http://www.macromedia.com/contribute

Contrary to your experience, Others are having incidents., and each incident runs up the cost of owning the software..  The documentation is not clear when configuring custom tags to not "step on each other" when a same-named custom tag but slightly different functions were in use.  Hot fixes were another matter, requiring "copy this to that directory"," make this registry change" and so forth.  MX is not the same.  It is not better. Macromedia should also include a clean uninstall so as to not leave behind registry entries and files/folders that require manual removal. Subscribing to the ever more expensive Technical Support just for install issues is not the answer either. My argument is that multiple configurations should be anticipated by the writer of the installer package and provide wizards for other than a single homed web server.  This would be my same request for Unix/Linux distributions as well. Microsoft and RedHat do this. My experience in writing scripts for InstallShield installer packages enabled me to do that for software distributions my former employer distributed.  Of course a default set up is straight forward.  If this is all the installer package will do, and when multiple web sites are hosted on the same server, then things get a lot more complicated. Obviously your twenty years of experience is limited to default installations and to suggest that a customer purchase additional machines to host multiple web sites to reduce labor expense, is ludicrous.  The correct answer in that case would be to purchase someone else's software.  Not every server admin type does all of his/her work via the command line. ====================================== Got DSL?  Check it out! For hosting solutions http://www.clickdoug.com ISP rated: http://www.forta.com/cf/isp/isp.cfm?isp_id=772 ====================================== If you are not satisfied with my service, my job isn't done! | On Tuesday, Nov 26, 2002, at 08:48 US/Pacific, clickdoug wrote: | > My biggest peeve with Macromedia products is the install packaging, | > including | > the updater. | | It's certainly true that there have been a larger number of complaints | about the CFMX installation than I would have expected. I have | installed the standalone server many dozens of times without incident | and I've recently been installing the CFMX for J2EE version, again | mostly without incident. I've run the Updater (a couple of times on | different servers). I've built clusters, laptops, desktops. All very | straightforward and almost never a problem. I say almost because I | *have* had a few problems but, to be honest, pretty much only with beta | versions of various parts of that puzzle. So, my personal experience is | that the various CFMX installers are an absolute breeze and that | configuration of the product is really straightforward. |

clickdoug writes: >The documentation is not clear when >configuring custom tags to not "step on each other" when a same-named custom tag >but slightly different functions were in use. This doesn't seem to be an installation issue? I believe that CF has always searched a directory tree for custom tags and if you had multiple tags with the same name, it's always been a bit hit and miss which version you got? I agree that isn't ideal but what would you like the behavior to be if CF can find more than one tag with the same name - should this be a check in the administrator? A runtime check on every tag access? >Hot fixes were another matter, >requiring "copy this to that directory"," make this registry change" and so >forth.  MX is not the same.  It is not better. You don't find the CFMX Updater better than the previous hot fixes? It no longer requires anything more than double-clicking to update a basic installation. Obviously, if you've customized your installation, the Updater can't be expected to figure it all out so you should expect to have to do some additional work in that case. Can you be specific about issues you have with the Updater? >Macromedia should also include a clean uninstall so as to not leave behind >registry entries and files/folders that require manual removal. That sounds like a good idea (albeit Windows-specific). I suspect the reason that it doesn't automatically clean up everything is that the uninstaller errs on the side of caution wherever it finds user-added files (e.g., under wwwroot). But you're right about the registry (the worst aspect of Windows, if you ask me). On non-Windows systems, CF is uninstalled by simply removing the directory into which it was installed. >Subscribing to the ever more expensive Technical Support just for install issues >is not the answer either. Support for installation issues is free and always has been. There is a big difference between "installation" and "configuration" however. Macromedia provides free support to get the product up and running. Beyond that, it seems fairly reasonable to pay for support. All server-based products I've ever used required that you pay for support - usually 15-20% per year (that would be $750-$1,000 per year for CF Enterprise). >My argument is that multiple configurations should be anticipated by the writer >of the installer package and provide wizards for other than a single homed web >server. This is a very valid point. I know the product team are keen to address the shared hosting scenarios common with CF. >Obviously your twenty years of experience is limited to default installations Actually no, I've done a lot of customization of software packages. But I'm used to Unix where customization is expected and, in my opinion, much easier to deal with (since it's all text files). >and to suggest that a customer purchase additional machines to host multiple web >sites to reduce labor expense, is ludicrous. Hardly ludicrous given that machines are cheap and labor is expensive. However, I did not suggest "purchasing additional machines to host multiple web sites". I was commenting that enterprise software developers normally have separate hardware for development, staging and production and that an upgrade should be considered an 'important project' rather than just something you do on a whim. It is perfectly reasonable to expect someone to create a mirrored environment when upgrading enterprise server software and for them to thoroughly test their application on the upgraded server prior to deployment in production. Doing anything less is unprofessional. >Not every server admin type does >all of his/her work via the command line. I conceded that Windows developers do not - my point was that Unix developers do. My personal feelings about Windows are well-documented: I've used almost every version of Windows over the years and all the time also used a variety of Unix hardware and software. In my experience, no Windows software has ever configurable entirely through some GUI tool - and that's extremely frustrating! This sits well with comments (mostly from Dave Watts I believe) that the CF Admin web interface does not let you configure everything. I agree. But whereas Dave - and I suspect you Doug - think that the solution is to make the administrative interface (or installer) much more complex and all-encompassing, my preference would be to keep the admin / install relatively simple and expect folks to do more configuration via files. As I conceded earlier in this thread, that doesn't sit too well with a lot of Windows users and I cannot argue against their position. It just isn't a position that I share (or understand) because most of my experience with deploying production systems has been on Unix. Specific issues are helpful, so keep them coming! Thanx, Sean