Improve Java site deployments
Deploying a Java application to Azure for the first time is not bad, but incremental updates are very painful. The basic functionality works, but it involved multiple steps that really shouldn't be there.
1. Every time that you want to deploy a WAR file, you have to delete the application's exploded directory (ROOT, for example). In order to do this properly, you have to stop the server first. You should be able to simply replace the WAR file (ROOT.war, for example), and have Tomcat take care of updating the application. If you have an application that is large or has a lot of files this process can take your application out of service for a long time (20+ minutes to delete all the files over FTP in my case).
2. There is no easy way to redeploy/restart Tomcat without taking the service out completely. When updating certain classes that may be loaded in memory, you may need to trigger a Tomcat redeploy.
3. When deploying WAR files over GIT (or any of the other deployment methods), it looks like Azure SOMETIMES attempts to have Tomcat deploy the newly uploaded file before it is finished uploading. This results in a partial application deploy and requires to you to restart the server anyway to get it to load properly.
Deploying exploded WAR files via a repository seems to work OK, but classes don't always get reloaded if they change.
4. The Catalina and other tomcat generated logs seem to be locked by the OS (even for reading), and are unavailable via FTP until the site is stopped. This makes debugging issues very difficult, as errors can't be read while the server is running.
There are a number of bumps with how we enable publishing for Tomcat and Jetty. The system we have is pretty open ended as it allows you to drop in nearly any Java application. Unfortunately the side effect is that the more PaaS like experiences that are reasonably expected with the built in Tomcat/Jetty are subject to the bumps when publishing to Tomcat/Jetty that is configured with the war autoload capability. Long story short, there are work items that we are looking at to make this better when using the built in Tomcat and Jetty.
Joaquín Vano commented
We recently added a new deployment endpoint called WarDeploy for deploying your WAR files.
For more info please visit:
Additionally, we are adding support for this new deployment mechanism to our maven plugin
so we actually do CICD. In fact, we made our team (release and configuration management) near obsolete, because team members (development AND test teams) are self sufficient.
Provisioning an new environment, hardening it, deploying 20+ java based services + GUI + database + ... takes less than an hour. Then it is up and running. Only thing the owner of the environment need to do is start deploy in VSTS.
I am really happy with that.
We spent quite some time to make deployment of WAR files to Tomcat on Azure WebApp stable. We automated it all using powershell scripts (which in turn call Azure powershell cmdlets and kudu).
In general the steps taken are (keep in mind that we have 1 webapp for 1 WAR):
- Stop web app
- (optionally kill java process)
- Remove ROOT folder
- Remove ROOT.war
- Upload war file as ROOT.war
- Start webapp
- trigger url (in order to wake up Tomcat)
Most of above steps include a retry mechanism with various wait times after failure.
Finally, we have web tests to monitor that the web site is up and running.
Hope this helps other, but a built-in solution would be really appreciated.
Frank G. commented
Still buggy WAR-File hot deployment using Kudu. Don´t think about CICD, when you have to unzip all files manually on the WebApp. That´s a showstopper for production.
Alon Klein commented
two years after. any news?
Rob Barrett commented
Bump. No update since Oct 2014.
George Platon commented
Better support for Java, would be really helpful! Had the similar issues so far.
One more addition to the post above - is there any planned feature to have the deployment done by fetching the war archive from an artifactory ? (E.g Nexus or Jfrog)
All the best
Josh B. commented
Any update on this?