Java Web Application - Deployment Strategy Alternative to WAR - Managing UI Changes Separately from Full Code Base Patches

Question

I've heavily edited this question because responses indicated I wasn't being clear

problem: UI changes to a Java web project can be tedious and time consuming because every web-app file is contained within the WAR

my proposed solution: Manage the JSP's, CSS, JS and Tags separately from the application code base which for the purpose of this question I'm defining as:

• All Java Source Code
• Custom Tag Libraries With Compiled Java (extending TagSupport)
• Spring Configuration Files
• Web.xml
• Jar's

+ Source
+ WEB
   - WEB-INF
      - JSP
      - Tags
      - lib
   - HTML
   - CSS
   - JS

What would be nice is if after the major initial release and maintenance cycle, changes to view files could be treated as a different kind of release than a change to the Source. Source changes would be committed normally, and the application version would change. However, a change to a CSS/JS/HTML and even a JSP could be made in a test environment that is internally viewable to test new looks, add links, and so on. Technically, a JSP could even be added and as long as the controllers (like mine do) can be configured to show new JSP's without any Source modification, pages could be added without any deployments.

USE CASE - Owner of the site is running a promotion, he has a fancy graphic to link to an informational pure HTML page and wants it added to the home page.

Now imagine this work-flow: UI dev opens dreamweaver and can FTP into Staging (staging may be a bad name, but basically a live test server). He can see:

   - JSP
   - Tags
   - HTML
   - CSS
   - JS

Now he brings in the HTML file with information on it, adds it to the HTML directory. He then goes into JSP/home.jsp and finds the component that renders an advertisement on the right column, directly below it he adds his nifty image, saves his changes, opens his browser and goes to the live Test URL. He sees his image, but the component no longer renders the advertisement. Oops, he calls a developer and the developer says no problem

$ staging - > ./rollbackView -mostRecentBackup

The UI guy checks the site, everything is back like he never touched it.. now he more carefully adds his graphic and HTML, realizing that he cut off a JSP custom tag before. Now, QA, whatever that is for the project looks at the site, runs selenium, whatever. It all looks great. The developer gets the ok to release the changes

$ production - > ./updateProductionView

the script checks the application versions, ensuring they are identical, then copies over the view files. It's now 8:45 and the website owner (for us internal) is very happy that his new idea was implemented in the first 15 minutes of the day

Now the developer wants to create a patch that allows something cool, he updates his project, and the new view files are present. Maybe this isn't possible, but he could run a script, or use a second source repository like Mecurial to manage the views (ideas?) and he has the project and view files he needs. He makes his changes to the source, and views, whatever he needs. Now that is complete he can check in his changes and bring the WAR to a directory on Staging

$ staging - > ./deployStaging -overwriteView

The full war is deployed, and the JSP's are now what he had in his project. If the UI guys had made changes to staging, they will be overwritten (backed up maybe?). He could leave off the '-overwriteView' flag and the view files would remain untouched. At this point a full QA regression, integration and unit tests have been run, it's time to patch the main application

$ staging - > ./deployProduction

A full deploy is there, the application version is now V1.1 and everyone is happy

My Questions:

First, has anyone done something like this? If so, are there any good recommendations you can make? Development is done on Windows, but the production and staging servers are running Unix. All servers run the same version of Tomcat.

I'm looking for ideas for scripts that would allow Staging web files to be backed up, and hopefully even committed to the main project, also scripts that could take

What has been overlooked? Can I keep the project structured the same? Will this cause problems with CVS?

Is there anything that isn't possible or technically feasible here?

Answer 1

If switching away from JSP is an option you could use a template system (Velocity or Freemarker for example) and store those resources outside the deployed war, on the file system or in a relational db for example.

Answer 2

Can you point your UI resources to other folders? This way you set up the symlinks once on the test server(s) and allow the UI developers to manipulate the 'live' files. If these folders are source controlled then the UI devs could rollback their own changes if necessary.

http://www.isocra.com/2008/01/following-symbolic-links-in-tomcat/