Hi,
I just installed tomcat 4 and some things are looking good (didn't deploy my
current applications yet under tomcat 4), but one of the big issues when
running a server that must be online 24 hours a day, is upgrading the server
with new classes / configs etc. The current "stable" tomcat doesn't reload
stuff correctly all the time and tomcat 4 solves these problems (at least
that is my understandig from the docs). I would like to take a step further
: using a tomcat internal version control system, so that you can go back to
the previous version(s) of your webapplication without any trouble.
Lets first point out the perfect world scenario (the it supposed to be, or
reasons why the above idea is bad ) :
- You're code should always be tested (ahum...)
- You should write test cases (eg jUnit)
- You should do integration tests on a separate server, to see if everything
is still ok.
- You shouldn't write buggy code (ahum..)
- Version control is in CVS..
Now the arguments that support my version control wish :
- We're humans and make mistakes (which can be deadly on a production
server)
- Version control in CVS is limited and too much time consuming
- All scenarios can be tested, but if you have eg 2000 shops running at the
same time and all the shops have been made under a different release and
changed in different releases, it's hard to test that (it is possible, but
very time consuming).
- If you can go back with a "press on the button" scenario, the customers
are happy again.
- Better possibilties for remote managament of servers and version control
(not all our customers give us the access to eg telnet, which makes it
harder to use cvs amd ant for this).
If I missed some reading and this is on the list to be done, let me know
:-)
Do you (=the developers) like that idea?
I would be happy to invest time in this (to build it), but I never peeked at
the source before, so I don't know yet what I'm volunteering for...
Mvgr,
Martin
