Environment management
There has been a massive increase in the number of environments from 2 dev,1 uat and 1 prod
to about 9 UAT environments 3 dev and one prod.
This has caused a lot of work, enough for a new hire just to take care of them all.
Issue from Java side is, all the environment specific settings were in properties files inside the deployed binary.
We could then just select the internal property file using a -D java command line parameter.
This has proved not to be scalable
1. Settings change much more frequently and every change requires a new binary build.
2. Source code branching of the app also means we get multiple versions of the same environment file - very confusing..
The solution I think is to move environment settings to separate source controlled project. This then becomes like a environment directory, always of current state.
Using JNDI is another solution, but we also need these environment files to be processed by unix scripts.
Why the blog?
To record development problems and hopefully subsequent solutions when working on an ongoing Java project.
When I started on this project, it was already 5 years old. I thought it would be useful see how introducing some XP techniques might help reduce some unwanted artifacts
A test-driven re-write would be my preference, but as is so typical, this has been ruled out as too much work.
So, hopefully continuous gradual change in the right direction will help.
When I started on this project, it was already 5 years old. I thought it would be useful see how introducing some XP techniques might help reduce some unwanted artifacts
A test-driven re-write would be my preference, but as is so typical, this has been ruled out as too much work.
So, hopefully continuous gradual change in the right direction will help.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment