Stories

We all have stories to share around the lounge at a conference of deployments gone bad and those that were successful. We want to share a couple to set the stage for some of the issues discussed in this chapter and point out a couple of mistakes we have made over the years so you can avoid making the same.

The first story is about a one-person company run out of his basement. The application was developed by someone learning Visual FoxPro during the development of the solution. The program runs to this day on one computer in the guy ‚ s basement . This author was called in on the project because the original developer was moving to a new continent , following her husband ‚ s new job. The original developer did a decent job overall for a first application, but was struggling to finish the last 10% of the development and make a deployment. The first deployment of the beta application was throwing numerous errors at start up and would not even run. Most of the problems related to not finding Drive D, ActiveX controls, or FOXTOOLS.FLL, and some were related to hard-coded paths to various items like external reports and missing columns in a table. It took several months of part-time work to get this application completed. The original developer never used the Setup Wizard to install a single component. Each file was copied to the computer and manually registered.

The fixes were fairly simple if you had experienced the problems in a previous deployment. Install and register the appropriate ActiveX controls, the FOXTOOLS.FLL, repair the structures, and add a PATH = reports in the C ^ONFIG . ^FPW for the reports instead of hard- coded paths in the code. The majority of these problems would have been avoided simply by creating a test folder on a different machine and testing out the application before installing it for the client. The user had a copy of Visual FoxPro loaded so I fixed the structures manually. The long- term solution was to implement Stonefield Database Toolkit for future updates. Even setting up a test folder on a different drive would have tested out everything except the FoxTools and ActiveX problems.

The second story we want to share is a release candidate deployment. I made this deployment for another developer in the company I worked for at the time. The developer had made several beta releases before my visit. The deployment was a simple update to the EXE. All I had to do was copy the new executable to the folder and show the customer a new report and a couple of report changes added for the release. No table structure changes, no additional components , no other special circumstances. I first renamed the existing executable in case I need to revert to the previous version. This is something I always do because of a lesson learned years earlier when I overwrote an executable with a corrupt executable and had nothing to revert to in the situation. I made sure the new executable ran by bringing up the About form to verify the correct version, ran the main data entry form, scrolled through some data, and previewed the new report. This is when the deployment went bad. The new report caused a fatal application error. I ran the other altered reports and they executed without error. That was a relief. I explained to the customer the new report was crashing the application, but the other reports were ‚“working. ‚½ Boy, was I ever wrong! We ran each of the changed reports and each report had logic errors, miscalculations, bad pagination, and an incorrect logo. The last report we ran the customer asked me to print the report. She left the room to get the printout and when she returned, she threw the report in my face and asked: ‚“Is this acceptable to you? ‚½

I took the bullet for the original developer. I told her I did not do appropriate testing and it was my fault the application was not working. I did this without writing a line of code involved with the deployment. What was the lesson learned during this deployment? Testing is king. Now you know why we have stressed testing throughout the various chapters in this book. Simply testing the new reports and changed reports would have avoided a terribly embarrassing situation. Fortunately, I was able to revert to the old executable and even more fortunate, no data was destroyed even though I did not back up the data during the deployment because we were not changing structures. It is entirely possible the report processes could have updated data after the reports were run and I would have been in even more hot water. Now I always back up data before deploying updates.

The last story we want to share is a new deployment for an application that shipped to 300 sites across the US and Canada. It is not the method of deployment or the nerves frayed in sending out 300 copies of an application simultaneously that is a lesson learned, rather a simple thing like a label caption. One site on the deployment schedule was a branch in Montreal, Quebec, Canada. A nice city to tour, but deploying our application there revealed a small problem with larger implications. I will never forget the phone call. ‚“What is a Social Security Number? Do you mean Employee Number? ‚½ Our Canadian customers do not have Social Security Numbers. The next question was: ‚“When does the French translation get delivered? ‚½ We found out rather quickly our application needed a plan to deploy with an option to display English and French within a year, and it was the law. Fortunately, we were able to purchase Steven Black ‚ s INTL tool and within two weeks we updated the application and provided the necessary translation for French strings. Each time we look at an application we take into consideration the locales involved in the deployment in case it impacts the application or how we deploy the solution.