What can go wrong during a deployment?

In a word, everything! Deployment nightmares are not uncommon. Poor software deployments destroy schedules, projects, and potentially your customer ‚ s computer. A bad installation can ruin all of the development work that came before it.

We can ‚ t cover every possible problem in this book, let alone this chapter. What we will do is cover many of the common problems that have trapped us over the years . Early planning for deployments allows you to avoid many of the problems we list here.

Implementation

We have all lived through embarrassing implementations where we encounter a problem that never showed up during unit testing, system testing, user acceptance testing, or even the installation rehearsal you did the day before the real installation. This could be because of external problems or because of one you interject into the process all by yourself.

• Users who are incapable of performing the installation and following deployment instructions.

• You show up and your users are not available (pulled into some important project or meeting).

• Required hardware is not delivered.

• Missing files (executables, runtimes , reports , ActiveX controls, metadata, or images) in the deployment package.

• Missing data files in the production environment.

• Version problems (file not overwritten when you want it, overwritten when you did not intend to).

• Bad conversion of the data before the installation is started.

• Corrupt indexes after implementation.

• Corrupt resource file (FoxUser.dbf/fpt).

• No backups (data and application).

• 24/7 operation cannot take down the application for 10 minutes (scheduling).

Application

The application should have been tested long before you deploy it, but during deployment you may encounter a new condition that breaks the application. We strongly advise you or the designated installer run the application before turning it over to the users.

• SET EXCLUSIVE OFF , single developer runs one instance on the development machine, never test multi-user contention issues.

• Read-only files (INI, DBF, CDX, FPT), typically caused when copying files from CD-ROM using Windows 2000 and earlier.

• Paths on development machine do not match production directory structure.

Environment

The most difficult part of ensuring a smooth deployment is understanding the environment long before the deployment takes place. Yet we still find ourselves tripping over problems we did not anticipate before the fateful day.

• No compatible media readers.

• Older runtimes can result in VFP bugs not getting resolved (for example, VFP 8 SP1 solves a printer preview problem with reports on Windows NT 4.0).

• Network administrators want data in a location not compatible with the way the application was architected.

• No admin rights for the implementation.

• Hardware not capable of running applications (PC, Printers, memory).

• OS problems ‚ Windows 95 machines in the environment when application requires Windows 98 or better.

• OS problems ‚ bad printer drivers, missing printer drivers, bad network drivers (Netware in particular).

• Screen resolutions not high enough to fit forms.

• Missing fonts on the workstation can be problematic because substitute fonts may create problems like truncated labels and can make forms and reports unusable.

• Anti-virus software might conflict with the application, potentially leading to instability in the machine, and slowing down the performance of the data access.

• Some environments (like Netware long file name support turned off) only support the old DOS 8.3 (filename.extension) format. You might want to consider this for tables, index files, memo files, and executables. Table names can be long inside of the database container and the physical table can remain in the 8.3 format.

• Missing software for automation objects.

• Software is not the right version. You wrote Word Automation code for Word XP and the users have Office 97 loaded on all the machines despite the fact three months prior you specifically asked them to upgrade each machine.

• Old Internet Browsers, Internet Browser incompatibilities, or Internet Browser preference of one user not using the company standard.

• No Internet connection to grab driver updates and software updates.

• Network problems ‚ slow machines, slow NIC cards.

• Network problems ‚ peer-to-peer machine acting as a server is used all day as a workstation for a staff member.

• Drive mappings being inconsistent by network administrator and end users.

• Security rights to data directory and application directory not set up for all users.