Page 1 of 1

Application installation process design

Posted: Mon Apr 19, 2010 2:03 am
by Luke
I have written a lot of applications that have done a very wide variety of things. I have written just about every type of application and app component. But the one thing I have never written is an installation processs. None of my applications have ever needed to be installed by anybody but me, so an installation process just hasn't been necessary.

The app I'm writing right now needs an application installation process. It is a Zend Framework application and I have created a ZF "module" called "install". Before the application is installed, the only available ACL role is "installer" and it only has access to the "install" module. After installation, the "installer" role goes away and then the traditional ACL roles are introduced (which do NOT have access to the install module). That way, the app can only be installed once, and the app can't be accessed until it's installed.

Here's my question. How do I determine whether the application is installed? It seems like an easy enough thing to figure out, but I just can't seem to come up with a clean way to determine if the app is installed. Should I test that there are tables in the database? Should I create a file after installation and check for its existence? What do you guys think?

OK, that was my specific question. Now, for a more general question. Do you guys have advice on an installation process in general? Is there anything I should keep in mind? Any caveats I should be aware of? How do y'all go about an install process that basically installs the tables in the db, sets up writable tmp dirs, sets up plug-ins, access control, that sort of thing. Any advice is appreciated :)

Re: Application installation process design

Posted: Mon Apr 19, 2010 9:15 am
by alex.barylski
Should I test that there are tables in the database? Should I create a file after installation and check for its existence? What do you guys think?
Test for tables, settings file, whatever feels best for you. I don't think there is a more elegant way. Creating a file for the purpose of testing a successful install is overkill, IMO. I personally would probably check a install = true property in a settings file, only because DB connections are not established until an action controller is invoked and a new settings file would not have DB connection details, so I wouldn't be able to connect anyways, whereas a settings file is the first thing I process so it's data are available almost immediately.
OK, that was my specific question. Now, for a more general question. Do you guys have advice on an installation process in general? Is there anything I should keep in mind? Any caveats I should be aware of? How do y'all go about an install process that basically installs the tables in the db, sets up writable tmp dirs, sets up plug-ins, access control, that sort of thing. Any advice is appreciated
File permissions are probably your biggest enemy. In writing/updating a settings file, you will have to ask your user to manually update the permissions of the INI (or whatever) file manually after uploading all the files.

Secondly, you may want to write a quick MD5/CRC32 script to compare the uploaded files to the value you generated after release. I find when clients upload files, many times (shared hosts) files don't upload completely, missing files and sometimes incomplete files. Having a quick script you can run before installing to ensure all files are uploaded completely will save you from spending time trying to figure out why your scripts are breaking, because of something trivial like an incomplete file upload.

Access control I assume is stored in tables, in which case, you should include default roles and data in the install.sql file or whatever you call it.

I basically delete all data in DB except that which is required (default status, roles, cities, etc) and once I get the DB credentials from the user I run an install.sql file which creates tables, import default data, etc.

Cheers,
Alex

Re: Application installation process design

Posted: Tue Apr 20, 2010 6:10 am
by josh
It doesn't sound like you need an installation process. I sell a plugin that does. It does, because certain files must be copied around... due to the fact thats the way the host system works.

Ideally the system should be designed so that no installation process is needed. In the real world you'll need to create database tables, maybe, at minimum. In this case your install can be a txt file that users follow the instructions, it can be an install.php that they input their database credentials into, etc.

But just because you have an installer doesn't mean you should take advantage of that too much. If the installer fails some day there should not be much manual work involved, in an ideal world.

in practice I refactor my install process. I do the simplest (sometimes silliest) thing possible. If I feel pain, or "installation smells" (like repeating myself) then I stop and solve those smells, like creating an install.php I can use to copy files, instead of trying to FTP the files myself. Over time the installer just evolved to fit whatever needs I've had.

Plus, I do the install for any paid customers. I could care less about the free customers, so ALL I focus on literally, is what I need for myself. All my paid users get free installs done by me anyways.

Re: Application installation process design

Posted: Tue Apr 20, 2010 12:51 pm
by alex.barylski
Ideally the system should be designed so that no installation process is needed. In the real world you'll need to create database tables, maybe, at minimum. In this case your install can be a txt file that users follow the instructions, it can be an install.php that they input their database credentials into, etc.
If he is selling COTS then a user-friendly installer should be included. In my experience (I've made this mistake twice now) having an user-friendly installer is critical. Remember many buyers are potentially acting as middlemen between their clients and you, and have no interest in reading a install.txt file

Re: Application installation process design

Posted: Thu Apr 22, 2010 3:45 am
by Chris Corbyn
I'd even perhaps go so far as to suggest checking for a known table and also holding a version number in the database. You can use that version number for determining if upgrades have been done or not.

You could go nuts and do a full environment integrity check, but really who'd bother. Just look for something obvious like a table you know should be there.

Re: Application installation process design

Posted: Fri Apr 23, 2010 1:57 am
by josh
PCSpectra wrote:If he is selling COTS then a user-friendly installer should be included. In my experience (I've made this mistake twice now) having an user-friendly installer is critical. Remember many buyers are potentially acting as middlemen between their clients and you, and have no interest in reading a install.txt file
So if your only installation steps are to unzip the code, and go (no database or anything)... you should still have an installer that does absolutely nothing at all? I think not.

An install should be as much of a non-event as possible. If possible, no installation procedure at all is always optimal.

"COTs" is just a stupid buzz word. "off the shelf" software is a stupid concept. There is no such thing as "prescription" software is there? Selling software is selling software. If I write for a client once, who's to say I shouldn't also resell it as an "off the shelf" software too? Selling software is selling software to me. I try not to take on development work for stuff I can't resell anyways. It's only logical

If you want to include an installer that is one business strategy. Not including an installer is an equally valid business strategy (consumer surplus).

So logically the answer to what should go in an installer, is as little as possible. Not because you are going to make the user perform manual steps, but because you shouldn't abuse the convenience of having that installer. You should just write forwards compatible code, as your first option. Only once the need arises, should you add to that installer, in my opinion. I don't think users like the fact Adobe's Creative Suite install takes hours to complete, for example.

The concept of an upgrade is distinct from an installer in my opinion. In my head when I think upgrade I think database migrations, which you don't even need an installation step for, technically. Just check the version on every request (ala Magento). If you already have an installer anyways, doing the database upgrades there could be more convenient.

So I guess the cliff notes of my position on this matter would be, that I feel strongly an installer for a PHP web application should not be doing much more then creating & upgrading the database schema. If your installer is copying files around, for example.. ala a desktop application's installer, you're doing it wrong. At most you should create a database, maybe set up some initial configuration in that database or on your filesystem.

The user should be able to install your web app in 5 seconds should the installer not work for whatever reason (permissions problem, password reset). I am telling you this from experience. A good percentage of users won't even find out how to chmod the file when the installer asks them too, so that's why its best not to have complex stuff in the installer in the first place.

For example, Magento diverted resources from their development to work on their "extensions" marketplace, which is a PEAR like package manager developers can use as an installer for their extensions. The only problem is Magento has all they can do to work on their main product, let alone a home brewed package manager, so it doesn't even let me charge for my code. Right off the bat now users can't use the Magento installer to install my extensions, since I charge. Due to this, I had to write my own installer to copy files around all over the place. Had they architect-ed the extension system in such a way that file copying was not required, they wouldn't have created an artificial problem for all their commercial developers like that. I'd love for my users to be able to unzip & go. Instead I have to sit and listen to them complain about the fact the installer didn't complete because of a permissions issue, or what not. When that happens though, theres only about 5 minutes of manual work for me, because I follow this philosophy of KISS (keep it simple stupid) for my installs.

Re: Application installation process design

Posted: Fri Apr 23, 2010 10:55 am
by alex.barylski
Most popular open-source and commercial software have user-friendly installers, not because developers like building them (I hate it) but because users demand it.

Any CMS worth it's salt has an installer, as do most other systems. Installing extensions is not quite the same thing. Probably best left for a package manager within the application itself.

Certainly uploading the files should be all you need to do as a developer perhaps setting CHMOD on a config.ini or something but after that the installer should be able to do whatever is needed to make the system work.

My point was that, expecting users to open a setting.ini file and change SMTP details is wishful thinking, they almost always contact support and request a developer do it. Installers alleviate this work load.

Copying files around, I agree is clear indicator your file system is faulty. Unless of course the installer include a package manager that lets users download templates, extensions, etc.

Depending on the complexity of the application and installer will vary in complexity. If you can just upload files, thats great but not realistic in my experience. Setting the root admin, requesting email accounts, SMTP, FTP, multiple databases, REST API keys, company names, etc. Much can be changed at a later time via a settings page, but often it's best to request these details in one go at the time of install, again to avoid users contacting support at a later time and wasting your time.

Cheers,
Alex

Re: Application installation process design

Posted: Sat Apr 24, 2010 6:41 am
by josh
Agreed, pcspectra. Database, and configuration settings are good candidates for an installer. Template down-loader not so much (in my opinion). Plus, having a "settings" area of your application might already alleviate the need to ask for most of those settings at install time. Using the same logic you will just get phone calls because users might just put fake values to satisfy the installer if they are feeling antsy, but generally I agree with all you wrote.
Luke wrote:Here's my question. How do I determine whether the application is installed? It seems like an easy enough thing to figure out, but I just can't seem to come up with a clean way to determine if the app is installed. Should I test that there are tables in the database? Should I create a file after installation and check for its existence? What do you guys think?
I just had another idea. If install.php exists, direct the user there. If it does not exist, don't redirect them. When the installer finishes it should delete the install.php, your client's users shouldn't be able to run the installer, and the presence of the installer is enough to determine if the application has been installed, (on the other extreme is the "full integrity check" which is exactly what I think should not go in the installer, but instead should go in a "integrity checker")

Re: Application installation process design

Posted: Sun Apr 25, 2010 4:23 am
by Luke
Why would you say I don't need an installation process? I told you almost nothing about my application. This is an application I hope will compete with other enterprise applications on par with Magento. I can't imagine an application competing with Magento that doesn't have an installation process. That's absurd. I am not going to ask people to manually edit a configuration file.

Re: Application installation process design

Posted: Tue May 04, 2010 9:27 am
by josh
Luke wrote: I am not going to ask people to manually edit a configuration file.
Was this directed at me? I don't think I told anyone what their needs where. Obviously I don't know anything about your app.

But what I do know is, is that you guys are confusing configuration with installation.


Including configuration options in the installer is all fine & dandy; I have simply stated that my observations lead me to believe the more clutter you put in the install, the more calls you'll get saying "your app sucks it doesnt even install"

If you choose to implement an installer, my personal opinion is that, the installer should not be cluttered up with options that can be set from within the application after installation. The installation, by its very nature, is supposed to be bare minimal.

Since you used it as an example - Magento asks for a database name, and a few configuration options like the domain name. 99% of the configuration is done from within the app itself. They only put the bare minimum fields into the installer, as they saw fit. The configuration of the application, due to it's complexity, is not something that can be done in one sitting. Its an ongoing evolutionary process that happens over the years the user uses the application, it cannot be squeezed into some 5 minute setup process when your program is that complex.

In a perfect world I did say you would have no installer. But we all know what kind of world we actually live in. For example a console video game, there is no install. The user presses on and the device turns on. That would be a perfect world. In the real world; the type of apps we write sometimes call for installers. When you do build an installer, it should be kept as much of a non-event as technically possible.