Service Pack installs

[Andy McMaster]

Hi,

I've just installed the latest 3.4.0 service pack. It all went smoothly and everything seems fine, but is there no way you can automate this process?

Copying and moving 20+ files on each of three installs is time consuming. Most of the internal directory structure seems consistent so setting those at the start should make automating the SP install possible? I appreciate database/repository changes may be very install dependent.

Just a thought...

Andy

[Sarah]

This is something that is going to be looked into sometime in the future, but as yet we don't have any timescales.

The main difficulty with it is that each customer has completely different settings in several different files within the Ebase directory and it would be very difficult to automate.


An alternative to the Service Pack upgrade is to install a completely new instance using the Ebase Installer, and then copy across the settings that have been customised. This is still not straightforward, but it might be a better option for certain customers' installations.

[Andy McMaster]

Hi Sarah,

I can see the problems but maybe it's down to formalising the whole Ebase structure and keeping it distinct from customer specific stuff, although I appreciate this may not be easy. Part of the benefits of the system is being able to hook into it in many places.

Could possibly put the main config files under version control in some way and then compare after doing a clean install to see what's changed and what needs copying over to reset the install how you want it.

Cheers

Andy

[ehmd]

I've now got used to the upgrade process with service packs and it takes me max. 10 minutes to install a service pack on each installation.

For each major revision, i.e. 3.3.0, 3.4.0 etc, first thing I do is install copy on local development PC, test it and configure how we require it.

This 'complete install' is then copied to the Development, Test and Live servers at the appropriate time. Only changes required usually are database config, UFSSetup.properties, Licence file and DB Upgrade. Each server has the same installation path for each instance e.g C:\UFS. Since version 3.4.0 we using Environment Variables for common path names, to reduce the impact of 'hard coding' paths.

With regards to the 'Automated Install Process', this is not something I would want or wish to use. We have Ebase installed in a non-default directory naming convention, which has been done deliberately for security purposes. Documentation is not installed on any live server ( internal or public facing ). We also use site specific jar files for a number of Custom Resources and Custon Functions we have implemented.

regards,


Mark