Care About Your Environment

For those who are confused about the title, I am not going to talk about our planet (although it is essential we take care of it). The environment I am referring to is of course the development, testing, build and production environment. All these environments can be different and in most cases they are. There are a couple of reasons for this:

  • You have different customers all having different hardware and software in production you have to integrate with.
  • There is a difference between your company and the customer in setup, which would be very expensive to change.
  • Having a full production environment for development is almost always too expensive.

So unless you are willing to change all of your environments and pay a serious price for it, your environments will differ. And while these differences can be cumbersome and make software development harder, a lot can be done to overcome most of these problems.

Before talking about the solutions, lets get more into detail about the actual problems. In a recent project I was faced with the biggest gap between my development environment and the actual production environment of the customer I ever experienced.

  • The database the customer used was SQL server, while I had to use a free alternative.
  • The customer had hardware for the Profinet communication, while I had to use a simulated component.

In itself, these differences shouldn’t have been a problem if they were tackled correctly. However as I inherited the project I had no saying in most of it.

For the database the major problem was that the database schema was provided by the customer as well and it contained columns names with spaces. Ask anybody who is involved with databases, and they will tell you not to use spaces. Why? Because a name with a space needs to be escaped, not only is this annoying and cumbersome it is also handled by different databases in different ways. My MySQL for instances uses the backtick ‘`’ character where SQL Server uses braces ‘[]’. I hardcoded these set of characters instead of putting them somewhere in a configuration file because to the structure of the frameworks that is used does not allow easy configuration like that.

The second differences was tackled by having an internal dummy component that did not do any communication over Profinet but instead kept the data in memory and reacted to TCP messages being sent. While having such a dummy made testing possible, the fact that it is an internal dummy means that the real component can never be tested. It would have been better to have an external component that reacts to the real messages, though I am not sure if it would have been that straightforward with Profinet messages.

A bigger issue with this approach however is that due to the dependency injection framework all of the software is build upon there can only be one component implementing the interface (otherwise the framework can not determine which to inject). This means that the dummy and the real component can never co-exist, which makes sense and should never be desired. The dummy component however required a bigger API to receive signals which would normally be sent over Profinet. If however the dummy is not used the API framework detects there is nothing implementing this couple of API methods and refuses to respond to any message.

These problems have led to a couple of release that were completely useless, either because the query that is created is just not valid for that database or because all messages where rejected due to only a partial implementation of the API. It is even this bad that the Continuous Integration system is useless because the code that is committed can either be used to run a simulated environment or must be used in the production environment but never in both of them. To me it makes no sense to change all the code such that is works in production before committing it, I just make my own builds whenever it is required.

This real life example should have made it clear that your environments should be as close together as possible. If they can not be made the same, it is essential that actions are taken to make the software work on both of them without much effort.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.