Incremental Java Application Deployment

Question

We have the following task. Developers often have to make small changes to our web applications. When I say “small,” I mean things like spelling correction on a web page or the like. Creating and relocating military archives can be slow and expensive in such scenarios.

How could we automate and install changes gradually? For example, generate a new exploded war, compare the files with the exploded war in production and then replace in production only the files affected by the change: .jsp.html.class, etc.

This should not be a hot deployment; its normal to restart the server. I want to avoid copying and deploying wars that can be 80 MB in size. Sometimes connections are slow and make such a minor change in a web application, as a simple spelling correction can take several hours.

We use Maven to automate the build process. The key issue is automating the entire process, so I can be sure that the v2.2.3 application in my Subversion is exactly what I have in production after incremental deployment.

Answer 1

We always did such things all the time. We worked at a bank, and sometimes legal phrases or conditions changed that were to be changed today (or, more often, yesterday).

We have done two things that will help us turn around quickly. We had good change control and build process. We could change and deploy any version we liked. We also had a good set of tests with which we could easily test the changes.

the second was more controversial. All our html was deployed as separate files on the server. There was no WAR. Therefore, when circumstances arose, we needed to quickly change something in the text, we could do it. If java needs to be changed, we always did a FULL assembly and deployment.

This is not what I would recommend, but it was good for our situation.

A WAR point is that everything is deployed simultaneously. If you use WAR, it means that you want it to be deployed right away.

One suggestion is not to make such corrections so often (once a week?). Then you do not have much pain.

Answer 2

Hard to say. You can, of course, replace individual class files in a disassembled webapp, but this is usually a bad idea, and you don’t see many people doing this.

The reason is that with small changes it becomes harder and harder to detect the differences between production and development. The chances that you send the wrong class file and break the production server increase over time.

When you talk about changes in the text, don't you need to leave text resources separate from the war file? Thus, not only developers, but perhaps even the client can easily add / modify translations.

This is important for the client, but it’s technically stupid to deploy 80 MB on a slow line to fix a small typo.

You can also try looking through the build / delivery cycle and increase your testing efforts to prevent these small changes.

Hope this helps.

Answer 3

You can deploy a leading war somewhere on which running servers can run, and instead of deploying military files to separate servers, you can use rsync and perl to determine if there are any changes to the files in the main war, distribute them to the servers and perform a reboot.

Answer 4

diff and patch:

http://stephenjungels.com/jungels.net/articles/diff-patch-ten-minutes.html

Answer 5

At the moment, I have installed SVN on a remote server, so in case of a simple udate, you can just update one file. Transferring a large WAR file will be quite impractical.

You can automate one-click deployments using putty / plink [if you use windows] by creating a simple script on the local computer of another on the remote computer.

I currently have SVN DEVELOPMENT and LIVE SVN. The ANT construct integrates DEV into LIVE and transfers again to the LIVE repository. At this point, the remote server can run SVN UP, and you will automatically receive the requested file.

You can continue to update the script to restart the server if some classes were changed and did not restart in case of script / JSP updates.

This way you will also have the option of rolling back to a previous version to make sure that you have a working web application all the time.

To improve the SVN merge process, this tool is quite useful .: http://www.orcaware.com/svn/wiki/Svnmerge.py

Answer 6

The usual answer is to use a continuous integration system that monitors your disruptive activities, creates artifacts and deploys them - you just want your web application to work even after redistribution. The question is, is this enough for you?

Answer 7

I do not think there is a direct answer to this question. T

The key point here is modulation - a problem that I don't think about is very well resolved with Java applications at the moment. You might want to take a look at OSGi or the lathough dynamic modules, I'm not sure how effective they are in terms of this problem.

I saw solutions in which people throw classes into the application / servlet container, I disagree with it, but it seems to work ... I'm sure there are horrible stories!

Maven certainly makes things easier by breaking applications down into modules, but if you do this and unlock the modules independently, you need to make sure that different versions play well together in a test environment to start with ...

An alternative is to split your application in terms of functionality and individual host functions on different servers, for example:

• Client Accounts - Server A
• Search - Server B
• Online Booking - Server C
• Payment Services - Server D

Separation makes it easy to deploy applications, but again you need to make sure your modules play well together first. Hope this helps.

Answer 8

I used to have a similar situation. This is really a separation of concerns, and it's not too straightforward. What you need to do is separate the text from the template / HTML page.

We solved this by placing our text in a database table and using the table as a message resource - just like people use myMessages.properties for internationalization (i8n). This gives you two advantages: you can insert text into text and make changes to prod instantly and easily without code deployment. We also cached the table to ensure that performance was not badly affected.

Not a solution for everyone, but it really worked for us.