A development server is a necessity

by Giuseppe Lanzi on 12/11/2014

Before putting an application into production, you have to reduce to a minimum the chance that users may encounter errors, because every time someone sees one, their perception of the product deteriorates. The things I’ll list for you today may seem like items that should be taken for granted, but my experience in the support department has shown me that this just isn’t true.

I’ve also noticed that there is a trick that’s relatively simple, though rarely adopted, that helps you achieve good results: develop in the same environment as the production environment.

I’ve often received support requests for problems that crop up only in production, and in many cases the two environments are different. It doesn’t take much to cause unexpected behavior in an application.

The most frequent causes are:

  • 32-bit development environment, 64-bit server
    If you don’t configure the server to run the application in 32-bit mode, the external libraries used can cause errors while loading. The InDe IDWS.dll web server library may also behave this way. It’s practically a classic.
  • The version of Java/C# is different
    Errors may occur while loading the libraries, or while loading the application context because of specific directives used in the development machine that aren’t valid in production.
  • The database version/configuration is different
    I am citing two glaring examples that need no explanation: since version 8.3 of PostgreSQL, query parameters are no longer automatically converted into characters, while before they were. MySQL 5.01+ considers all the “\” of the SQL code to be escape characters, but it does offer the no_backslash_escapes parameter that deactivates this functionality;

In the Support Department I often say, “by looking for the differences we’ll also find the cause of the problem.” It’s precisely the difference between the two environments that causes the unexpected behaviors. So it follows that when developing in an environment that’s identical to the production environment, any problems will be found during development, not after deployment.

Establishing a copy of the production environment locally takes time, but I don’t think it’s an optional element of developing and maintaining software.

If you don’t already have a solution like this, I recommend you organize one as soon as possible. And if you really don’t want to dedicate a server for this, at least a virtual machine!

Leave a Comment

Previous post:

Next post: