“Automate your deployment of Jenkins artifacts” it’s the “eat healthy” of your work life. You’re certain its the right thing to do, But how should you start? 

There’s a long list of reasons why you’d want to automate your deployments through Jenkins, but the two major benefits are: 

• Reduced Errors: Automating anything reduces the chance of missed keystrokes or simple errors creating issues in your pipelines. Reduced errors also mean reduced rework. This leads us to our second point…
• Increases Team Productivity: Work that’s done manually is often slow.  Automated deployments allow your development team to focus on important work that can’t be automated. 

Below are 3 ways to automate the deployment of your Jenkins artifacts. Plus one method to avoid.  

How to Automate Deployment of Jenkins Artifacts

“Deployment” can mean a lot of things for different applications, like web applications with lots of files, images, etc.; microservices that are deployed as containers; or blue/green deployment to ensure zero downtime.

But deployment can also mean simply copying the files that you build to a drop folder for another team (or a customer) to use. If this is all you’re doing, this is really easy to do in Jenkins.

⚠ Method 1: With Plugins

If you need to copy on your network, there are two popular plugins:

1.  ArtifactDeployer, which “enables you to archive build artifacts to any remote locations such as to a separate file server”
2.  CopyArtifact is primarily used to copy artifacts between projects, but it has a “target” parameter that can be used to copy to a folder

ArtifactDeployer is more purposely built for deploying, but it hasn’t been updated in over four years. While CopyArtifact is not designed for this exact purpose, it is more popular and is frequently updated.

There are also plugins to deploy to popular locations:

1.  Deploy artifacts to Amazon’s cloud storage (AWS S3)
2.  Deploy artifacts to Azure’s Blob storage
3.  Deploy using FTP

Warning! Make sure to use the Publish Over FTP plugin, NOT FTP Publisher. FTP Publisher has vulnerabilities and is not frequently maintained (I’m not even going to link to it because I really don’t want you to use it).

Using Jenkins to automate deployment beyond simply copying artifacts to other file servers or the cloud is not recommended. Let me explain why.

✔ Method 2: Use a Tool that Can Directly Deploy from Jenkins

There are a few tools that can integrate with and deploy directly from Jenkins. Most require that you use Jenkins to publish to an artifact repository or package feed first, and then deploy from that.

BuildMaster is one of these tools, and it directly communicates with Jenkins. BuildMaster will import artifacts directly from Jenkins and then handle all of the deployment complexity. It can also automatically queue builds in Jenkins, which means you can have BuildMaster use Jenkins behind the scenes. You can learn all about this integration on our Docs page.

✔ Method 3: Deploy from Your Maven Repository or Package Feed

This adds complexity to the process, but it makes sense if you want to use a central repository for your build artifacts. (There are a lot of commercial and open-source tools that can do this.)

This makes sense when you want to have other tools (alternative CI servers for example) publish to this central location; when you have artifacts or packages distributed to many locations for edge-based deployment; or if you need to create a “no man’s land” between the build and deployment tool.

BuildMaster and ProGet can also do this, and offer the added benefits of:

•  repackaging, to indicate package quality while maintaining immutability
•  package promotion, to ensure only approved and verified packages are used in the correct environments
•  deployment records, to have a package-centered view of deployments to help with auditing and rollbacks
•  package usage scanning, to tell you where which packages are installed

Obviously, I’m biased towards our products, but doing CD tasks with the right tools, like BuildMaster, makes a serious difference in the quality you’ll get from just Jenkins alone.

⚠ Avoid: Scripting Your Own Deployments with Jenkins

Jenkins is an all-purpose automation tool that was designed for Continuous Integration. It can run scripts, which means it can do anything you can script, including deployment.

But this means YOU have to script deployment, and there’s a LOT to deployments.

•  Large, monolithic applications have thousands of files that can take a long time to deploy; require starting and stopping components at just the right time; are a bit quirky, and sometimes need a retry.
•  Microservices are often distributed to many servers; relatively easy to deploy, but often need to deploy several at the same time; and there are often lots and lots of microservices, often with slightly different ways to deploy because they’re developed/improved over many years

🤝Jenkins and BuildMaster Together

In this article, I’ve gone through the options available to automate deployments through Jenkins. The reality is that doing anything more than copying artifacts is pretty much beyond the scope of Jenkins.

BuildMaster is perfect if you want to automate deployments and not worry about the complex process of scripting your own. BuildMaster directly communicates with Jenkins to automatically queue builds. You can learn about the details of this integration on our Doc page.

When you use BuildMaster (or any other CD or deployment tool) with Jenkins, you get all of the value that Jenkins is currently bringing you (build automation/CI, testing, and/or running arbitrary scripts) plus a flexible release process that the business wants to use. This also has the added bonus of being more accessible to team members who aren’t Jenkins experts.

Don’t do all the work of scripting your own deployments with limited tools, download BuildMaster for free to start automating them! For more approaches and insights on making your Jenkins CI/CD work for you, why not check out free eBook “Level Up Your CI/CD with Jenkins”. Download your copy today!