The transparent promotion process

 

Every friday evening, we are enjoying talks around a set of beers in my company. Not the whole company, just our IT group. This helps fostering the team spirit of the development team and offers an opportunity to talk about professional and non-professional topics.

We briefly talked yesterday about what we internally call “Transparent Promotion Process”. We call transparent promotion process this idea putting the mecanisms in place to be in a position to:

• Not having to change a single line of code in order to promote an application from a test environment (during the User Acceptance Testing phase) to the production environment.
• Not having to change a single line of configuration to change as well.

While the first point is commonly accepted (you are deploying the code that has been tested), it is interesting to realize that the second point is often not considered important. We do consider this is important, since many problems in software do come from misconfiguration. I tend to consider configuration like code. After all, there is no reason why we should treat java/c/perl or C++ differently from a configuration files. Both are source of problems, both need to be tested with the same level of dilligence.

From this starting point, achieving promotion transparency require a couple of principles:

• Applications must pay particular attention to their environment
• Applications must be more flexible than before in handling configuration

My company has structured testing environments. We have test unix users, test databases and other test resources (applications servers and other services). The applications must be aware of these resources through configuration (you are not going to hard-code the the database server aren’t you ?). The key here is to ensure the specifics of the configuration are not hard coded in the configuration file. For example, the database server name is taken out of the environment, not coded in the configuration file. Java 5 now allows the JVM to read environment variables, making it easier to use a single configuration file for all the testing environments and the production environment.

Of course, the transparency has its limitations. Most technological stacks use their own configuration, in which case, there is nothing we can do but use one configuration file per testing environment or production, but the closer we can get from promotion transparency, the better confident we can be that properly tested functionality during a User Acceptance Testing phase will still work when promoted to production.

 

Wouldn’t it be cool to drop a war from one application server to an other and see the application automatically deployed automatically without a single configuration change ?.

Advertisement