Just as the importance of unit tests during development phase, so is the environment verification test during deployment phase. Environment verification test is the most important tool for an application during deployment phase or even maintenance phase.
An application often makes assumptions about the environment within which it runs. It might requires a file being present, an environment variable being set, or a functioning network environment. Without any of these assumptions holding true, an application cannot run. And depending on the quality of an application, when the assumptions about the environment are broken, it might or might not be easy to find out.
That’s the first part of environment verification test. An application should be robust enough that even when any of its assumptions does not hold it can still behave reasonably. Under such circumstances, an application should gracefully exit and pop up an easy to understand message indicating what the problem is (what the broken assumption is).
The second part is a tool set for quickly verifying the environment. Normally if the first part is well done, most applications do not need this kind of tool set. However, providing such tools could be handy during deployment. First of all, the person responsible for deployment does not need to start the application simply for verifying the environment. The tool should carefully examine the environment against all the assumptions made by an application. It should produce a complete list of all broken assumptions so that the list could be sent to the developers later for problem determination.
Most of the time wasted during deployment comes from the mismatch of the real environment and the assumed one made by the application. If we can quickly determine whether the problem is related to the environment or not, our lives will be a lot easier.
Normally we use a class to encapsulate all application related properties and apply the singleton pattern. This way, we could have a unique instance representing the collection of all application related properties. The benefit is that we could pick up any update to the properties and reflect it in the application on-the-fly.
This is not hard, as the following code snippet illustrate:
public class AppProperties {
private static final AppProperties INSTANCE =
new AppProperties(...);
public static AppProperties getInstance() {
return INSTANCE;
}
private AppProperties(...) {
}
}All is very simple, great. But usually we read application properties from some repository, such as reading from disk file or from database. And usually we have exception to be handled within the private constructor. In such cases, that is, if the constructor throws an exception, this class is effectively failed “loading”. At this point, you have no choice but to restart the JVM in order to fix the problem.
This is pointed out in System Configuration Management, which says “Do not put any initialization work in Java class static constructs ...”. The purpose is really to avoid the restart of the JVM. But how can we do that at the same time to apply the singleton pattern? Here’s what the solution:
public class AppProperties {
private static AppProperties INSTANCE;
public synchronized static AppProperties getInstance() {
if (null == INSTANCE) {
INSTANCE = new AppProperties(...);
}
return INSTANCE;
}
private AppProperties(...) {
}
}Before you cry out the performance suffering from keyword synchronized applied to the method getInstance(), check out Double-checked locking: Clever, but broken. Personally, I would rather trade the slight performance suffering for the maintenance convenience.
After spending the past whole month on fighting to deploy our project on production environment, I have some words about configuration system.
The one very bad thing came to my mind is “recycle”. You have to know that in a production environment it is very very difficult to have the servers recycled. But with a not-so-good configuration system, you may find yourself constantly asking for a recycle in order to make a configuration change.
Another thing I complained most about is the fact that I have no idea of what the current configuration is. Configuration is all about options, and with all options available I have to know which one the system is currently using or I cannot tell when problem occurs.
A good configuration system should at least let us know what’s going on when something is really wrong. And when we need to make configuration change to the system, the burden should be minimum.
That’s all I want, and I hope I can have it in my next project.
