Simplifying Deployment

A common problem that my customers face when developing and deploying Enterprise applications is how to keep all the different application server instances configurations synchronized. What I mean is, how to easily make sure that the development application server, the QA application server and the production application server have the same configuration, and when the development application server changes, what is the process to move those configurations changes to the other application servers. I am not talking about application code itself, but the configuration files and directories on the servers. I see this issue even in organization with a mature software process.

I have seen many solutions to this problem. Most of the time the solutions are depending on a technology, are manual and poorly documented. Here are some examples I have seen:

- README notes. I have to admit I have a soft spot for README notes. As a person heavily involved in Open Source, I am used to getting building, installing and upgrading instructions from README type documents. These notes alone just don't do the trick. They can be an important instrument in the process.

- Saving entire application server configuration directories in the repository. This one is a bad idea all around. For example, I have seen applications being moved from development to production by copying the entire server directory to production. To do this in JBoss, you would copy the directory //DevelopmentServer//%JBOSS_HOME/server/default to //ProductionServer//%JBOSS_HOME/server. This is bad because that instance of the server is only useful for the one application you are deploying. Deploying another application to that instance is difficult and complicated. Also, the possibility you will have broken file links is high.

As an enterprise architect the first thing I do to solve this problem is first to create a non technology specific strategy that can be instantiated to a particular technology stack. The plan will look like this:

a) Push as much configuration as possible to the application resource file (.ear, .war., .sar, etc).

b) Define what configurations can not be pushed to the application resource file. For example in JBoss that usually is : xxx-ds.xml, xxx-service.xml, login-config.xml among others.

c) Create a repository project separate from all the applications where you keep those files. Tell developer that their configurations have to play nice with everyone elses.

d) Create scrips with Ant, Maven, etc that automatically get those files from the repository and place in the correct place.

As a deliverable of this solution you should provide documentation of what can't be placed in the application resource file, a repository project for those files, scripts to automatically perform do the update to the servers from the repository.

Let me know if you have any questions.

Comments

[Dr Dre Solo]

so good

[essay writers]

Yeah, the article is very meaningful. You should write your book