Creating a CD Pipeline With Jenkins and Java

lately, i’ve been working a lot with jenkins for continuous deployment of one of my applications. in case you haven’t seen it, the keynote demonstration given at couchbase connect 2016 used jenkins to build and redeploy the java backend and angular frontend every time a change was detected on github. this is the application i helped build.

so how did i leverage jenkins to make this possible? we’re going to see how to create a continuous deployment pipeline for a java application which includes building and deploying to a server.

to be clear, i won’t be explaining how to use the couchbase connect 2016 application, which i’m calling gittalent , with jenkins as it is a bit more complicated. we’re going to start slow to get a better understanding.

the requirements

there are a few requirements that need to be met in order to be successful with this guide. they can be found below:

• jdk 8
• jenkins 2.32+
• couchbase server 4.6+

in this example, jenkins, the jdk, and couchbase server will all reside on the same machine. this means that jenkins will pull code from github, build it using the jdk, and deploy it locally rather than to some remote server. that said, some of the automation is removed from this example because to get jenkins to automatically build when commits are found, github hooks require a machine that is not localhost. the effectiveness of this guide will still be present.

while couchbase is a requirement, it is not the focus of this guide. it needs to be present for the sample application that we’ll be pulling off github.

configuring jenkins with the required plugins and dependencies

at this point, you should have at least downloaded jenkins. we’re going to walk through setting it up because it can be a little confusing for a first time user.

you can run jenkins by executing the following from the command prompt or terminal:

java -jar jenkins.war -httpport=8080

the above command will make jenkins accessible at http://localhost:8080 in your web browser. upon first launch, you’ll be guided through a wizard for configuration.

as part of the first configuration step, you’ll need to obtain a generated value to be used as the super admin password.

after providing the password as per the instructions on the screen, you’ll be asked about the installation of jenkins plugins.

we’re going to start by installing the suggested plugins and then install extras later. it may take some time, but after the suggested plugins have been installed you’ll be prompted to set up your first administrative user account.

you can choose to create an administrative user, or continue to use the generated password when working with jenkins.

after creating an account, jenkins is ready to be used. before we create our first workflow, or job, we need to install an extra plugin.

you’ll want to choose to manage jenkins which will bring us to a list of management sections, one of which being a section for managing plugins.

choose to manage plugins and do a search for the post-build script plugin.

this plugin will allow us to execute scripts on the jenkin host after the build has completed without errors. we need this so we can deploy our java jar after it has been packaged.

jenkins as a whole has been configured. while it is ready for us to create jobs, we’re first going to get couchbase ready to go.

preparing couchbase with a bucket for document storage

couchbase isn’t the highlight of this example, but since we’re using one of my old projects, it was a requirement per the project.

if you haven’t already downloaded couchbase, do so now and walk through the configuration. for help with configuring couchbase, check out a previous article i wrote.

what is important is the bucket that we’ll be using. make sure to create a bucket titled restful-sample with at least a primary n1ql index.

if you need help with any of this, a full write-up of our project can be found here . of course, that write-up doesn’t include continuous deployment with jenkins.

now we can focus on our pipeline.

creating a job for building and deploying an application developed with java

with jenkins and couchbase ready to go we can focus on creating a job that will control our pipeline. to re-iterate on our plan, we will be pulling from github, packaging a jar in the build process, and deploying that jar during the post-build (deployment) process.

go ahead and create a new job in jenkins. the first thing you’ll be asked is for a project name as well as the type of project name

give the job a unique name and also make sure to use freestyle project from the list. when configuring this project, our first concern is the github repository that we’ll be using.

if your repository is not public, don’t worry as you can add credentials, but for this example my project is public.

i’m using the project found here .

feel free to use your own project if you’d like. with the source control figured out, let’s move onto the build step.

here we can enter whatever shell commands that we want in order to build the application that was pulled from git.

we only want to generate a jar file in this example, which can be done by adding the following command:

mvn clean package

this leaves us with a jar file in a new target directory that is only relevant to jenkins at this time. the final step is to kill any already running instance of the application and run it again.

since we installed the post-build plug-in script we can define what happens with our build.

in this example, we aren’t deploying it to another machine, but we could. instead, we’re just going to run it on the local machine.

choose to execute a shell script and include the following:

ps | grep java-fullstack | awk '{print $1}' | xargs kill -9 || true
env server.port=8081 nohup java -jar ./target/java-fullstack-1.0-snapshot.jar &

the above is cheating a little, but it’s necessary because we’re running everything locally on the same machine.

the first command will search for any running process on my mac that looks like our java application. once found it will kill the process. even if it doesn’t find the process it will return true because of our pipe. this prevents the job from failing.

after the process is stopped, we run the built jar in the background.

keep in mind that your script may be a bit different if you’re running locally on linux or windows. in a production scenario, you’ll probably use the ssh plugin for jenkins and push the jar to some server and restart the controlling daemon.

go ahead and try to run the job using the build now button. if you don’t want to initiate it manually, consider adding a hook or a cron timer in the configuration area that we had just explored.

if everything goes well, you’ll have your java application accessible at http://localhost:8081 and it will communicate with couchbase server.

conclusion

you just saw how to configure jenkins to do continuous deployment on a java application that communicates with couchbase server. this jenkins configuration will pull from github, build a jar, and deploy it. while it should be a little more polished in a production scenario, it is a good way to get started.

want to use jenkins for continuous deployment of microservices bundled into docker containers? check out a previous article that i wrote titled, continuous deployment of web application containers with jenkins and docker .