The last blog post (Jumping into continuous delivery with Jenkins and SSH) demonstrated how to build and deploy an application continuously using Jenkins, SSH and Nexus. In that scenario, the application was packaged and deployed on Nexus by Jenkins, and then retrieved from Nexus by the host. However, what about doing it without Nexus? You might have no other need for Nexus or even Maven. Or perhaps you prefer to deploy your application only after you have tested it in several environments. So, how to deploy your application without Nexus?
This post explains how to use the Jenkins SCP plugin to copy the freshly built application to another machine using SCP. This is useful when you need to copy an application to a specific machine or another environment without exposing it publicly.
Although this post is focused on Jenkins, other continuous integration servers have equivalent capabilities.
Why copying instead of deploying to a repository?
In addition to the fact that you may not use Nexus or Maven, there are a couple more advantages to copying an application instead of publishing it.
First, using copies, your application is kept private. Your artifact must cross the whole test pipeline before being published to a repository. So, you know that your team won’t rely on an untested (or at least, not completely tested) artifact.
Secondly, all the versions built by Jenkins will be copied. The previous approach used only the latest, which runs the risk of skipping some versions, making it hard to know when a regression was introduced.
Let’s move on and modify the pipeline. Our previous pipeline was the following:
We update it slightly, to the following:
To implement this pipeline, install the Jenkins SCP Publisher Plugin (actually named Hudson SCP Publisher Plugin):
Then, you need to configure the host on which you want to upload the application. In the global configuration of Jenkins, scroll down to the SCP repository hosts section, and configure your new SCP Site:
Note: The SSH and SCP plugins must be configured separately.
Then, in the Jenkins job building the application, we add a post-build action to upload the artifact to the host. Check the ‘Publish artifacts to SCP Repository’ check box, and select the site you added. You also have to select the files you want to upload. In the following picture, we select the war file we’re building:
The ‘destination’ allows you to define the final location of the file you deploy. This location is relative to the root set in the site configuration. In our case, it’s already the Tomcat deploy folder. You can upload several sets of files, but to only one site. If you have to deploy to several sites/hosts, you will need one job per site/host (making sure that each job deploys the same files).
Once done, we’re good to go. Execute your build, and the files will be uploaded. The rest of the pipeline can be more or less the same as in the previous post, except that now you already have the application in place. If you’re targeting an already running environment supporting hot-deploy, then you don’t even have to do anything else after this deployment.
Conclusion
This blog post shows how the Jenkins SCP plugin can be used to support continuous delivery, and actually provision your application to your host. It’s another way to achieve continuous delivery simply. This approach is particularly well suited when your host already contains your application server, and when this application server supports hot-redeployment.