This blog is part of the series of Continuous Delivery Automation Framework use cases.

Java Build and Deploy using CDAF

This content has been moved from the generic CDAF Docs material as it distracted from the common concepts.

In this example, the version is automatically incremented by placing a variable in the pom.xml file

<?xml version="1.0" encoding="UTF-8"?>

  ..

  <artifactId>springboot</artifactId>
  <groupId>io.cdaf</groupId>
  <name>Spring Boot Data REST Sample</name>
  <description>Spring Boot Data REST Sample</description>
  <version>0.2.${build.number}</version>

In the build task, the build number is supplied as a maven parameter

mvn --batch-mode --file springboot/pom.xml package -D"build.number=${BUILDNUMBER}"

The resulting artefact is in a subdirectory, buy using the -flat parameter in storeFor the artefact will be placed in the root of release package.

springboot/target/springboot.war -flat

In this example, the decreasingly used remote task is implemented to deploy to a remote server, in this case, both pre-production and production are hosted on the same server. Note that there is also a local context, this is used to test the deployment.

context  target      deployHost             deployUser  deployLand                    runtime
remote   staging     perimeter.example.com  tomcat      /opt/packages/$DEPLOY_TARGET  /opt/tomcat/webapps/pp.war
local    staging     http://perimeter.example.com/pp

remote   production  rails.hdc.company      tomcat      /opt/packages/$DEPLOY_TARGET  /opt/tomcat/webapps/pr.war
local    production  http://perimeter.example.com/pr

Two deployment tasks are needed, first, tasksRunRemote.tsk will deploy the build artefact, using the verbose copy operation.

VECOPY springboot.war ${runtime}

Once deployed, tasksRunLocal.tsk will test the deployment, using the CDAF helper to cater for delays in WAR file deployment.

EXERTY "curl --silent $deployHost"