In a previous blog post, we discussed a quick overview of Continuous Integration and Deployment of .NET applications using Visual Studio Team Services (VSTS). This involved building and deploying regular old .NET applications with VSTS—something that we would definitely expect a Microsoft service to handle. However, there is some lesser-known support that VSTS has for other frameworks, including Java. The Microsoft VSTS website even has a portal page proclaiming their Java support: “Love Java? So do we!”

VSTS support for Java build frameworks such as Maven and Ant came in handy for AIS recently, as we were tasked with developing some new features for an older Java desktop application for a federal client. And I will have to say that all of the VSTS tools for Java applications worked flawlessly. We were able to easily add the Java project source code to a Team Foundation Version Control (TFVC) repository hosted online in VSTS. Oracle even has an extension for integrating with a TFVC workspace—allowing us to check in changes right from the JDeveloper IDE.

After development environments were set up with the IDE and version control, the next thing we wanted to tackle was to set up continuous integration for this Java application. Setting up the automated build was extremely straightforward—all we needed to do was to write an Apache Ant buildfile. This is just an XML file that contains one project and at least one target, which each target including one or more build tasks. In our case, tasks included building the actual JAR application and all of its corresponding directories, including and excluding specific files within those directories, and then creating a zip file of the whole bundle as an output.

The next step was to create a Java build definition for VSTS. The first task was an Ant build task that would target the Ant buildfile in the repository. We didn’t even need to create our own build agent, as the VSTS hosted agent handles Java builds. After that, we just made a simple task to copy the zip file containing the compiled application to a VSTS drop folder location.

Lastly, we wanted a place where both our testers and the client could go and easily test the application. As this application was a desktop application—and not even an executable one yet—the only real deployment option was to copy the zipped JAR application directly to a virtual machine. This too, was an extremely simple process. First off, we created a Server 2012 VM in our AzureGov environment. After that, we created a release definition in VSTS that connected to the AzureGov subscription. This task would take the zip file from the build task’s drop folder and then copy it straight to the common desktop directory of the VM. VSTS allowed us to create a directory denoting the date, build number, and the name of the release on the fly—a folder where each release was stored. We created accounts on the VM for both the testers and the client and they could go in and test changes.

Considering the decent size of this application, it only took about 10 minutes between checking in changes to the VSTS repository and having the latest release of the application copied to the AzureGov VM—not bad at all for a continuous integration and deployment cycle.

AIS as a company is a Microsoft Partner and most of our shared experience and knowledge lies with Microsoft products and services. While this Java application development was a new one for us, the experience was actually quite pleasant due to Microsoft’s continued drive to provide support for non-Microsoft products. We were able to set up continuous integration and deployment for Java in almost the exact same way we would for a .NET application. And because of the ease of this experience, we are definitely looking forward to more opportunities developing with Java and other non-Microsoft products.