Automatic fat jar deployment with Bamboo
- Bamboo 5.5
- Spring Boot
This article shows an example of how to deploy a Spring Boot fat jar on a remote server using Bamboo. As reminder, a fat jar is a self-contained jar, in other words it contains all the dependent libraries. With Spring boot it’s also easy to embed an HTTP listen such as Tomcat.
deployment project has to be associated with a
Bamboo plan. Usually, it produces an artifact and this is what you want to deploy.
Is it without saying that in our case the artifact will be a fat jar.
Define the artifact
You have to tell Bamboo where to find the artifact. Just follow the steps:
Plan configuration > Stage > Artifacts > Create definition
And then fill in the form:
- Name: myApp-release-jar
- Location: /target
- Copy pattern: *.jar
- Shared: true (this is important otherwise you won’t the artifact from the deployment project)
Extract maven GAV - optional
You might need to extract the maven GAV (GroupId, Artifact, Version) from the pom.xml, in order to reuse these variables in the deployment project:
- Add task: Maven POM Value Extractor
- Variable Type: Plan
- Variable Prefix: “maven”
Create deployment project
If you do not know how to create a deployment project click on this link.
The deployment can be triggered right after the plan succeed or it can be scheduled at a specific time. Eventually, no trigger is defined, and then it’s up to the user to run it manually.
You must first create an environment, like this one:
And then we will focus on the
Edit tasks. Here are the tasks needed:
The tasks “Init Kerberos auth” and “Destroy Kerberos” are custom commands. It is used to initiate/close the authentication with the remote server. I won’t cover the authentication because it might vary for each of your cases.
Clean working directory task
This is one of the default task. Just keep it as it is.
This is the second default task, it’s used to get the artifact to deploy. Normally in the dropdown list appears the name of the artifact from the Bamboo plan, just select it and save.
If the artifact is not listed, go back to the plan configuration and make sure the
shared option is checked in the artifact tab.
From now, I will use only
Script tasks to manage the deployment. It might seem a bit low level, but at the same time it’s really flexible.
I’m going to use the following variables, all along the different scripts:
- releaseVersion (plan variable or extracted from the maven pom)
- app.name (name of the application to deploy - also the maven artifact id)
- app.server (user@servername)
- primary.port (the port on which to run the app. In the future there might be more than one app running so this one will be the primary one.)
The first script task is used to upload the jar on the remote machine. (the bash script goes in the body of the task)
There might be already an instance of your application running on the server. You should stop it before starting a new one.
I could have done something much smarter. But in my case I know this is the only app which runs on this port.